Kanban
it's all about the throughput, baby
Forget about the card wall for a minute. To get at what Kanban is about, think of the development process as a pipeline, with capacity determined by the most constrained segment. Relieving pressure in the blocked segment increases maximum sustained throughput. The question is: how to find the obstructions? Kanban is a quest, and the card wall is the treasure map where increased capacity lay hidden, waiting to be discovered.
Traffic Signals
Kanban means Signal Card: a metaphor of traffic control, a protocol for team members to signal the need for collaboration on some issue, like a traffic light going to amber. If the issue can’t be resolved more or less immediately, then the signal goes to red: a call for all-hands on the problem. The underlying theory is that relatively few constraints are responsible the most significant limitations on throughput, thus, increased productivity can be achieved by a systematic identification and resolution of constraints.
Increased Productivity
Kanban has no time-boxed sprints; instead, work is batched by WIP limits coordinated by buffer and pull policies, with important implications when it comes to release management. There are few proscribed practices, and no prescribed meetings or roles.
If you’re simply running a team with no Sprints and no WIP limits, then calling it Kanban misses the point. Although Kanban and Scrum are both work scheduling systems, Scrum is a framework that has a lot to say about how to the team should work whereas Kanban is mostly concerned with finding constraints that are limiting productivity.
Much of the methodology has to do with organizing the work so that we’re in a better to position to understand what is limiting throughput. The essence of Kanban is to stop kicking the can down the road and deal with issues that come up during the execution of work in real time.
WIP Limits
Limiting the amount of simultaneous Work In Progress gives us a way to identify what’s holding things up. What we’re hoping to get out of it is to:
- Prompt collaboration to prevent work from getting sidelined pending resolution of whatever question has been raised.
- Increase productivity by encouraging team members to focus on completion of work.
- Improve understanding the team’s activity by having less work in flight at any one time.
We’re trying to understand what the actual process is, why team members are working the way they are, to understand what obstacles they are working around, and to figure out what changes would improve outcomes. The problem that Kanban is trying to solve is a predictable outcome by emphasizing the strategic advantage of focusing on quality over maximizing capacity.
Backlog Refinement
Kanban doesn’t prescribe a Backlog Refinement Meeting, or how one should be run. Prioritization is an inalienable attribute of a Scrum backlog whereas Kanban promotes just-in-time prioritization in the Queue Replenishment meeting.
Decomposition is always tricky business, especially in the backlog, where we’re trying to keep the focus on the business objective and avoid speculation on solutions, but it is necessary to break work down into manageable components at the backlog stage. The INVEST set of qualitative attributes is appropriate for any process.
Batching Work
Scrum pulls from the Product Backlog in the Sprint Planning meeting, the goal of which is to pull a batch of work corresponding to the team’s capacity for the duration of a Sprint. Getting the batch size right involves
- projecting the teams capacity,
- estimating the work,
- guessing the impact of queue time.
Each of those is a puzzle; taken together it’s just a lot to ask for.
Kanban pulls from the Product Backlog in a Ready-Queue Replenishment meeting where you don’t have to take any of those bothersome questions into consideration. The team’s capacity is already subsumed in the WIP limit set for the Ready for Work state.
You might choose to do effort estimation to support analysis, but all you need to worry about is getting decomposition right (qualitative estimation). Queue time is managed with buffer and pull policies, and we don’t have to consider that during the replenishment meeting.
No Story Left Behind
A common problem is Scrum is that by the middle of the Sprint, most of the work is in progress with very little done and it’s hard to tell what’s going on by looking at the board. Burn-down charts may summarize the situation, but don’t provide any insight into what needs attention. The busy-board progression is inevitable when blocked stories are sidelined pending resolution of some question or issue. By the last day of the Sprint, the situation is usually a bit less clear. The smoke finally clears at Sprint Review meeting, not that you can do anything about it by then.
Kanban can’t force you to resolve issues in real time, but it does provide a protocol for sidelining blocked work. First, the WIP limit on the In Progress state provides some buffer to allow time for questions to be resolved. You might set a higher limit on a globally distributed team, when questions are to team members who are not available, but when you hit the WIP limit, and you want to pull another story to keep working, then the protocol requires approval, a signal for collaboration to ensure that whatever the decision, there is deliberation and visibility.
Ideally, instead of sidelining a blocked story before pulling a new ticket, the team comes together to resolve the issue, so the story can move to the next transition state, rather than be blocked.
Frequent micro-meetings forced by the signal system reinforces the importance of team collaboration and sets the stage for retrospective and root-cause analysis to become part of the fabric of daily activity. The signal system and WIP limits are intended to make it a bit harder to kick the can down the road than it is to try to resolve these question in real time.
Lurking behind the rows and columns of the Kanban card wall are hidden constraints; the elusive complications that are a drag on progress. Increase throughput is the bounty paid for each issue resolved. I like the treasure hunt metaphor better than the mud-and-blood Rugby metaphor of Scrum.
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.