Noodling on Kanban… Part Two

Okay… time for part two in my Noodling on Kanban mini-series.

Yesterday we talked about the Kanban board and how it was similar, but not the same, as the Scrum task board. We also talked about work in process limits and how they can be used to explicitly control the flow of value delivered by the team. This post we are going to explore the idea of constraints and how Kanban handles the division of labor on the team. So without further adieu… constraints and labor.

Constraints

So this is how it works… we’ve got the board and we’ve got the work in process limits. As work moves through the team it is possible that certain steps in the development process might become bottlenecks and constrain the flow of value through the system. For example, the team might be dependent on a person who is not part of the team to deliver a particular feature. If that person is not available to assist them team, the work in process limits will prevent more work from being started until that constraint is removed and value is able to flow from the team once again.

Constraints are those steps in the process that are limiting the team’s ability to get completed backlog items through the system. The Kanban board forces us to stop taking on more work until we get the problem with our constraint fixed. By focusing all our attention on the constraint… we work together until the impediment is removed. Work in process limits encourage everyone to work as a team and prevent any one individual from getting too far ahead of everyone else.

Fundamental to the idea of managing constraints is the notion that any partially completed features are considered inventory and could potentially lead to waste. Our goal with a Kanban system is to limit the team’s ability to create inventory and increase the likelihood team members are doing work that will result in value in the shortest amount of time possible. Kanban systems elevate constraints and force the team to address them before they can bring additional work into the queue.

For a great visual representation of this whole process, go visit Henrik Kniberg’s blog post… One Day in Kanban Land.

Reasonable Division of Labor

Some teams that encounter a Kanban board for the first time note that the columns seem to reflect a waterfall style process mapping. The reality is that requirements have to be analyzed and designed before they can be built and tested. The problem with waterfall is that teams work in large batches, doing all of one phase before beginning the next. In traditional methods, there is typically a high degree of specialization amongst team members and an excessive number of handoffs between teams as work moves through the system.

The Kanban board acknowledges the phases a backlog item must go through in the development cycle, but like mainstream agile, encourages small independent user stories that are developed in small batches. The columns on the Kanban board do not represent strict hand-offs between team members but more the feature’s state during that time in its development lifecycle. While Kanban teams can accommodate a reasonable division of labor, Kanban teams are still typically made up of specializing generalists. Having specializing generalists on the team reduces skill-set dependencies and levels the flow of work across the team.

Kanban, like Scrum, leaves it to the team to decide how work moves through the system and doesn’t explicitly assign work to an individual with a specific skill-set. The Kanban board does acknowledge the reality of intermediate development states, and through the use of work in process limits, explicitly controls the amount of work in each state. This allows work to be managed, helps identify constraints, and provides visibility so the team can determine which impediments should be dealt with next.

The next post in this series will address going iteration-less and replacing velocity with cycle time. We’ll close after this next one with some thinking about when you might consider using Kanban and maybe even introduce some advanced contexts I find particularly interesting.