I was kindly asked by Rachel Davies and Liz Sedley to write a sidebar on kanban for their upcoming book on Agile Coaching (no links yet). Here’s what I put together:
An alternative approach to planning work in time-boxed iterations is to use a Kanban system.
A Kanban system uses physical tokens to limit work in progress and to pull work as single units. This helps create a one piece flow, where features of value move through the system individually, rather then being grouped into batches. Kanban is the Japanese word for “visual card”. When applying a Kanban system for software development the Kanban token can be an index card representing a user story.
A key characteristic of a Kanban system is that it limits the work in progress in order to improve cycle time, reduce investment in inventory and enhance teamwork. For example, if the team sets a limit of only three user stories being in progress at a time, the team can exclusively focus on those three stories, and defer analyzing and planning new stories until there’s space in their queue. Instead of having an iteration planning meeting, the team simply waits until they complete one of these three stories. Now they have the capacity to pull the next most important story, as prioritized by the customer.
Following this approach, task estimates are no longer necessary, and any task breakdown becomes a purely analysis and design activity. Releases can still happen early and often, but a kanban system allows the planning and release cadences to be de-coupled. The customer might prioritize user stories on a weekly basis but releases might only happen fortnightly, and releases contain whatever is ready, rather than a planned set of stories.
Instead of the team committing to deliver each feature within a time-box, the team commits to delivering features at an agreed throughput (rate of stories per release) and mean cycle time (how long each story takes to get done). These agreed metrics are arrived at by measuring the team’s performance over time.
Applying this approach with a team that was using Scrum, but struggling to deliver reliably, allowed a more natural process that enabled the team to improve and become more successful.
Point of correction. It’s not flow if there is a queue waiting for the next step to draw from it, even if that queue has a limit.
Make one, move one, no delays.
Even saying “the goal is one piece flow” is questionable. Flow is a tool used to respond to a situation. The goal is Better Quality, Lower Cost, Shorter Lead Times, Higher Morale.
I’m on kanbandev but I’m usually very behind on mailing list mail. If you post something, I’ll participate.