Misconceptions about Kanban
There is an enormous amount of confusion and misinformation about Kanban. This article will clear up some of the major misconceptions that surround this topic. Let’s go through them one by one.
You have to choose between Kanban and Scrum
The most common misconception I’ve found is that people think you have to choose between Kanban and Scrum. This question is being asked and answered all over the internet right now.
Of course, it is a misconception, because the two are not incompatible.
Scrum is a product development framework. It is a system that defines roles, rules and artefacts that allow a small team to define and structure the work required to build and enhance a product.
Kanban is a system for controlling, limiting and eventually improving the flow of work through a system. Kanban concepts can be applied to any type of work – Scrum product development work, service management work, even traditional project management (AKA Waterfall) work.
Yes, Kanban can be applied to a Waterfall project. If there is work flowing through a system, Kanban can be applied. There’s nothing that says it has to be “agile” or “Scrum” – or not!
You can’t do sprints with Kanban
Another common misconception is that you can’t do sprints if you are doing Kanban – further reinforcing the “Kanban vs Scrum” myth. Kanban is a system that can be applied and overlaid upon any existing structure of work.
Now, many experienced Kanban practitioners move their system towards a “continuous flow” model, which does not have formal sprint boundaries. But if you’re starting off with Kanban, there’s nothing saying you can’t be doing it within sprints.
Kanban is only for production support
Another common misconception is that because Kanban does not have sprints (again, not true), it is not good at forward planning. And so it should only be used for production support, not development.
This is not true and based on other misconceptions. Kanban can be applied to any product system that has work flowing through it, whether it be support, enhancement, maintenance, development, and so on. It can be used for small or large projects, software work, manufacturing work, inventory management (where it came from), or service provision.
Explicit policies mean Kanban is rigid
Some people think that because Kanban required policies to be explicit, that they must, therefore, be rigid and carved in stone. Nothing could be further from the truth.
Kanban is about process optimization and continuous improvement. Making policies explicit is important: it ensures everything is transparent and agreed to, rather than the hidden rules and secret loopholes that govern many organizations.
But just because a policy is explicit doesn’t mean it cannot be changed. Policies and should change as the team learns and improves. Kanban just requires that whatever the latest policies are, are explicit and communicated transparently.
Kanban is all about visual boards
Some people think that Kanban is synonymous with visual management boards (or VMBs). They conclude that if you have a VMB, you’re doing Kanban, and if you don’t, you’re not. This is not true.
Visualising work is often an important step in the Kanban journey since it helps teams immediately spot queues, blockages, overloaded people, unattended work, and so on. Setting up a VMB is therefore often one of the first things a team will do when starting out with Kanban.
However, having a VMB does automatically mean you are doing Kanban! If a team does nothing about the problems on their board, they are not doing Kanban.
The real objective is Kanban is not to visualise work, but to improve it. And this is done fundamentally by two practices:
- Pull instead of push work
- Limit Work in Progress (or WIP).
If a team is pulling work instead of having it pushed on them, and if they are controlling their work in progress through WIP limits, they are doing Kanban. Even if they don’t have a board (though they probably will).
Kanban is easy to master
There is a misconception that Kanban is a “light” or “simple” system, best suited for teams that are finding Scrum “hard”. They think it is some sort of cheap “shortcut” or “hack” to get results without going through the pain of Scrum.
There is actually a nugget of truth here. Kanban is much easier to begin with than Scrum. Moving to Scrum requires major changes in how an organization structures teams, releases software, funds work, and so on. Many companies don’t, won’t or can’t make these changes, and just assign people Scrum role titles and leave it at that. This, of course, leads to “Scrumfall”, “Cargo Cult Agile“, “Zombie Scrum” and other horror movie titles.
Kanban is much easier, to begin with. You start by not changing anything and simply visualising the work that is in the system. However, it is a gross mistake to think that there is nothing more to it than that.
Moving properly on the Kanban journey will eventually involve many radical changes to how work flows through a system. Kanban is a system of continual change and improvement. Some of these, such as moving from a Push to a Pull system, will be just as difficult as some of the changes implemented by Scrum.
However, Kanban implementations may often be more successful in the long run because of the more gentle learning curve. Kanban leaves the more difficult changes until later, after teams have achieved some successes and built confidence in Kanban.
Conclusion
I hope this article has cleared up some of the dangerous myths and misconceptions that surround the topic of Kanban! Please let me know your thoughts in the comments below.
