In Kanban, we set Work in Progress (WIP) limits so that we can easily visualize when bottlenecks occur in our workflow. This is explained in the blog, https://kanbanmentor.com/how-kanban-helps-visualize-and-remove-your-bottlenecks/. But, what should you do when you hit one of these bottlenecks? This blog discusses options for when your Kanban team hits a bottleneck.
Example of a bottleneck
Let’s assume, for example, the following board:
This represents a situation where a developer completed item S and wants to move it into the Ready Test column to indicate that it is ready to test. However, the Ready Test column has a WIP limit of 2. This is an indication that Testing is not keeping up with Development. Therefore, there is a visualize signal that Ready Test is at its WIP limit. Most tools will automatically flag the column red or give some indication that the WIP limit has been reached. But even a manual board containing sticky notes on a wall will show when a WIP limit is reached. As soon as this happens, or minimally at the next Daily Meeting, the team should discuss what actions they want to take.
Kanban bottleneck options
This following table depicts the 6 options I could think of. Of course, there may be other options and is dependent on the specific issue for this particular team.
| Option | Explained |
| Hire more testers | If testers cannot keep pace with the developers then one option is to hire more testers. Of course, this option only makes sense if the team were sure that this is a persistent issue.
A similar resolution might be to move testers from another team to this team if testers were readily available. |
| Developers help testers to get caught up | Assuming this bottleneck is not a persistent issue then hiring more testers would probably not make sense. A simple solution in the mean time is for the developers to help the testers get caught up whenever the WIP limit is hit.
If the bottleneck continues to occur then a decision will need to be made whether this is a good long term solution or if one of the other options makes more sense. |
| Fewer developers on the team | Perhaps the issue is not that there are too few testers but rather than there are too many developers on the team.
Consider moving developers to a different team – ideally one that has the inverse bottleneck where testers are starved for work. |
| Figure out a way to automate test (e.g., creating automated tests) | Creating automated tests may relieve the testers from getting overwhelmed with too much manual testing. In a perfect scenario it can eliminate all manual testing.
This option is just one example of implementing an option using technology or process change to eliminate the bottleneck. The team should brainstorm other approaches along this line. |
| Do nothing for a little while and see if problem continues | An option is always to ignore the bottleneck. If the bottleneck rarely occurs then this may be fine. If the bottleneck continues to persist or if the bottleneck causes too much development work to back up then this will not be a reasonable option. See the blog https://kanbanmentor.com/how-kanban-helps-visualize-and-remove-your-bottlenecks/ which discusses dangers and consequences when bottlenecks are ignored. |
| Adjust WIP limits | Perhaps the issue is that the WIP limits initially agreed upon by the team are wrong. If modifying the WIP limits allows work to smoothly flow through the system without too much development ever building up then this is a reasonable option. The team could always initially adjust the WIP limits and continue to monitor how well work is flowing through the Kanban board. |
Kanban enables discussion
Kanban does not magically fix these problems for you. It gives teams very simple visual tools to enable discussions to take place as soon as bottlenecks occur. The team can then take whatever actions they believe makes sense in order to get products to the customer in the most efficient manner.