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?
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?
- Experience – try the patterns out in different situations, see what works and what doesn’t.
- Talk to others that have the experience.
- 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
- Create & utilize feedback loops
Read books & articles, attend conferences, talk to colleagues, participate in online forums such as email@example.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.
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)