I see Lean/Kanban as mostly a re-packaging and branding/sales effort. David’s success doing what worked for him in a specific context has been badge an re-sold as “best practice” for everyone everywhere. He as as much as admitted so in the past.

To me as far as I can tell, the leading Kanban practitioners are doing Agile. Agile as always been a broad church, from DSDM to FDD to XP. I see Kanban as practiced by people like Rob Hathaway as fitting into this tradition.

What makes all these things Agile? Accepting complexity and adapting to change. As many have said here, I think you would be better off describing your actual practice what you do, when and where it works, and why it works. I don’t think the branding helps. This will add to the broad pool of Generic Agile knowledge. The best practitioners don’t follow a brand, they pick and choose ingredients from where ever and apply them as applicable. I don’t see that changing.

As for Lean. It seems to be all things to all men On a more concrete level, we can study Lean product development and Lean Manufacturing. We have known about these things for a long time now, and have borrowed from them much in the past, but it should be needless to say that neither of these things are Agile. Agile goes beyond questions of efficiency and addresses the effectiveness of teams in an unordered, complex and changing world.

Of course re-stating Agile using new “Lean” language may better help some understand it. But we should be sure to “re-state” rather then “replace”, otherwise we will merely be turning the clock back and going over old ground.

I’d rather move things forward… I sense you do too.

Paul.

http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf

There are teams that do Kanban as Karl or David would describe it in a conference presentation: no iterations, straight to release, no estimating, measure their flow and so on.

Then there are teams who are trying to do Kanban, but they have warts. Perhaps they still need to estimate, perhaps they can’t measure their flow, or perhaps they still do iterations. Maybe it looks more like ScrumBan.

If you want, replace “pure” with “by the book” – is a prerogative term I know.

Usually there is some truth behind the headline.

For me one of the strengths of Scrum has been that it is relatively well defined. While “agile” has come to mean just about anything you want it to it is quite clear what Scrum is, and is not.

While Scrum and Kanban may have similar roots and underpinning theory they are different. To say Kanban is a renaming of Scrum shows a mis-understanding of Scrum, Kanban or both.

Try this: apply Bas Vodde’s Nokia test to a Kanban team
- No iterations in pure Kanban, that fails part one
- No concept of a product owner or backlog in Kanban, they may exist but they are not mandated (as they are in Scrum)
- No estimation in pure Kanban
- No burndown charts, cumulative flow yes, burndown no

Finally disruption: heck yes, Kanban teams I’ve seen are disrupted all the time. Scrum seeks to create undistributed times, that concept seems lacking in Kanban.

Of course between Pure Scrum and Pure Kanban there are a lot of variations and this is probably the space Cope is thinking of.

I do have a minor issue, though, with relabeling Kanban as a software development methodology… I sometimes wonder if David Anderson regrets calling his Corbis stuff a “Kanban system for software engineering” because we (the community) shortened it to just Kanban and that name stuck. Anyway, I digress.

On a more serious tone, I also have an issue with teams adopting Kanban for the wrong reasons, i.e. because another methodology revealed a dysfunction, it started to hurt, and Kanban offered a quick fix. Statements like, “in this Kanban thing we don’t have to estimate”, or, “if we do Kanban then nobody needs to become a generalist and all that feature team crap goes away.” Hearing people say things like this (and being somewhat serious while saying that) makes me a sad panda. There’s great value and a powerful improvement mechanism behind the (unfortunately named) method we call Kanban.

Finally, I’m always happy to see discussions about Scrum and Kanban, their different approaches and fundamentals, without unnecessary and unproductive FUD and expletives.

Thanks, Karl, for blogging this.