Failing with Scrum

There are plenty of Scrum success stories out there, but not so many failure stories. That gives rise to a healthy scepticism. Where are the failure stories? Obviously there must be failures! Or?

Introducing Schlum

Well, here’s another process for you. It’s called Schlum, I just invented it. It has two principals:

  • Schlum principle #1: Do the right thing
  • Schlum principle #2: Don’t do the wrong thing

This process has a great track record! I can’t remember any single project failing with this method! Wait, come to think of it, one did actually fail. But that’s because they did it wrong. They mixed up the words "right" and "wrong"! Once I pointed that out to them things got better :o)

Failing with Scrum & Schlum

Why is it so hard to fail with Schlum? Because it is a process framework. It addresses the most fundamental bits, and leaves all the scary details to you. Slippery isn’t it?

Scrum is sort of similar. Most of Scrum translates to common sense. Deliver working code early and often. Work in short cycles to minimize risk and maximize feedback. Do the most important stuff first in case we run out of time. Discuss and improve the process on a regular basis. Show the customer stuff as early as possible. 

Not always easy, but certainly desirable! Who wouldn’t want a process like this? When would this approach in itself cause a project to fail?

But then there are lots of other really important things that Scrum doesn’t address. How do you test? How do you decide who should be on what team? How do you synchronize diverging code bases? How do you find the most representative customer representative? Etc, etc.

THOSE are the failure points. You can really get things wrong if there is no customer to talk to, to name one example.

A process framework isn’t enough – you need the patterns as well

Scrum is a process framework. It is a process for creating a process. It contains slightly more meat than Schlum, but is still very bare-bones.

Scrum provides feedback loops and control points that make you continuously rub against the weak points of your current process, and thereby help you inspect & adapt your process to your specific context.

Now, a process framework is in itself not very useful.

Take Schlum for example. What more do you need? Just do Schlum and you’ll be fine! Uh, what did you say? How to do the right thing? Who decides what the right thing is? Have you ever heard an expensive consultant say "Oh those are implementation details, it is up to you". Not a very useful answer. A better answer is "Oh, those are implementation details – here are some examples of how those issues have been addressed in other similar contexts".

I’m talking about patterns. There are lots of books and sites on organizational patterns. Patterns are most useful when they are accompanied with an example describing how a particular problem was solved in a particular context. My book Scrum and XP from the Trenches is full of patterns and anti-patterns and examples of how they were implemented, although it isn’t really organized as a formal pattern repository.

A failure story. Or?

One of my clients had decided to start using Scrum for a project. They had a grandiose vision for what they were going to build and wanted to get started as quickly as possible.

I asked them to wait, and instead start by creating a product backlog, and get it roughly estimated by the team (actually it was just a few representatives of the team-to-come). They wanted to start by doing prestudies and building platforms. I asked them instead to fully implement the first few stories in "prototype" mode, just to get something to work.  The goal of the first sprint would be to learn enough about the first few stories in order to make better estimates for the rest of the product backlog, and learn about the team’s velocity.

A few weeks after helping them get started I called back to ask how they were doing. They had canceled the project! My company lost some business there, as we were supposed to be involved in the development.

Hmmmm… what happened here? They were going to start a new cool project. In fact they were already in the middle of the pre-study. And then they decided to start using Scrum. And a few weeks later they canceled the project.

So – did Scrum fail?

No. Scrum succeeded. The project was canceled because it turned out to be unclear, overambitious and unrealistic. The wanted to build too much stuff in too short time. Scrum was the messenger that helped them fail early rather than late. Without Scrum they may well have commited significant resources to the project, only to discover several months and many bucks later that it was doomed to fail. Nobody outside the project needed to convince them, they discovered it themselves.

Although we lost some business on that one project, we won a very satisfied and faithful customer who now hires us regularly for other projects. They are also continuously expanding their use of Scrum.

This type of story is very common. It is an example of a successful process and a failed project. There will always be projects that fail, the trick is to get them to fail as early as possible when they do.

It’s easy to confuse project success/failure with process success/failure.

  • A project may succeed because of a great process
  • A project may succeed despite a lousy process
  • A project may fail because of a lousy process
  • A project may fail despite a great process

So when does Scrum itself fail?

Scrum fails when it is misapplied. You don’t need to get it right from the start, but you do need to continuously inspect and adapt the process.

Maybe there are projects that have failed because of Scrum, i.e. where Scrum was implemented correctly and actually caused the project to fail. I just haven’t seen a convincing case yet, let me know if you have one. Usually failure stories travel faster than success stories, so if it Scrum failures were common I’m sure they would be well spread.

There is a paradox, an unfortunate rhetoric that some Scrum trainers use. I accidentally use it myself sometimes: "If Scrum failed, you did it wrong". This is a tautology, a meaningless statement. You can use that type of statement to justify anything – "If waterfall failed, you did it wrong". It is like saying "Scrum can’t fail, because if Scrum fails it isn’t Scrum". Note that my statement "Scrum fails when it is misapplied" isn’t really the same.

Scrum is just a framework. You have to fill out the blanks yourself, find the patterns and experiment with them. Sometimes you will get it wrong. Sometimes the corporate culture will get in the way and stop you from making the necessary changes.

Finding Scrum patterns is easy. Just read web sites and books on Scrum and agile software development.

The hard part is knowing when to apply which pattern. And how do you learn that?

  1. Experience – try the patterns out in different situations, see what works and what doesn’t.
  2. Talk to others that have the experience.
  3. Read books & papers written by people that have the experience. 

Did I mention the word "experience"?

Some patterns are quite universally applicable, for example the use of physical taskboards. Other patterns are more contexts-dependent, for example how to divide people into teams.

How to minimize the risk of process failure

  • Learn
  • Create & utilize feedback loops

Read books & articles, attend conferences, talk to colleagues, participate in online forums such as scrumdevelopment@yahoogroups.com (LOTS of patterns to be found there, but takes some digging!).  Experiment with different ways of implementing Scrum, but make sure you don’t accidentally break the critical feedback loops of Scrum – the daily scrum and the sprint review.

And remember that the improvement process never ends – you can always make things better! And besides, your context will evolve so the process has to evolve with it.

Slack!

Guess what. It takes time to learn! It takes time to create & utilize feedback loops. This is typically the role of the Scrum Master.

If you tell me "I don’t have time" then I will tell that you are probably wasting time! You are probably fruitlessly banging your blunt axe against the tree, instead of taking a few minutes to sharpen it. You are probably running with the bicycle on your back, instead of stopping a few seconds to get on it.

Take the time. Reprioritize. If nobody on your project has time to learn about process patterns, and nobody has time to create & utilize feedback loops in your process, there is a high likelihood that you are dooming your project to failure – and working very hard to do it.

So if Scrum itself rarely fails, is Scrum a Silver Bullet?

Nope. Scrum doesn’t guarantee success. It just improves the odds :o)

8 responses on “Failing with Scrum

  1. This reminds mee of the Kennedy quote – ‘Victory has a thousand Fathers – defeat is an orphan’. Of course the quote was ‘borrowed’ in part from a chinese philosopher.

    You will not see many failures quoted for obvious reasons – no one likes to be associated with failure.

    SCRUM is not a silver bullet – how can it be – because it is a simple management framework. Its what you do when the pain comes through finding issues and constraints that repeat themselves over and over – daily – unless fixed that mark out the successful organisations from the less successful ones.

    A company that uses SCRUM to take on the changes needed is in for a tough time – but when it comes through the tough times and improves its end to end processes it will be in a strong position compared to its competitors -imho.

  2. You say that Scrum increases the odds but you don’t say by how much.

    Where is the proof that it increases the odds? Which patterns are not mere placebos?

    Who says that throwing patterns at a problem results in a solution? It may or may not — there is no evidence to support that it does, especially if there is a new situation for which no pattern exists.

    Like many bloggers you seem to say, without proof, that whilst Scrum is not 100% pure silver, it is nearly that.

    Jordan

  3. The only evidence I have is anecdotal, having visited and talked to hundreds of companies worldwide. I have no proof that the sun will go up tomorrow either, but more than enough anecdotal evidence :o)

    I think proof is overrated. Not much innovation would happen in this world if you needed proof for everything.

  4. If the only evidence you have is anecdotal than it is not evidence correct?

    You claim it increases the odds — by how much?

    Anyone could claims their friends had visited Las Vegas and bet on the green and won — that is hardly however an overall winning strategy.

    Also I don’t know if it was a joke or not but clearly there is more than “anecdotal” evidence that the Sun rises every day.

    I had come here thinking this is a serious blog but what I’m hearing is not different from the myriad superstitious claims of the faithful

    Jordan

  5. I like these two points, Henrik.

    “Oh those are implementation details, it is up to you”. Not a very useful answer.” – many coaches/consultants get by, by saying that that to their clients, without providing good examples (both, successes and failures). Alternatively, they sometimes give prescriptive solutions that are not based on any known case studies or personal experiences. Too purist, imo.

    “No. Scrum succeeded. The project was canceled because it turned out to be unclear, overambitious and unrealistic.” – scrum/agile frequently gets rejected/avoided because it starts to reveal such painful systemic problems that some people feel that they are better off without explicitly dealing with those problems (they are in denial).

    Great post.
    Gene

Leave a Reply to Jordan Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.