Myths of Kanban

Posted by Dan Puckett on Jan 24, 2011

Sections

Process & Practices

Topics

Kanban ,

Agile Techniques ,

Lean ,

Agile

Share |

RELATED Research

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?

RelatedVendorContent

Five Key Practices to Agile ALM

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Agile Maturity Model Applied to Building and Releasing Software

Agile assessments for your team

Agile workshops and training

Related Sponsor

Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.

1. Back to top

   What software development should NOT learn from manufacturing

   by Udayan Banerjee

   There are hidden dangers of blindly migrating successful practices from manufacturing to software development - and that applies to kanban.
   
   setandbma.wordpress.com/2010/05/20/what-softwar...

   Reply

2. Back to top

   Re: What software development should NOT learn from manufacturing

   by Stephen Starkey

   Just as there are dangers of blindly rejecting an entire swath of practices because they happen to come from manufacturing.

   Reply

3. Back to top

   Re: What software development should NOT learn from manufacturing

   by Chris Matts

   Udayan
   
   You conclude in your article with...
   
   "What can we conclude from this?
   Reject all idea which is derived or borrowed from managing predictable processes.
   Accept all idea which helps you to deal with unknown and uncertainty."
   
   consider that there is a third way.
   
   "Grant me the serenity to accept the uncertainty,
   the courage to automate the predictable,
   and the wisdom to know the difference."
   
   There are aspects of software development that are repeatable and certain which should be automated. ( Automated testing or continuos integration )
   
   There are aspects of software which are currently uncertain. For these we should continue to tilt at windmills until we can isolate the uncertainty to its core. For this we should take inspiration wherever we can find it. However, we should not blindly map solutions from one domain to another. Most people in the Agile community are smart enough to know this. :-)

   Reply

4. Back to top

   Kanban IS good for support / operation teams

   by Augusto Rodriguez

   I won't say that kanban is *only* for support, but it does work like a charm for support / operation teams that usually get bombarded with changes.

   Reply

5. Back to top

   Re: What software development should NOT learn from manufacturing

   by Bill Long

   Thank you, Chris; you've inspired me to adapt your "third way" statement to my own neural patterns:
   
   Grant unto me
   the Serenity to Adapt to what remains Uncertain,
   the Courage to Automate what is Predictable,
   and the Wisdom to Tell the Difference.

   Reply

6. Back to top

   No timebox is wrong?

   by James Watson

   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.

   
   
   Isn't the whole point of timeboxing to put a hard limit on the time? It's confusing to me to read that it's a myth that Kanban doesn't have timeboxing with the explanation that it doesn't have timeboxing.

   Reply