Essays on the Continuous Delivery of High Quality Information Systems
{ Category Archives }
Jurgen Appelo has put up a survey of Agile practices. While I consider myself and this blog to be decidedly post-Agile, I also love survey data and the concerns of practitioners. Plus, critical analysis of the survey itself makes for great sport.
I made a simulation of an XP-like process. I won’t go as far as to say it’s exactly XP, but it’s a reasonable approximation. The first one is an unconstrained workflow with a single customer. It is a PIPE2 simulation, and the file is here. Multiple customers (or nested stories) would require a colored Petri net, which PIPE2 doesn’t support. One of the keys to understanding the model is the bidirectional edge between the customer and write a story. The team keeps writing stories until the customer doesn’t want any more stories and accepts a final build. Other keys are the bidirectional edge out of accept story and the inhibitor arcs into accept build. Those things give the model most of the “iterative goodness” you’d expect. Not surprisingly, the unconstrained workflow rarely reaches a checkpoint where the customer has nothing in process, so the deliver build transition rarely triggers. If we add a stories in process kanban limit, then there is also much more reengagement with the customer as a consequence. That model is here. I would be interested to hear of any improvements to the model. |
This is the card wall we’re currently using in the Modus Cooperandi office. It’s not terribly complicated, because there are only five of us, but there are still a couple of interesting things about it.
We’re working on a number of different programs in the office. Some of these programs have distinct workflows. Most of them don’t, or more accurately, don’t yet. So, we’ve split the board into two sections.
The top section is the workflow for software development. The workflow is yet another variation on the two-tier workflow that I’ve discussed here before. The green tickets are Minimum Marketable Features (MMFs) and they occupy the outer, slow-moving workflow with states { backlog, ready, busy, demo, verify, done }. The yellow tickets are User Stories that are decomposed out of the green MMF tickets. The inner User Story workflow is { ready, busy, demo, done }. Stories should be done in a few days. MMFs may take several weeks. The workflow is not particularly detailed because the team is small and the work is exploratory. The emphasis on the demo states is because most of the work is done off-site. We’ve allowed capacity for two MMFs in process at any time, but for now we are only scheduling one.
The rhythm of pull, and the discipline of the MMF make planning a self-regulating activity. Naturally occuring pull events occasionally trigger planning events, which trigger further pull events and so on. Demos and process improvement are built into the workflow, so no planning contrivances are required to make these happen. Keeping the “Minimum” in MMF isn’t always easy, so having a “Minimum Champion” around is pretty important to making this kind of self-regulation work. Time spent thinking about real options strengthens one’s resolve in this matter. Enforcing the MMF is still much easier than wasting a lot of time on estimating and forecasting. And after you gather enough cycle time data, the work begins to forecast itself.
Software development is one thing we’re working on, but we also have a number of other programs which are…not software development. For now, these are mixed work item types that don’t have well defined workflows. Instead of assigning them to a workcell, we assign them to individuals, with a generic common-denominator workflow of { backlog, ready, busy, verify, done }. Backlog tasks are unassigned. Ready tasks are assigned by affinity or consensus. At the time that a task is assigned, it is given a due date. When busy tasks are judged complete by their owner, they are moved to the verify state, where somebody else has to agree that the task is complete. When a task is verified, it moves to a pooled done state. Blocked work, as always, gets a pink ticket for issue resolution and/or process improvement.
Some of these programs are content development and we expect that they will develop more regular workflows over time. When we identify those workflows, we’ll redraw the board and move their tickets out of the personal rows and into new workcells. Eventually, we may collapse all of the personal rows into a single “miscellaneous” row. The miscellaneous row is worth keeping because there’s always random stuff to do that still merits tracking. The card wall is a living system that is subject to evolution as we learn more about how to do our work.
We haven’t set hard WIP limits on the personal rows, because we’re able to manage it through peer feedback…mostly. The emphasis on controlling WIP still allows us to plan new work and manage the backlog on demand. We all know that if the WIP ever gets out of hand, we can restore order by setting kanban limits. The card wall is the focus of the daily standup, where we gather around, point at the tickets, move them around, write new tickets, and make plans for how we’re going to advance the board for the day.
The lesson is that, with or without kanban, the investment in a thoughtfully designed and carefully managed visual control is already enough to obviate time boxing and the planning ceremony that goes along with it. Go with the flow.
Software development is like golf in that your chosen path to the pin is a primary problem.
The choice involves weighing your capabilities (people), the course (technology), and the conditions (market).
Confident you can do anything? Bring out the big guns and send it over that treeline on the left. If you make it, you must land it among that sea of traps. This is the most common choice in software development, and the #1 reason why we so frequently turn “par 5″s into 10, 15, and 20s.
Don’t have a team of Tigers? Then go long down the center if you can avoid that large sand trip on the left and lake beyond it. But is this abstract little map accurate enough? Does it tell us about the 50 yards of soggy turf there in the middle? How about wind howling left to right over the lake? Unless you’ve played this hole before you don’t know. What makes software development so tricky is by definition we never play the same hole twice. Technology is changing around us, even while we make our own changes.
Want to make sure you don’t turn a par 5 into a 10? Land it short of the traps on the fairway and take it from there with comfortable strokes. There’s a price to pay for this caution: no holes in one for you. You’re less likely to be a hero this way, but in team-scale software development, the hero model will fail you are sure as a week in Vegas, anyway.
And, sometimes, the conditions are particularly bad. In the downturn of 2008/2009, one could say the conditions for technology products are analogous to “a raging hurricane, with chance of nearby volcanic eruption and ash over the course.” So take care. Be humble. And may you keep both your work in progress and your golf scores down.
(apologies to all software developers offended by an anology from the “sport of salespeople and CEOs”. Think of it as an analogy to bridge the divide)
Lean & Kanban 2009 Miami is a three-day conference featuring a full day of presentations with separate tracks for Lean and Kanban, plus a full day of open space and a half day of lightning talks. I’ll be speaking about Scrumban and process evolution on the first day and enthusiastically working the open space session on the second day.
I think this is going to be a very exciting conference. The Lean software development community has made explosive progress over the last couple of years, only to discover that we are still in the dawn of our evolution. I expect to see terrific advancements in 2009 and some of them may very well find their beginnings at this event.
