big

NOOP.NL | The Creative Networker

In Defense of Scrum (Please Stop Pissing on It)

08/02/2010

Manneken_pis Last week Uncle Bob Martin wrote about seven “serious flaws” in Scrum. I usually agree with Bob, but not this time. Actually, I might even feel a bit sad about all the <method>-bashing I see happening in the Agile world, where all too often <method> = Scrum and the bashing comes from either the XP side or the Kanban side.

Here’s my take on the matter…

“Scrum has no technical practices”
The lack of technical practices in Scrum is a strength, not a flaw. It means Scrum can be (and has been) applied successfully not only in software development, but also in design, marketing, and several other creative domains. As far as I know Scrum has always been presented as a framework, meaning that it must be augmented with domain-specific practices. True, some software teams forget about the technical practices, and they are idiots! But is it a “flaw” of the script writer when the director forgets to use stunt doubles when filming the dangerous scenes? Or is that a failure of the craftsman who apparently doesn’t know how to do his job? If you call it a “flaw” that Scrum has no technical practices, then you can only conclude that Lean and Kanban are seriously flawed as well! Obviously this is a bit silly. To me this flawed reasoning seems like a bad case of tunnel vision. There’s more happening in the world than TDD, Continuous Integration, and Pair Programming. Really! (BTW, it is interesting to see praise on the Lean side for Bob's criticism of Scrum, while Lean and Kanban have no technical practices whatsoever! The few described in Lean books are simply copied from XP…)

“The Scrum Master arrogates project management powers”
Maybe, but it’s a risk worth taking. A much bigger problem I see with teams without a Scrum Master is that they are usually an undisciplined bunch of mandrills. XP requires and assumes that teams consist of self-disciplined, competent, and communicative people. Unfortunately, many software developers don’t fit this description. Scrum at least acknowledges that most teams need some help and assistance in getting their processes and communication in order. I find it particularly strange that people who call for craftsmanship on the technical side should point out the dangers of positioning a master on the process side! Honestly, I would rather run the risk of a Scrum Master taking up PM powers than a dev team completely ignoring their responsibilities. What is worse? (And yes, the sooner a team can do without a Scrum Master, the better. I don’t have one in my own team right now. For us there's no need.)

“Scrum provides insufficient guidance regarding the backlog”
See the first issue above. A backlog for graphic designers probably looks quite different from a backlog for developers. And marketers print their backlog horizontally and call it a road map. What’s wrong with keeping all the options open? Scrum is a framework, not a by-the-minute recipe!

“Scrum carries an anti-management undercurrent”
I don’t get it. How is that different from XP? Management has always been underrated in the Agile world. True, management has done badly before Agile. And we should be glad for the Agile movement and its self-organizing teams. But self-organization without governance is anarchy. This is not a flaw in Scrum, it is a flaw that began with the Agile Manifesto itself, which completely disregarded the role of management. And guess who co-wrote that? :-)

“Scrum doesn’t say anything about multiple teams”
True, and again: how is that different from XP, or any other agile methods? Allow me to quote John Gall here:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. – The Systems Bible, John Gall

Scrum is a small system. That’s why it works. It is specifically designed not to cover technical practices, complicated backlogs, multi-team projects, etc. They tried that with RUP, and they failed. Because a complex system designed from scratch won’t work. A big working system has to start as a small working system. This is not a flaw. It is common sense. And now that we know that (small) Scrum can work, we can learn how to make it grow…

And that's what I had to say in defense of Scrum. I really hope that people would stop pissing on it. No agile method is perfect. But I think there’s a world of difference between imperfect and "flawed".

Please note that I am not a CSM, and will never be one. I like XP and Kanban just as much as I like Scrum, because I believe no single model or framework is enough when managing complex systems. Anyone who favors one method and pisses on another is just showing off his ignorance of complexity thinking.

That's it. I hope to have entertained or annoyed you.

I will be speaking at the Scrum Gathering in Orlando. Hope to see you there!

Twitter TwitterRss SubscribeEmail NewsletterLinkedIn LinkedInSlideShare SlideShare

Latest, greatest and favoritest posts:
Management 3.0: The Era of Complexity
ScrumButs Are the Best Part of Scrum
The Complex Manifesto for Software Development

This article is written by on in Trash & Garbage. Jurgen Appelo is at Happy Melly. Connect with Jurgen Appelo on .

This article was posted in:

  • http://SoftwareDevelopmentToday.blogspot.com Vasco Daurte

    Good points. Those bashing Scrum do it for a reason, a very clear an undisguised jealousy for the success that scrum achieved.
    True, the success that scrum achieved also leads people in that community to bash other methods (like certain famous people saying Kanban cannot work for “beginner teams”).
    They are *all* wrong! Any method can work. Even waterfall…
    How soon people forget their own mistakes and repeat them over, and over again.
    To those criticizing Scrum, XP or Kanban: stop bashing and start publishing. We need more science behind this, we need to know what *really* works and what does not!

  • http://machielgroeneveld.nl Machiel Groeneveld

    Pissing on methods is quite useless. Pointing out observable ugly side effects of a method that often result from a dogmatic implementation is useful.
    Though you don’t need to understand complexity theory to use take a balanced approach to methods.

  • Angelo Anolin

    Nice point. More focus on people and what is the applicable framework/methodology/technology in addressing complexity.

  • http://www.silverstripesoftware.com/blog/ Siddharta

    Many of these things are not problems with Scrum per-se (except the anti-management one, which is inbuilt into scrum itself), but a lot of it is a consequence of the way Scrum training has been conducted, especially CSM.
    When a person takes an official certified training, the expectation is that they will be taught all it takes to be successful with the process.
    Technical practices are part of that. Building a backlog effectively is part of that. Management practices are part of that. Facilitation is part of that.
    Now not everything can be covered in a two day course. So offer other courses. Offer a official backlog management course. Offer a TDD course. Offer a facilitation skills course. Offer a customer collaboration course. Offer a scrum transition course. Doesn’t matter if these other things are not part of scrum, if it is a prerequisite to be successful with scrum.
    Then people who take one course know that they are learning about 1 topic out of 10 that they need to know to be successful.
    Right now there is one CSM course. It’s a 2 day training. It is official and certified. People take it, get a shallow understanding, and figure out that now they know everything they need to succeed. Then they run into big problems during implementation.
    I doubt people are attending CSM classes to learn how to use scrum to build houses or run a restaurant. So the training program should be tailored appropriately.

  • http://www.agilesavvy.com David Updike

    Spot on Jurgen. One could create equivalent arguments targeting XP, Kanban, FDD, DSDM, etc. Lightweight methodologies are…hmmmmm…lightweight, which means there are strategic holes left to be filled in by competent professionals who believe in and understand the Agile Values and Principles. As an Agile Coach I look at the Organization, the Team and the Backlog in order to make smart dynamic decisions on how to TUNE Scrum to the benefit of the Product, the Team and the Client. Complex Adaptive Systems require Scrum Tuning.

  • http://profile.typepad.com/unclebobmartin1 Unclebobmartin

    Jurgen, I wasn’t trying to compare Scrum to XP. XP has some of the same problems. Although XP does _not_ have the anti-management attitude that Scrum has.
    Nor was I pissing on Scrum. Not every criticism is pissing. In fact, some poor guy’s manager asked him for criticisms and how to address them. If he went back to his manager without any credible criticisms, his manager would have dumped the idea.
    All _real_ solutions can be criticized, because there are no perfect solutions.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Of course, the urinary qualification is just me drawing attention. :)
    The fact remains that you’re talking about “flaws” and “criticism”.
    I think it would be unfair to criticize a cooking recipe for having no instructions on how to operate your oven. That is not a flaw of the recipe, it is simply not its goal. You’ll need to learn how to operate your oven from a manual. (But the manual won’t teach you how to cook.)
    Lack of dev practices in Scrum is _by design_. It is not a flaw. Therefore I find this particular “criticism” of Scrum misplaced.
    And I regret that such remarks of “flaws” and “criticism” are too easily picked up by others to join in the chorus and beat Scrum to death.

  • http://profile.typepad.com/mfloryan Mfloryan

    Interesting Jurgen what your observations are because all the things you have mentioned in your post I have inferred from Bob’s email in the first place anyway.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    So you mean my post actually didn’t add anything new? ;-)

  • http://kevinontheweb.com Kevin Webber

    The ScrumMaster role is a bit too dictatorial for my liking. If you’re working with/for a benevolent dictator, things can be wonderful. But living under the reign of an evil dictator is a nightmare, and I’ve experienced this first hand. Don’t get me wrong, I think the spirit of the role is great, but companies need to really keep an eye on the individual in this position.

  • Olivia Jennifer

    Scrum study also has interesting ways to
    teach the students for

    agile scrum
    certification
    ( Scrum
    Master Certification
    ) courses. check their website for some free
    introductory course in scrum

  • Ella Mapple

    Becoming agile is associated with becoming good at technical practices. In Technical practices pattern, a team introduces standard XP practices first which later on other team adopts as they see productivity and improvements. It leads to more trust and improved collaborative relationship among different teams.