Kanban in a nutshell

[Health Warning: looking at this still quite popular post 3 years on, I worry about its focus on kanban the tool, not on Kanban the method. Best read in conjunction with Introducing Kanban through its values and Values, understanding & purpose. If your interested in Agile software development I can recommend Learning together: Kanban and the Twelve Principles of Agile Software too.]

Step back, squint a little, and think of your development project organised in a big to-do-list.  In your imagination, pin your to-do, in progress and done deliverables onto a board like so:

To Do

In Progress

Done

Hold that picture for a few more moments and visualise those tokens moving across the board as work gets done.  See how items pass quickly through the In Progress stage when only a few are allowed there at at any one time; watch the whole process slow down as work-in-progress (WIP) is allowed to grow.

That three-stage process is of course an over-simplification, so let’s map it out in a little more detail.  In Lean-speak, we’re identifying our particular process’s “value stream”.  Here’s a representation of mine:

[To Do]

[In Progress]

[Done]

Proposed

Prioritised

Ready for Dev

Dev

Test

Ready for Release

Released

Imple-mented

In my model (yours may differ):

  • Proposed items could (but perhaps never will) get done; they are subject to a prioritisation process
  • Prioritised is where pre-dev analysis work gets done if any is needed
  • Ready for Dev is a buffer between the prioritisation and analysis activities the the left and the core Dev and Test activities to the right.  It’s handy too for forcing the sequencing of some prioritised items ahead of others.
  • Ready for Release is another buffer – we can’t always release immediately
  • Released is Done, Implemented is Really DoneTM. When that distinction isn’t important, items go straight to Implemented.

The items here are all features, recognisable by the people that sponsored them, even where the team has chosen to break the larger ones down to manageable size.  On those rare occasions where we need to break work down into pieces smaller than a working feature (into tasks, say), that breakdown goes into our Trac system but not onto the board – we’re interested in delivering value, not just tracking how busy we have been!

Then there are two rules for choosing what to work on:

  1. Pick a rightmost available feature (e.g. prefer one in Test over one in Dev)
  2. Don’t move an item into a column if doing so will breach a work-in-progress limit.  If that leaves you with no available features, go and help someone else complete theirs.

In a sentence, Kanban is a WIP-limited, pull-based system for feature-driven software development.

What makes for an “available” item here will depend on local factors: roles, skills, approvals to make high-impact transitions (e.g. releases), and so on.  I’m told that some teams – especially those that (i) practice pairing, and (ii) don’t have much differentiation between roles – find that WIP is limited naturally, in which case rule 1 suffices on its own.

But every team is different!  Initially, my team did without WIP limits but found that work didn’t flow quite as well as we expected; later we added a limit that spans the Dev and Testing columns, set (with buy-in from the team) low enough to encourage pairing.  That limit is so rarely reached now (let alone breached) we could consider removing it again.

Add some local rules for dealing with exceptions such as rework or unplanned urgent work, and that’s pretty much all there is to it.  With a bit of thought there should be nothing about Kanban that precludes it from being implemented on top of an existing process – probably a good starting point for most teams.

The control tools

These are simple too:

  1. The Cumulative Flow Diagram (CFD) – the counts of items in each column recorded over time and shown in a stacked chart, completed items at the bottom. Brilliant for visualising lead times and bottlenecks.
  2. Lead times (read off the CFD or captured on a per-feature basis) tracked over time

Here’s a CFD:

cfd1

If that seems too complicated, we can go back to the simpler to-do list model:

cfd2

but bear in mind that your definitions of “To Do”, “In Progress” and “Done” may differ from your customer’s, so be careful.

What makes the CFD a really useful tool (I refer to mine a lot) is that the widths and heights of those coloured bands give (respectively) average cycle times (lead times if measured from the “Prioritised” stage) and WIP. It is very interesting to see how these correlate over time – they tell a story about the progress of your project that you can use in your retrospectives and feed into your improvement process.

Next up: a series on lead time “diseases” with some Kanban-inspired remedies.  Watch this space!

4 thoughts on “Kanban in a nutshell

  1. Mike:
    I caught your link to this from the KabanDev discussion board. Very nice job. I hope your next installment continues where you left off, interpreting the CFD. If you can similarly reduce CFD interpretation to an easy-to-understand format it would be both instructive and a great launching point for your “diseases” explanation.
    I still find a lot of questions in various threads about the CFD, for instance, there was a link to this presentation in one of the KanbanDev threads:
    http://www.slideshare.net/yyeret/explaining-cumulative-flow-diagrams-cfd
    Thanks, and keep us posted.
    Bill

  2. Pingback: Tweets that mention Kanban in a nutshell « Positive Incline -- Topsy.com

  3. Pingback: Knowing .NET » Blog Archive » Recently Bookmarked…

Comments are closed.