≡ Menu

Scrum Alliance Reflux

[Alternate Title: “If I have to talk about the Scrum Alliance any more, I’m going to vomit”]

Yes, I want this to die. But Jesse Fewell has posted some thoughts around the Scrum Alliance that in fact what they are doing is right, and correct, and they should fix the leaks and stay the course.

I’ll try to be brief with his arguments:

1) “The 75% failure rate of Scrum is one man’s hunch” – Um, no it’s not:

  • “Why there is such widespread failure is no mystery to us. We’ve been studying why Scrum works and doesn’t work for years”
  • “I’ve mentioned Scrum because when we see this problem, Scrum seems to be particularly common as the nominative process the team is following. “
  • “Now many people who call me already have Agile in place (they say), but they’re struggling. They’re having trouble meeting their iteration commitments, they’re experiencing a lot of technical debt, and testing takes too long.”
  • “Does Scrum really fail to achieve its promise 3 out of 4 times? I am afraid so. I have heard that at the last Scrum gathering this number was bandied about and although it was somewhat arbitrarily selected, seems to have won general acceptance.”
  • “As XP / Agile / Scrum have become more popular, many teams and individuals have wanted to do them, or “be” them. This has led to a school of Agile methods that wants to be called “context dependent”. The idea is that whatever brand of Agile is under discussion is “too rigid” and “doesn’t fit our context”. So we have to modify Agile because God knows we can’t modify our context.”

If the 75% number was way off-mark, there would be many CSTs jumping to counter it. Heck, even the Scrum Alliance doesn’t counter it. It’s an accepted fact of life. And that’s the troubling thing – it isn’t the number, but the reaction to the number – one of, “Oh, yeah, well, we know”. (And yes, I know some of the quotes above mention agile. I’ll deal with that in a minute)

2) “But what if we instead asked “How many of those who tried Scrum or Agile techniques saw at least some positive improvement?” or “How many teams were in on the whole at least a little bit better off for exploring Scrum?” I bet the answer would be much different.”

Read this. Go on. If you don’t want to read it, look at this quote:

What does a high touch Scrum team do? A high touch Scrum team does
many things to incorporate touch into its daily practice. High touch
Scrum teams:

  1. Hold hands during the Daily Scrum.
  2. Give each other standing backrubs at the start of the Sprint
    planning meeting.
  3. Hug each other at the end of the retrospective

How many teams would be, on the whole, a little better off for exploring that? I bet most would be. And what does that tell us?


Because Scrum isn’t about making people “a little better off”:

  • “Over fifty organizations have successfully used Scrum in thousands of projects to manage and control work, always with significant productivity improvements.” (from Control Chaos)
  • “With Scrum, these impediments are prioritized and systematically removed, further increasing productivity and quality. Well-run Scrums achieve the Toyota effect: four times industry average productivity and twelve times better quality.” (from Scrum Alliance)

(emphasis mine)

But wait. That last quote is so great, because of what is on that page.

Successful Scrum implementations have many benefits for teams and management. Scrum does, however, require a change from the status quo.


These results can only happen, though, when leadership commits to the required changes: teams that adopt Scrum must move away from command-control and wishful-thinking-predictive management.


“On the surface, Scrum appears to be simple, but its emphasis on continuing inspect-adapt improvement cycles and self-organizing systems has subtle implications.”

And what are those implications?

Oh. Yeah. That’s the end of the page. Guess you have to figure that out on your own.

3) “The Scrum Alliance is NOT a company that has to choose between a narrow vertical industry or a very specific generic offering. Rather, it is a formalized body that supports an organic movement to “transform the world of work”. It is a big tent that provides tools and products to equip any one person’s niche within that movement. Whether offering an article for how to interact with a large company PMO, or supporting a local user group consisting mostly of GUI designers, the SA responds to what its members ask for.”

I covered that in my last post.

4) “However, I do not think the SA’s execution issues point to having the wrong mission.” – Unfortunately he doesn’t say what it does point to. But I can tell you.

Let’s say I create a new digital camera. People who use it are blown away at how much better it is than every other camera out there. But some people, in fact, many people, aren’t seeing the same results. And when they go to my company’s web site, I tell them:

“The CFmera is a revolution in camera design. However, to use it, note that you have to rethink what it means to be a photographer. The way you shoot pictures has to change, and everything you know about what constitutes being a good photographer is applied differently. If you don’t do these things, then you won’t get the results from the CFmera. Sorry about that.”

Is that their problem, or mine? I don’t offer them any guidance, any pointers, any suggestions. If my goal is to transform the way people capture memories, well, that doesn’t really seem to help, does it?

Scrum does good in the world. Even Alan Shalloway admits that. I’m not saying that Scrum is at fault.

What I am saying is that the Scrum Alliance is at fault. They say themselves that to adopt Scrum you have to alter the fundamental tenants of management and organizational behavior. Right there, on their web site. But I’m not seeing trainers updated with the latest advancements in Organizational Behavior, or Change Adoption. CSMs aren’t getting paths to how to adopt it in their organization and how to deal with the fallout (some CSTs do this, I know). And this is all in the context of software development, where we have a very strong base, and a fairly good understanding of the issues involved.

But Jesse’s key point was that the Scrum Alliance can do both a Depth and Breadth approach. I disagree. It needs to choose. Either it’s about Scrum, the framework, with no underpinnings in software, or it’s about software and helping build that out. I actually prefer the former, and having industry-specific groups split out, each that can control the requirements for their subsegment.

Scrum is a good framework. And it’s a stable one – it doesn’t change. That means that the Scrum Alliance mission isn’t to make Scrum better, but help organizations adopt it. And since they say that to adopt Scrum you have to change things – fundamental things – about your organization, doesn’t it make sense that most of their work would be in enabling people to understand how to make that change?

It does to me. Because if we want to “Transform the World of Work” we ain’t gonna do it by sticking people who have no authority to make change or understand of how to introduce change through a 2-day class and collecting some fees. We do it by a concerted effort to change how businesses think about delivering software, interacting with customers, and running their entire company. That’s change, and that’s power, and that’s something that could theoretically be within the grasp of a money-making machine like the Scrum Alliance.

And an organization doing work like that can gladly have my fifty bucks.

Comments on this entry are closed.

  • Robert Dempsey March 1, 2010, 7:18 am

    You’ve hit the nail on the head with this post Cory. The implications that Scrum has on an organization are wide ranging. The transparency and visibility it brings for project and everyone involved in them can be risky for some people, especially if they’ve been floating along in their organization, not rocking the boat, just doing the minimum, or not even that.

    I believe that to be more successful implementing Scrum, it needs to become less risky and more palatable for the people involved. We need to get top-down buy in and support, and it needs to be publicly stated.

    Also we need to start gathering many more metrics on projects (post coming on that today) so we can show solid improvements in the business.

    Also, everyone that is fanatical about what is and isn’t “agile” needs to stop doing that. I remember when Chad Fowler told the Ruby on Rails community to stop being a bunch of jerks so the community could grow. I think the same needs to happen here. I understand branding, but seriously, the “you’re not doing agile if you aren’t doing [blah]” needs to stop. If you’re adhering to Agile principles and working to improve, then who cares? Only people trying to make money on selling the mythical silver bullet.

  • Tim Gregory March 1, 2010, 8:42 am

    Nice post Cory. Spot on.
    I think that the SA has to face their critics head-on, and soon. Withdrawing from the conversation to focus on Scrum Gatherings is not the way forward.
    Perhaps the answer is simple – start prescribing some development and management practices that fit well with Scrum?
    The Nokia Test is pretty good at rooting out whether the processes that you need to run alongside scrum are in place, and some of these should probably be folded into the core of the process.

  • Jesse Fewell March 1, 2010, 10:45 am

    Good stuff, Cory. We can disagree about the breadth/depth thing, but I sense that we’re getting to some passionate agreement around helping people with the details and implications of this stuff. In particular, even if the SA focuses only on “transforming the world of software”, we still need way more detailed resources on how to go about the transforming part.

    So, at the risk of making you vomit, I’ll put a fork in this one for now. Instead, I’ll go add some more stuff into my Scrum curriculum about the CFmera.


  • William Pietri March 1, 2010, 12:09 pm

    Wow, Cory. I’m sorry for your esophagus, but I hope this doesn’t die. As an outsider to the whole Scrum thing, it’s exciting to see somebody internal holding the Scrum Alliance to account, and demanding results that match the hype.

    The whole notion that it’s ok to take something that could make teams wildly better and settle for “a little bit better” is bullshit of the highest order. It’s a great way for lazy CSTs and consultants to make a pile of money, but it results in a classic tragedy of the commons: everybody ends up thinking that Agile only gets you “a little bit better”, and having tried it once, they may never try again.

    So thanks for speaking up on this.

  • Ilja Preuß March 2, 2010, 2:35 am

    Cory, the camery is an interesting analogy. I have a slightly different perspective on it, though:

    A camera is just a tool. No photographer should expect a camera making him a better photographer. Sure, a company might sell a camera that gives you exceptional control over how to take photos. It might give you some new kind of helpful feedback, or some suggestions. But in the end it’s the responsibility of the photographer to learn how to use that information to make good photos. And a successful photographer will probably have done it by not just reading the camera’s manual and/or taking some workshops. He will have looked at the work of other photographers, got in contact with a community, and practiced for years and years.

  • Cory Foy March 2, 2010, 6:53 am

    Thanks Ilja. My point is that I created the CFmera, and I don’t offer a manual, or workshops, on what you need to change. Some of my company’s instructors happen to be very good, and so slip in their own tips, but it isn’t consistent.

    My new CFmera isn’t about a slightly different control. It’s about fundamentally altering your identity as a photographer. You still have to know some basics (framing) but even those have changed slightly (you don’t have to wait to have all of the picture framed just right before starting to take the picture).

    But you’re right – analogies only go so far. Scrum isn’t the one to blame here. All I’m saying is that if we aren’t looking for ways to /modify/ Scrum (which has been pretty clear) then it would seem like the Scrum Alliance’s goal should be to help people /adopt/ it.

    And if we’re about helping the adoption, then we need to help with the organizational change part. It’s very similar to the CSD efforts – you could create a “Certified Scrum Developer” program which was a class where someone learned about TDD, small stories, Simple Design, etc. But if they go back to their jobs and are still measured on how many lines of code they right and how fast they get the crap out of the door; and every one of the other developers are working 10, 12, 16 hour days – what’s the point?

    It goes back to Jesse’s comment. Would a CSD class be, or is the CSM class, worthwhile? Sure. People would see an improvement in what they are doing. An incremental improvement. But if we’re really going to “transform the world of work”; if we’re /really/ going to tell everyone that by adopting Scrum, or XP, or Lean, or “Agile” you’ll see faster releases, higher quality and more money – we’ve got to see an effort to change the fundamental way we teach people how to run and organize business.

    If the Scrum Alliance is doing *that* then imagine the impact we could see in the entire software community. That could be truly amazing. Instead we have to bicker about whether someone taking a two-day CSM class should have to take an exam. And, to me, that’s just sad.

  • Ilja Preuß March 2, 2010, 10:41 am

    Cory, thanks for the clarification! I agree that helping people adopting Scrum by helping them to see which changes in running und organizing a business are necessary would be a good goal.

    I’m not sure we are so far that the SA is in position to *define* and *teach* those changes. Seems to me that supporting ideas and building communities where ideas are developed, exchanged, tested, scrutinized, etc. might be the best that can be done right now. And I would love to see that happen!

  • Phil Ruse March 3, 2010, 7:19 am

    This was a really great read. I’m on the outside looking in but nonetheless am following the development of scrum with great interest – who knows maybe one day I’ll actually get to be agile rather than just hear about it?

    Are you saying then that SA should provide the framework and then concentrate on specific (and a limited number of) ‘verticals’ (such as software development) and how to implement in those environments in greater detail? Would each of these ‘verticals’ evolve independently and/or do you envisage a point where they would inevitably ‘merge’. Or do you see evolution in different directions – albeit with common ancestry?

    Sorry for all the questions!