Noodling on Kanban… Part One

For the next few posts I want to explore some of my thoughts on Kanban. Like many in the community, I started thinking more about this during the Lean/Kanban Conference down in Miami. On the heels of that conference I did an exploratory post on some of the similarities and differences between Scrum and Kanban. The post addressed how Scrum and Kanban (in principle) were not all that different and how Kanban makes some things explicit that Scrum leaves up to the team.

There are a lot of things I consider myself pretty knowledgeable about… but on the whole… I am not certain Kanban is really one of them. David Anderson wasn’t sure he agreed with my conclusions about Kanban… but didn’t totally slam the post… so I took that as a small victory ;-) For the real experts… you do need to go hear what David Anderson, Corey Ladas, Karl Scotland, David Laribee, and Henrik Kniberg have to say about all this. These guys are in the thick of the Kanban movement and most of what I know comes through them.

That said… I fancy myself pretty good at figuring stuff out and understanding what is most important. I am also pretty good at communicating complex ideas in a way that others can understand. So with that little bit of confidence (bravado) I am going to take another stab at explaining what I think is essential about Kanban… what tooling and principles I think are most important… and explore a bit how we can use these ideas to help our organizations become more effective.

Kind of like my first post on Kanban… I believe it is helpful to start from a shared foundation and bridge into the new ideas. My opinion is that there are five or six things… right out of the gate… that we need to know about Kanban to be knowledgeable of where it fits and how we can use it to our advantage in the enterprise:

The Kanban Board

The Kanban Board is a tool that helps the team visualize the flow of value through the development process. If you have used a Scrum task board you should be pretty familiar with the general concept behind the Kanban Board. There are sequenced columns that represent the states a work item can have at any one time. As work progresses through the development lifecycle, the card is moved from one state to the other, until it has been accepted by the customer.

The primary difference between task board and the Kanban board is that the Kanban board tracks the flow of user stories through their development cycle and is not concerned with tasks. This is significant because now the team is focused on the value creating item, the user story, rather than the activities required to deliver that value. Only when the entire user story makes its way through the Kanban board have we delivered value to the customer.

A simple Kanban Board might have a column for the backlog, work in process, and the work completed. A more complex Kanban board might break out the work in process column to include dedicated areas for each of the steps in a typical development lifecycle: analysis, design, develop, code, and test. Some Kanban boards will include columns for buffers between the various states depending on the needs and process maturity of the team.

Work In Process Limits

Kanban is more than just a way of visually tracking progress at the user story level. The Kanban board is intended to help the team minimize waste, focus on the most important work, and keep the value flowing through the team. The Kanban team accomplishes this by setting work in process limits for each column of the Kanban board. Work in process limits effectively restrict the amount of work that can be in any one state at any one time.

One common failure mode in Scrum is late delivery within the sprint. Late delivery means that all the backlog items were in process during the sprint but were only fully done and accepted in the day or two prior to sprint closeout. Late delivery introduces risk, tends to destabilize velocity, and results in delayed value delivery to the customer. Scrum addresses this by encouraging team members to work together on only a few backlog items to completion before starting new work.

Kanban takes this implicit guidance and makes it explicit by setting a limit on the number of work items that can be active at any one time. By limiting the amount of work that is in process, the team is forced to focus on getting backlog items fully done before new work can start. These limits can be determined by the team, or by their management, in ways that optimize the flow of value and reduce the number of intermediate work products.

So… What’s Next?

The next post in this series will address constraints and a reasonable division of labor. After that we’ll discuss doing away with iterations and replacing velocity with cycle time. We’ll close with some discussion around why a team might want to consider using Kanban (over basic Scrum) and a little on where I see Kanban being used outside the team in more of an enterprise portfolio context.

Until next time…