big

NOOP.NL | The Creative Networker

Some Day Kanban Will Fail 75% of the Time

09/03/2010

Ship Yesterday I had a bit of an argument on Twitter about differences between Scrum and Kanban. Personally I don't care which is better than the other, because I believe that all models are wrong, but some are useful. And both Scrum and Kanban can be useful, given a certain context.

In yesterday's keynote speech at the Scrum Gathering in Orlando Jeff Sutherland said he had seen teams that were "doing Scrum" while they didn't even have a backlog. And there are reports of "Scrum teams" not practicing daily standup meetings, and teams not delivering a new product release every week.

These are not Scrum teams. They are ScrumBut teams. They do Scrum, *but* without some of the key ingredients.

Unfortunately, some people arguing against Scrum include these ScrumBut teams in their evaluations of the "high failure rate" of Scrum. They love quoting that "at least 75 percent of Scrum implementations fail." And I think "Yes of course, 75% fails when that includes the teams that don't understand what they're doing."

I believe that right now Kanban doesn't suffer from this problem. Kanban doesn't have a high failure rate because Kanban is still at the start of its adoption curve. Only very smart people like David Anderson and Karl Scotland are practicing it. And they know how to do it right!

But just wait a few years and see. When idiots like me get their hands on Kanban, we will start implementing KanbanButs, but we'll be calling it Kanban. We will have absolutely no idea what we're doing, because value stream mapping is not as simple as story point estimation. And we will introduce "Kanban teams" without limited WIP, or "Kanban teams" without a vizualized workflow.

Then the world will see a 75% failure rate of "Kanban" implementations.

And then there will be a great new software development method called Bonkiborki (which is the Mongolean word for 42). And I will have invented it. And it will have a much higher success rate than Scrum and Kanban, because I will be the only one who knows how to do it right.

(image by Misserion)

Twitter TwitterRss SubscribeEmail NewsletterLinkedIn LinkedInSlideShare SlideShare

Latest, greatest and favoritest posts:

Yes, Good Managers Are Manipulators

Reduce Your Fear, Increase Your Status

Planning for Feature-Complete Deadlines

This article is written by on in Don't Read This. Jurgen Appelo is at Happy Melly. Connect with Jurgen Appelo on .

This article was posted in:

  • http://www.zacharyspencer.com Zachary Spencer

    So what you’re saying is, 25% of the time, it works all the time?
    I find it interesting how the adoption of a process contributes to the devaluation of said process. Maybe our focus as thought leaders shouldn’t be about process, but instead about people. Picking the right people, rewarding people, motivating the people, and educating people. After that, the process is merely a tool.

  • http://blog.gdinwiddie.com/ George Dinwiddie

    Good post, Jurgen. And I’d like you to teach me Bonkiborki. We can start a Certified Bonkiborki Master program to ensure that people do it right or can’t get hired. ;-)

  • http://www.leadingagile.com Mike Cottmeyer

    Totally agree. I think the Kanban community is leading with some very interesting practices and ways of thinking. It is valuable thought leadership, but not the next revolution in software development best practice… it’s not agile 2.0. I’d love to see us focus less on methodology branding and more on doing what’s right to deliver projects in our particular context.
    Mike

  • http://softwaredevelopmenttoday.blogspot.com/ Vasco Duarte

    I followed the discussion on twitter and must say that I was rather amused with the seriousness with which people claim that method X is better than method Y.
    This discussion alone highlights why Kanban and Scrum will ultimately fail, just like “old-school” project management has failed in software development.
    FWIW here is my take on the whole thread on twitter from yesterday. The main point: what we can learn from the failures and successes is much more important than the discussion on what method is “better” (whatever the definition of “better” may be).

  • http://www.westborosystems.com?origin=jurgen Dave Rooney

    Jurgen,
    Well said. Here’s an interesting post on the Kanban Yahoo Group from Nov. 2008 by David:
    http://finance.groups.yahoo.com/group/kanbandev/message/1062
    Specifically, this snippet is interesting:

    …while I have heard of agile teams that appear to exhibit high
    maturity behaviors – objectivity, use of leading indicators, low
    degrees of variability, and (maybe, just maybe) continuous improvement
    in a failure tolerant culture, I have not heard of one that existed
    without the direct leadership of one of the personalities in our
    community. At this point, it is impossible to take the “David” or
    “Jeff” or “Israel” factor out of the achievement of the high maturity.

    Dave Rooney
    Westboro Systems

  • Jason Reid

    Hmm, but some things are easier to do “correctly” than others. This is virtuous. If it’s easier to fall into ScrumBut than it is to fall into KanbanBut, that’s a fault of the more complicated process. And I think it will likely fail more often, no matter where it is on the adoption curve.

  • http://www.rajivnarula.com Rajiv

    Could you please reconcile this post with your previous post- http://www.noop.nl/2009/09/scrumbuts-are-the-best-part-of-scrum.html ?
    I know the objective of this post is different from the other post , but it could be confusing for some and it would be nice to see the loop in noop closed :)

  • http://blog.brodzinski.com Pawel Brodzinski

    Well, KanbanBut is already started. In our team we’ve started Kanban with no measuring lead time which basically means we threw out two third of the rules.
    We soon started measuring lead times which doesn’t change that at that moment I didn’t feel like it was important thing and would make the same decision again.
    After all it doesn’t really matter whether you’re 100% Scrum or 100% Kanban. What matters is whether you’re able to deliver good products.
    And I read your comments on ScrumButs and KanbanButs not only as “people will do methods-in-the-name-only and will fail and it will decrease success rate” but also as “reasonable people will find their way to do a good job no matter which labels are pinned to methods they use.

  • http://www.management30.com/profile/GeoffreyLowney Geoffrey Lowney

    That is an interesting observation (about the seemingly contradicting posts). From my reading of http://www.noop.nl/2009/09/scrumbuts-are-the-best-part-of-scrum.html, Jurgen is saying he likes that Scrum (and other true agile methodologies) allows for the methodology itself to be modified by the self-organizing teams. I agree this is a strength of agile methods. But in that post Jurgen implies ScrumBut teams understand the methodology, and modify it by the reasonable application of logic.
    This post, on the other hand, seems to be saying many “ScrumBut” teams are making changes to the methodology without understanding it. They skip key ingredients without adjusting anything else to compensate for their loss. Those ad-hock changes, made without understanding the consequences, lead to higher failure rates. In this case, you could argue these latter “ScrumBut” teams are not actually ScrumBut teams (as defined in the previous post).

  • http://softwaredevelopmenttoday.blogspot.com Vasco Duarte

    @Jason Reid
    it’s not easier or harder to fall into a bad implementation of one method of the other.
    The point is that if you have a population large enough (like we have with Scrum now) there will always be plenty of failed implementations.
    Kanban implementation failures are just less known (and less frequent) now, but if Kanban is a success those failures will also be visible and others will start claiming that Kanban is this or that. Well, they will be wrong!
    The method is irrelevant. There is no silver bullet!

  • Jason Reid

    @Vasco Duarte
    There are many different kinds of failure. For example, there is fast failure, and there is slow failure. There is obvious failure, and there is hidden failure. Some kinds of failure is very costly (bad), and some failure provides a great learning experience at a low cost (good!).
    I have a strong suspicion that Kanban and Scrum are different enough that they will present significantly different failure profiles. And one will probably be more costly, in general, than the other.
    I don’t have a crystal ball to predict what is going to happen. I’m just saying that it’s not a foregone conclusion that “One day, Kanban will be failing just like Scrum does.”

  • http://www.jasonosgood.com Jason Osgood

    There’s now a software development methodology based on kanban? Seriously?
    Scrum “methodology” is a tacit admission that you have no idea what you’re doing. In sports, it’s called forfeiting. In comics, it’s called Calvin Ball.
    So then what’s kanban? I couldn’t even guess. I pull work units from you? Should I write all the 1′s and 0′s on 3×5 index cards?
    I wish I could say this is the stupidest thing I’ve ever heard.
    Ever hear of “code smells”. Agile methodologies is kind of like that. It’s useful as a full conversation stop. Hear someone prattle on and on about “agile” this and “agile” that, and you know to politely excuse yourself to go get yourself another drink. And hope to hell the next rube has something interesting to talk about. Like macrame or the weather.

  • http://PMToolsThatWork.com Bruce Benson

    My message has long been that if you know what you are doing, just about any method will work well. Any. I’ve taken many waterfall organizations and – using waterfall – jumped them up to regular on time delivery with good quality. I’ll admit that an awful lot of the management tweaks look kind of agile, but we’ve been doing these agile like techniques before agile manifested :-).
    While I love scrum and agile methods, my initial diagnostic for any organization is unsurprisingly still the same: are you delivering on time with good quality? We then usually take whatever they are using and help them move up the “maturity level” of that methodology.
    The vast majority of the time the overall methodology is pretty irrelevant. Usually … often … just about always, it is a huge mismatch between the promises made and the capabilities of the team. In *every* case where we’ve aligned the promises with the capabilities (i.e., good estimates) delivery “suddenly” started to be on time and quality improved – *often* dramatically.
    The inherent capacity of each methodology may be different but I suspect it is not larger than the normal noise found in management. In other words – done right – an agile methodology and a waterfall methodology would not significantly outperform the other – except possibly in specialized niches. (I’d like to see someone attempt a study on this, maybe using something like Big O notation to analyze the fundamental processes).
    For anyone who has watched methodologies come in and go out of favor, all this discussion looks very normal.
    Bruce Benson
    http://PMToolsThatWork.com

  • Dutch

    Implementing agile princples via Scrum, Xtreme programming, Kanban or other agile methods contribute to a higher likelihood of success. These methods are not sole guarantees for success.

  • http://www.parallelprojecttraining.com/public-apmp-training-courses/events Parallel Project Management Training

    Interestingly I have just had a similar discussion about the difference between Scrum and Project Management. Some people had very strong views that SCRUM was just a passing fad. The conclusion was that SCRUM is just another part of the Project Managers Body of Knowledge. It relevance to a particular project depends on the type of project and the culture of the organisation in which the project is being delivered. I would welcome your comments at http://blog.parallelprojecttraining.com/project-management-articles/what-is-the-difference-between-and-project-manager-and-a-scrum-master/