Alan Shalloway has made a list of what he calls "common myths" about Kanban. His list includes the following items:
[...]
- Lean Development is a prescriptive approach to work in social systems
- Kanban suggest linear work and requires too many handoffs
- Explicit policies are static, hard to change and/or inflexible
- Kanban has been successful because it is being done by early adopters
- Better to start with Scrum and then start with Kanban
- Kanban doesn't respect people as much as other agile methods
- Kanban doesn't attend enough to people
- To make great changes you need to be revolutionary while Kanban is evolutionary
- Kanban is Scrum without iterations
- Kanban is mostly good for support
- Kanban results in teams not changing
- Kanban cannot work because explicit policies make no sense in the Agile world
Shalloway does his best to dispel some of these myths on his "Myths of Kanban" page.
Alan Dayley cites a myth about responsiveness:
The myth I have run into most is around WIP limits."Kanban decreases the ability to respond to our customers quickly if we are already at our limits."
Adam Sroka has a myth about timeboxing to add to the list:
The one that I keep getting is that Kanban == no timebox.Some people see this as desirable (usually because they think that two-weeks is too short.) Others think this means that we will lose discipline.
Either way they are wrong. Our cadence may not happen to be two-weeks, but we would like to have one and know what it is. We don't impose a timebox artificially, but we do measure how long things take and try to minimize them on average.
Matthias Bohlen characterizes this quote from Ken Schwaber as a myth about Kanban: "God help us. People found ways to have slack in waterfall, to rest and be creative. With Lean and Kanban, those hiding places are removed. We now have a progressive death march without pause." Bohlen responds:
There is no such thing as a "progressive death march without pause". People can go for a pause and have coffee whenever they feel the need. They rest whenever they decide to do it. Kanban does not exploit people more than any other method because Kanban is no method—the work is done using the existing method that the team has in place. Kanban is something that makes the work more transparent but it is not a method in itself. It is a non-method, if you want (at least, that's the way I see it).Kanban is the opposite of a "progressive death march without pause". Imagine a team of acceptance testers—its duty is to help the product owner find out whether the backlog items have been implemented correctly. What happens if the entire test team gets the flu? The developer teams have a WIP limit that is now reached because the testers are sick and do not pull readily developed stuff away from development into acceptance test. So, stuff remains "in development".
Now what next? The developers respect their own WIP limit and stop developing—they take a rest! They read books, go for a training, refactor their software, learn something new that they always wanted to learn, and so on... When the testers recover from the flu and get back to work, they will find that there is no additional pile of work created by the developers in the meantime! No "death march" at all—they simply resume their work and pull items away from the developers. And, the developers resume their work, the line starts to flow again.
Are these "myths" about Kanban really myths? What myths about Kanban have you heard?