Kanban literally means “sign board” in Japanese. So, every Kanban team has a Kanban board that depicts the team’s workflow tracking all work from the initial inception of ideas all the way through to turning these ideas into a valuable product for their customers. The construct of a team’s Kanban board depends on the workflow of the team which could vary greatly from team to team. Kanban is more than just a visual board. One of the simple, yet powerful, components of Kanban are Work-In-Progress (WIP) limits. By setting WIP limits on the board, teams can easily see when bottlenecks occur. Bottlenecks cause us to slow down – we are not producing value to our customers as quickly as we can. This blog discusses how Kanban helps visualize and remove your bottlenecks.
Example
The following picture depicts what a typical Kanban board might look like for a software development team.
For more information on how to initially set WIP limits, please see the blog, How do I initially set WIP limits?
Continue pulling items if below limits
So, how do WIP limits work?
Kanban team members pull work from left to right as long as the column is below its WIP limits. In the example above, let’s assume a developer completed work on item R. Since Ready Test has a WIP limit of 2 and only one item (Q) is in that column, the developer can move R to the Ready Test column. Now the developer can pull item X in to the In Dev column since In Dev is still under its WIP limit of 6. Work continues to move freely from left to right as long as no bottlenecks occur.
What happens when a bottleneck occurs?
But what happens when a column is at its WIP limit as in the diagram below?
In this example, a developer completed item S and wants to place it in the Ready Test column. This should raise a red flag that the Ready Test column is beyond its WIP limit. It is a signal to the team that testing is not keeping up with the pace of development.
At this point, the team should focus on removing the bottleneck. Please see the blog, What do I do if my team hits a bottleneck? for more details on actions the team may take. By not allowing work to continue to pile up somewhere in the middle of the workflow, completed items are getting to the customer sooner. This is one of the key benefits of moving to a Kanban model. That benefit is only realized if the team sets WIP limits and addresses bottlenecks as they occur.
What if bottlenecks are ignored?
What happens if the team ignores WIP limits and allows work to pile up? Not only does work not get to the customer, but there are other potential consequences. As an example, let’s assume you are in the business of making square-shaped widgets. Your testers cannot test as quickly as the developers can build these cool widgets. But the developers keep cranking out square widgets knowing that eventually the testers will catch up. Moreover, the developers do not want to help test as they love developing. So they continue to “locally optimize” by continuing to produce as many developed square widgets as humanly possible.
Now lets assume that the market changes and customers desire circular-shaped widgets because, lets face it, these circular widgets are much cooler than the old square ones. Suddenly this change in direction leaves a pile of square widgets for which we do not know what to do. Do we shelve the untested squares in case they come back in style? Do we go ahead and test them so they are complete? But we know they are a lower priority than working on circular widgets and may never be used again. Or do we just throw out the partially completed square widgets and chock it up to wasted effort?
If the team had stopped developing the square widgets when they initially reached a bottleneck and focused on fixing the bottleneck as the top priority, the team would not be in this dilemma.