BT

Myths of Kanban

by Dan Puckett on Jan 24, 2011 |

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?

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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...

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.

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. :-)

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.

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.

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

6 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT