WIP limit in Kanban forces the team to complete tasks before starting new ones.
Everyone think it's a must in Kanban, but let's go to the basics, why WIP limit is a thing?
Kanban exist to visualize and maintain the workflow. The mission is to move tasks as much rapid as possible through the Kanban board, from the todo-list (backlog) column to the delivered (done) column. Using the (human) resources at their best.
It seems the more parallel tasks we have, the more time we need to complete the average task.
If you want to get things done, focus is the key.
Focus isn't the only argument, imagine we have 100 stories that form a project, if all those stories behave to the same project or epic, it became clear we need all of those done to complete the whole project/epic. Apparently it doesn't have any differences if we start all 100 at the same time or if we proceed with one at time. What happens if we start too many tasks in parallel and something goes wrong? Easy, we could arrive at the deadline with many of them not completed. On the opposite starting few tasks and completing quickly before begin with new ones seems more reliable.
So the trick is just to start few tasks at time and move them through the board until they are done and then start new ones. Nothing really new, just use your common sense. Anyway It's a basic concept we can found in several agile frameworks like Lean and Scrum and somehow is inside the idea of building a "viable product".
At that point limiting the WIP column(s) seems to be a good idea to produce the desired effect. Developers are not allowed to start a new task when the limit is reached (or in general move a task in a full column), simple and easy, right? Indeed it is, it works. But...
We know the pros, but which are the cons?
- Limit-numbers are not easily predictable, a team is different from another one, and different projects could need different limits, and if the team became bigger or smaller it needs to reset all limits
- What if one dev comes really early in the morning and start several tasks reaching the column limit? Maybe he has reasons for doing that, but other devs will have hard times moving tasks on blocked columns. We need to introduce personal limits to fix this issue.
- What if we discover there is a task in the backlog that could solve some dependency? Or maybe is related to the one we are yet working on? Maybe we can easily work on both together, but limits doesn't allow to pull it. We have to sacrifice a probable efficiency to follow blindly the rules.
- What if something really urgents start blinking in the backlog while all the other columns are full?
- What if a dev get sick his tasks are blocked, should other devs finish his work or freeze it and don't consider it for limits?
- Or what if a task needs some interaction with the client and occupy a column for days until we get an answer?
- For reasons teams add limits also to other columns.
The point is not solve all the above points but just to get the whole picture: limit columns in kanban is not the best idea, even if it is a good one. Under those circumstances kanban became like a cage where devs struggle and get crazy. We have to remember we introduced that tool (Kanban) to facilitate the daily work not to create impediments.
In the following article I'd like to continue proposing a different approach: The Backward Kanban
