Kanban has existed since the 1940s. Toyota built it on the factory floor, and it delivered. Decades later, software teams picked it up; and somewhere along the way, a lot of well-meaning people got it spectacularly wrong.
Kanban is one of the most misunderstood tools in the agile toolbox. Not because it is complex, but because it looks deceptively easy.
The board is not the method and the sticky notes are not the process. And “just visualize your work” is not a strategy. Let us take the myths apart, one by one.
Myth 1: Kanban is just a board with columns
This is the most widespread and most damaging misconception. A board with “To Do”, “In Progress”, and “Done” columns is a whiteboard. Nothing more.
True Kanban is a pull system. Work moves to the next stage only when capacity opens up there. Without that constraint in place, you have decoration on a wall: a false sense of process with none of the substance.
Myth 2: Kanban has no rules
Kanban is often pitched as the “relaxed” alternative to Scrum’s ceremonies and prescribed roles. No sprints. No daily standups. No velocity targets.
What Kanban does have are Work In Progress limits – WIP limits – and they are non-negotiable. They are the engine of the entire method. Remove them, and you have not simplified Kanban. You have broken it.
Without WIP limits, Kanban is chaos visualized. With them, it is flow optimized.
Myth 3: Kanban means no deadlines
Kanban does not impose timeboxes the way Scrum does. Teams often read this as “Kanban teams do not commit to dates.”
That reading is wrong. Kanban teams rely on cycle time and throughput data to build probabilistic forecasts. Those forecasts are frequently more accurate than sprint velocity estimates, because they are grounded in measured flow rather than gut feeling and planning poker. Deadlines exist; they are just earned through data rather than declared through optimism.
Myth 4: Kanban scales to any team size without adjustment
Small teams thrive with Kanban. It is fast, lightweight, and demands very little overhead. This leads many to assume it scales without limit.
It does not.
As the number of teams grows, the interfaces between them become increasingly complex; and Kanban has no built-in mechanism for managing cross-team dependencies. Scaling Kanban properly requires explicit structures: Features, Epics, synchronized replenishment cadences, and cross-team WIP policies. Ignoring this is how organizations end up with seventeen Kanban boards, no shared direction and a total lack of coordination.
Myth 5: Kanban is only for software teams
Kanban was built for manufacturing. It has since been applied to HR, legal, marketing, hospital emergency intake, and airport ground operations; all with measurable results.
The method is process-agnostic. If work can be defined, tracked, and handed off, Kanban can add value. The sticky note turns out to be a surprisingly universal adapter.
Myth 6: Kanban replaces the need for planning
“We’re doing Kanban” has quietly become shorthand in some organizations for “we stopped planning.” That is not a compliment to Kanban. It is process abandonment wrapped in agile vocabulary.
Kanban reduces planning overhead by keeping the current state of work continuously visible. It does not remove the need to decide what comes next, in which order, and for what reason. That is still called strategy. Kanban supports it; it does not replace it.
Myth 7: A full board means the team is productive
A board where every column is packed with work items gives the impression of a busy team. It is not. It is a team with a flow problem.
In a well-functioning Kanban system, the board is largely empty downstream and carries a deliberate, limited queue upstream. Full columns signal blocked work, oversized batches, or: most commonly, absent WIP limits. Busy is not a metric. Throughput is.
Myth 8: Kanban is easier than Scrum
Scrum comes with explicit rules. You can read the Scrum Guide in an afternoon. If your team drifts from those rules, it becomes visible quickly.
Kanban is built on principles. Principles demand judgment. Judgment requires genuine understanding. And understanding takes considerably longer to develop than reading a guide.
Scrum is harder to start. Kanban is harder to do well.
Teams that move from Scrum to Kanban in search of less process tend to end up with less discipline, not less process. The overhead they cut was often the overhead keeping them accountable.
Myth 9: Kanban does not require retrospectives
Because Kanban has no sprint boundaries, many teams quietly drop retrospectives. There is no sprint to review, after all.
This is a mistake. Kanban explicitly calls for ongoing process review and improvement; the practice is called Kaizen, and it predates agile by several decades. The format is open. The cadence is flexible. But skipping it entirely is not Kaizen. It is stagnation with better branding.
Myth 10: Kanban is a destination
“We implemented Kanban” is a phrase that should not exist. Kanban is not a configuration you set once and leave running. It is a continuous improvement system. The board evolves. WIP limits are tuned. Classes of service are refined. Policies are written down, revisited, and updated.
The moment a team declares Kanban finished, it stops being Kanban and becomes a relic: a board that no longer reflects how work actually moves, kept alive by habit rather than purpose.
Kanban, practiced well, is a powerful and low-overhead method that builds clarity, surfaces bottlenecks, and improves flow without drowning the team in ceremony. But “practiced well” carries all the weight in that sentence.
These myths persist because Kanban appears simple from the outside. Its learning curve resembles chess: the rules take minutes to learn; the strategy takes a career to master.
The Modelithe method and its supporting tool allows for both a “true” Kanban implementation in addition to a “Kanbanish” implementation – even if that one might not be 100% Kanban. The world is not 100%, and many organizations don’t have sufficient knowledge to fully embrace even the best methods. However, Modelithe also allows Kanban to scale, through the synchronization points of Epics and Workpackages. The latter allows teams to collaborate and keep delivering at a predictable pace even if the Kanban board might seem crowded. The Epic Kanban board allows for a higher overview of what is pending, done and ongoing.
Take a moment to assess your own board. Are your WIP limits actually enforced? Do you pull work, or push it? Is your cycle time stable or drifting upward? And how long has it been since your last retrospective?
If those questions are uncomfortable, that discomfort is the most useful signal Kanban can offer.