Evolving the kanban board

My wife and I are planning to move house. We aren’t sure where we want to move to, or indeed how much we have to spend. Naturally, though, we want to get the highest possible selling price for our current house in order that we have as many options as possible. So we called in a “house doctor” to help.

After she (the house doctor, not the wife) had recovered from the initial shock of seeing how we have customised a fairly standard 4-bedroom house into a 6-bedroom eclectic disaster, she produced a report containing a list of cosmetic improvements we should make in order to attract prospective buyers. The list is long, with jobs for myself, my wife, and our local handyman. We needed to make the project manageable in a way that would allow us all to contribute as and when we have the time. So I found an old whiteboard in the garage and made this:


As you can see, I drew a very rough plan of the house, including sections for upstairs, downstairs, the attic, and the outside. We then wrote a small sticky note for every improvement suggested by the house doctor (blue) and some that we had always wanted to do ourselves (yellow).

When we finish a task, we simply remove the ticket. For example, you can see that we have already finished all of the tasks needed in the Office (priorities, right?).


And why am I telling you all this? Because this is what I recommend teams do for their software projects. When you pick up the next feature, draw an architecture diagram and populate it with sticky notes. The resulting board is a “map” showing the feature and the tasks that need to be done in order to deliver that feature (thanks to Tooky for that analogy).

  • The diagram you draw for Feature A might differ from the one you draw for Feature B, because you might be touching different parts of your estate. That’s cool. The diagram needs to be the one that’s most appropriate for the work you’re about to do.
  • The visual representation of your architecture allows more people to be engaged in discovering the tasks that need to be done to deliver the feature.
  • And it allows everyone, often including non-programmers, to see and understand the scope and impact of what is to be done.
  • Sometimes doing a task will spawn others: things we didn’t consider when we did the original feature break-down; things we’ve learned by making changes or completing spike tasks; things we or the Product Owner couldn’t envisage sooner. That’s fine — we simply add and remove sticky notes as we think of them (and look for opportunities to slice off a separate feature that we can push back onto the ideas heap). The whole thing is quite dynamic, and yet very well controlled at the same time.
  • If possible I like to include testing in the scope of the stickies, possibly adding a few explicit testing task stickies where necessary.
  • As you finish each task (whatever “finish” means for your team), either remove the task’s sticky note or mark it with a big green tick. For our house doctor board, we’ve decided that removing the stickies is best. But for software teams, I generally recommend adding big green ticks to completed tasks. This allows anyone to see how much progress you have made through the current feature, and which areas still need more work.
  • Sometimes the distribution of ticked and un-ticked stickies will suggest opportunities for splitting the feature and releasing a subset earlier than planned.
  • Hold stand-up meetings around the diagram as often as you need, and certainly whenever anything significant changes. (Some of the teams I coach have been known to hold informal stand-ups 4-5 times each day.) The architecture diagram helps facilitate and focus these discussions, and makes it much easier for everyone to contribute.
  • Note that all of the above works best when the team has a single feature in flight. A WIP limit of one. Single piece flow.
  • This approach works well when combined with the 5-day challenge.

As usual with the recommendations I write in this blog, this idea is probably not a new one. But it is highly effective, and I recommend you try it.


I gave a lightning talk on this topic at the Lean Agile Manchester meetup this week. There is a video (below), although unfortunately you can’t actually see what’s on the slides. So I uploaded the slides here.



“from chaos to kanban” now online

I recently co-authored a paper with the developers at Codeweavers Ltd in which we describe their two-year journey from complete chaos to a highly evolved kanban-style software process. The paper has been accepted for XP2010, and you can now get the PDF from the Codeweavers developer blog. Well worth a read, because it shows in detail the team’s gradual transition using simple inspect-adapt steps. (Paul and Craig also presented the paper at AgileNorth2010 and received a lot of interest and positive feedback.)

initial observations on kanban introduction

One of the teams I coach decided this week to adopt kanban-style limits on the WIP at each part of their value stream. It’s much too early to tell how beneficial this will prove; the transition, though, showed up a few points of interest:

  • In order to set WIP limits we had to map the company’s value stream more completely. In retrospect, the previous fuzzy understanding of the value stream had been one cause of the bottlenecks towards the customer end of the process. Kanban was the catalyst to fixing this, but otherwise unrelated.
  • Re-mapping the value stream temporarily focussed everyone on clearing some inventory, because a couple of WIP piles were initially bigger than the WIP limits we had all agreed.
  • We quickly discovered that some of the existing inventory was caused by cards only having customer value in batches. Cards had been held up in huge piles at the “Beta” and “UAT” stages, because they didn’t represent stand-alone demonstratable user value.
  • The introduction of WIP limits helped everyone to realise that the cards had been representing engineering tasks rather than customer value. So either the WIP limits had to be multiplied by the number of engineering tasks per user story, or future cards had to change and become user stories.
  • The introduction of WIP limits also served to focus everyone’s attention on the whole value stream. Previously the developers had been throwing cards “over the wall” into “Beta” and “UAT” and then forgetting about them. WIP limits quickly encouraged the developers to address bottlenecks in all areas.
  • Some of the existing value stream stages turned out to be buffers for others; and at least two of these buffers were “discovered” during the mapping exercise. We set low WIP limits on these buffers, to help squash the “over the wall” mentality.

No doubt WIP limits will throw up other subtle side-effects as the next month or so unfolds. Interesting times ahead…

Lack of visibility can be the bottleneck

Making targets and their associated metrics more visible can be the most important factor in achieving those targets. That’s the message behind the agile notion of Information Radiators or Big Visible Charts: the visibility itself is a critical component of their success. Today Shawn Callahan tells an anecdote in which it seems the increased visibility of a target and its metric served to dramatically change employee behaviour. He relates a story from Pfeffer and Sutton in Hard Facts, Dangerous Half-Truths, and Total Nonsense in which a shipping company wished to save money by bundling small orders into bigger boxes. The policy wasn’t being followed, so:

“So the company announced a new program that provided rewards such as praise—not financial rewards—for improvement. On the first day, the proportion of packages placed in the larger containers increased to 95 percent in about 70 percent of the company’s offices. The speed of this overwhelming improvement suggests that a change in performance derived not just from the rewards that were offered, but also from the information provided that the current performance level was poor and this action—consolidating shipments—was important to the company.”

As Jack Vinson suggests, the relative invisibility of the target behaviour and its measures could well have been the constraint on that business at that time. The anecdote is from the 1970s, too early for the business to have used the ToC thinking tools to diagnose the situation, or for the metric’s increased visibility to have been the result of applying the five focusing steps (identify, exploit, subordinate, elevate, repeat).

For me, the lesson from this story is that the constraint is as likely to be in knowledge management or communication as anywhere…