When is Kanban not appropriate?
Kanban is a project management methodology derived from a manufacturing process. Problems with Kanban are likely to arise when the process you are managing isn’t quite a perfect fit. For example, support is usually a good fit for Kanban. But there are always issues that need more creative solutions. These are often handled with a parallel process better suited to bigger tasks. Or you can bend the rules a little. Call a task done when it has failed. And create a new series of tickets to address the more complex situation that arose. You might use a special ‘swim lane’ for longer-term issues. However, as long as you pay attention to Kanban disadvantages as well as the advantages it is a very usable process.
#1 Requires Process Stability
Kanban shines in a factory-like process with stable, repetitive production pipelines. Tasks pass through many states at a steady rate. It can’t cope with a task spawning many new sub-tasks and needing to stay on hold for weeks. A good example of this I have seen is an IT dept ordering and setting up new laptops. Complicated systems like a Linux developer workstation can cause problems. And tend to get prioritized lower because of this. This is a problem because the more complex requests are often the most important. While the standard laptops are well served being ordered and set up on a Kanban board, the non-standard requests throw off all your KPIs and require fudging everything.
#2 Lack of explicit iteration
When a card reaches the end of the board the task is complete. There is no allowance for it being a good first attempt that needs refinement. This doesn’t work well in creative tasks. You can attempt to add more to the process. I’ve seen asset creation tasks categorized as ‘placeholder’, ‘first-pass’, ‘second-pass’ and ‘final’. But things always need yet another pass. You can tell if you are running into this problem when you add a review column. A quality check is fine, but an invitation to iterative review suggests your problem might not be well suited to Kanban.
#3 Not updating the board
Updating a board seems like it should be easy. But in practice, updating the board needs to have a strong focus. Someone should be responsible to make sure the board is always up to date. Often people can manage their own tickets. But, particularly when other problems are also present. the board is left to rot and the whole process derailed. A daily status meeting is a good time to ensure the board is current at least once a day.
#4 Too simple board
In its simplest form, Kanban has just three columns, ‘todo’, ‘in-progress’, and ‘done’. What you have here is a to-do list with an in-progress state. You aren’t really getting much benefit from knowing what part of in-progress your task is at. You can’t track which stages take more time or are introducing quality problems. A factory assembly line is characterized by having specialists for each step and many steps in the process. We improve by optimizing each step.
#5 Over-complicated Board
On the other hand, as we add more stages and complications things tend to get lost. If new team members don’t understand the board in a few days it is a red flag that something isn’t right. Multiple swim lanes are also a good indicator of this. Maybe your team does too many different kinds of tasks for Kanban. One solution to this is to try and split teams, reducing how many different things one team member could be asked to do.
#6 Lack of time representation
How long a ticket has been on the board isn’t generally represented. I have seen sticky colored dots used to show time passing. There is the assumption that a task ‘in progress’ will move to ‘done’ soon. If it will actually take months then daily meetings to look at tasks become a bit silly. This can be fine for one or two tasks, but not too many. Some people create a ‘blocked’ swim lane. But if it happens too often you lose the nice feeling of progress you get when a ticket is completed.
#7 Unenforced WIP limits
Work-in-progress limits try to prevent having too many cards in a single state at a time. But very often these don’t trigger the important refactoring of the process that hitting your WIP limit should. If for instance, too many tasks stack up in acceptance testing you may need to hire more testers. The common failure mode here would be splitting into groups and one group calling a task done if sent to test. Then you are not measuring the cycle time to a tested published feature and there is a lot of scope for fudging KPIs.