Karl Scotland – Using Agile to Deliver Value
A Kanban Sidebar
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.
Related posts:
| Print article | This entry was posted by Karl Scotland on January 9, 2009 at 2:35 pm, and is filed under Agile. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |
No trackbacks yet.
The Science of Kanban – Conclusions
about 1 day ago - 1 comment
This is the final part of a write-up of a talk I gave at a number of conferences last year. The previous post was about the science of economics Scientific Management Revisited Is scientific management still relevant for product development then? As I have already said, I believe it is, with the following clarifications. I More >
The Science of Kanban – Economics
about 2 days ago - No comments
This is the fourth part of a write-up of a talk I gave at a number of conferences last year. The previous post was about the science of process Having a good understanding of how creative people can have an efficient process still isn’t enough however. As Russell Ackoff is often quoted as saying, “It’s More >
The Science of Kanban – Process
about 3 days ago - 1 comment
This is the third part of a write-up of a talk I gave at a number of conferences last year. The previous post was about the science of people. Even though a kanban system describes knowledge work, we can still apply formal sciences such as mathematics. Rather than applying them at a detailed, micro level, More >
The Science of Kanban – People
about 4 days ago - 1 comment
This is the second part of a write-up of a talk I gave at a number of conferences last year. The previous post was the Introduction. Software and systems development is acknowledged to be knowledge work, performed by people with skills and expertise. This is the basis for the Software Craftsmanship movement, who are focussing More >
The Science of Kanban – Introduction
about 5 days ago - No comments
This is a write-up of a talk I gave at a number of conferences last year. I have split it into 5 parts. Abstract Science is the building and organising of knowledge into testable explanations and predictions about the world. Kanban is an approach which leverages many scientific discoveries to enable improved flow, value and More >
Visualising Kanban Dimensions with TIPs
about 1 month ago - No comments
Following on from my post describing a Kanban Visualisation TIP (Token, Inscription, Placement), this post gives some examples of how to visualise the various dimensions of a Kanban Multiverse. The goal is not to define any ‘correct’ ways of visualising information, but to show that there are a variety of useful approaches and hopefully inspire More >
Thoughts on Kanban Thinking
about 2 months ago - 4 comments
Some thoughts on what I have been referring to as Kanban Thinking Why create an other brand? I’m in the camp that believes we need to create more brands, rather than reduce everything down to “common sense” or “good practice”. To paraphrase Alistair Cockburn, every successful team should create its own branded processes to describe More >
The Economics of Raking Leaves
about 2 months ago - 3 comments
I was out in the garden this weekend raking up leaves. Having read Geoff Watts recent post about using Scrum to clear his leaves – and as someone who can’t do anything without thinking about work (see Kanban and Quad Biking!) – my mind turned to how I would use Kanban Thinking to approach the More >
Scrum Gathering London – A Blast From the Past
about 2 months ago - 2 comments
At the Scrum Gathering in London this October, I had a bit of a flash-back to the last time the Gathering was in London. At that event, during the Open Space, I announced a Kanban session with words along the lines of “My team recently stopped using Scrum and our productivity has improved”. As I More >
A Kanban Visualisation TIP
about 4 months ago - 1 comment
In a previous article I wrote on Visual Management, I described how kanban boards can be viewed as multi-variant displays, visualising multiple possible dimensions of a kanban system. To visualize all these variants we can use a number of techniques to create multi-functioning graphical elements which can achieve a high data density. The techniques, when More >






about 3 years ago
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.
about 3 years ago
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.
about 3 years ago
I’m on kanbandev but I’m usually very behind on mailing list mail. If you post something, I’ll participate.
about 3 years ago
Hi Jason,
Probably true. The queues help mange variation in size of the features.
Perhaps a better wording would be that the goal is one piece flow?
Karl
about 3 years ago
Those are the ultimate goals. Shorter lead times is achieved via one piece flow.
Are you on the kanbandev list? I’d love to discuss this there with the group.