[Editor’s note: I was surprised to realize that I had never written my own list of kanban myths, probably because so many other good ones exist. But here’s my take.]
Like the one about George Washington, myths about kanban persist long after evidence to the contrary. Before I list some of them, I’ll start with a few connotations of kanban, since I think that most of the myths stem from a misunderstanding of kanban. Of course, I’ll happily work to understand your own connotation of kanban. As for me, when I talk about kanban, while I respect all of the following connotations, I really consider only the first two to be valid and the latter two to be shallow or incomplete:
- (Valid) A pull system enabled by virtual kanbans which signal capacity and create flow, reduce overburdening and yield other benefits.
- (Valid) A method for defining, managing, and improving services that deliver knowledge work, such as professional services, creative endeavors, and the design of both physical and software products (a.k.a., Kanban Method).
- (Shallow or incomplete) A work board (analog or digital) that makes knowledge or intangible-goods work visible. Since the intangible-goods context derives from the physical kanban system of tangible-goods manufacturing, though, the kanbans are really virtual in these environments. The tickets on these boards are signals of demand, not capacity (which is what kanbans indicate). Therefore, any board that doesn’t have pull signals (indicated either by an explicit work-in-progress limit or a space-limited area) really shouldn’t be called a kanban board. It’s probably only a work-visualization/management board or, simply “work board.” At best, I would consider this a “proto-kanban” board.
- (Shallow or incomplete) Continuous-flow-based delivery or timebox-decoupled delivery cadences, or “Scrum without Sprints.”
All right — on to those myths of kanban, or what kanban is not:
- Kanban is advanced agile, and it’s better to start with Scrum: See Don’t mistake adoption patterns for maturity patterns.
- Kanban needs all work items/user stories need to be similarly sized: I’m not sure how this one got started, but it’s simply untrue. What about a pull system necessitates that the work be the same size? (I won’t even ask how you know that your non-repetitive work is even of a knowable size in the first place.)
- Kanban teams don’t have a sense of urgency: If by “sense of urgency” you mean that at the end of a sprint, everyone rushes to complete tickets, resulting in overburdened workers, shoddy quality and unintegrated work, then it’s true that kanban doesn’t create this sort of environment. If you mean clarity of expectations (in the form of service-level expectations and explicit policies), guidance on how to handle work based on a customer’s needs (in the form of classes of service), and a focus on flow that enables getting things done, then this claim is false.
- Kanban teams can do whatever they want and don’t require discipline: I find it to be just the opposite in reality. Teams that otherwise fancy themselves disciplined and/or “agile” often somehow can’t summon up the basic discipline to implement WIP limits to create a simple pull system. Teams who use Kanban Method are by definition continuously improving, because they “agree to pursue improvement through evolutionary change.”
- Kanban is only for x work (where x usually means ops or support): Kanban allows us to see how our work works, creates flow and reduces overburdening. If you have work for which you don’t desire those benefits, then this might be true. But why would this myth be perpetuated? Perhaps because kanban originated in repetitive-task work environments (e.g., automobile manufacturing), unimaginative people assumed that it couldn’t be applied to the modern unique product development world (another flavor of mistaking adoption for maturity patterns). The question I usually ask is “What about kanban leads you to believe it can’t be applied in your current context?”
- Kanban is useful only at the team level: Flight Levels demonstrates and the Kanban Method elaborates that wherever work is being planned and delivered, kanban is applicable. As Klaus Leopold writes, “teams are usually part of a larger organizational context, which means that the topic of WIP limits should also be understood in this larger context. If the overall company performance — the business agility — should improve … you must limit the work where you want the effect, the value and the benefits of WIP limits to be realized.”
- Kanban and Scrum are mutually exclusive: Depending on what you’re referring to, this one may be only half wrong. It’s true that kanban is born out of a different paradigm and philosophy (e.g., pull vs. push, adaptive and evolutionary rather than prescriptive). But kanban in the pull-system sense is certainly something that many Scrum teams benefit from. And taking the Kanban Method as the “start where you are” approach to improvement, if your starting point is Scrum, you can certainly design a kanban system to wrap over it and improve service delivery.
- There is no commitment in kanban: Well, technically, there’s no “commitment” in Scrum, if you want to go down that road. Again, it comes down to what you mean by “commitment” and of course what you mean by “kanban.” I suspect that people who make this claim aren’t really using kanban systems but rather define kanban by one of the two shallow connotations above. In reality, kanban allows teams to make informed forecasts and improves predictability, thereby allowing everyone in the system to make better and more-informed commitments.