What to Do When Scrum Doesn’t Work

Scrum is great! Except when it isn’t. What do you do when scrum doesn’t appear to work?

Diagnosis 1: Using the process wrong

If your immediate response to failure is “Oh, that must mean you were doing scrum wrong,” then be careful.

Scrum is indeed often misused (in which case the remedy is clear). But if you jump to that conclusion without examining the situation at hand, then you are guilty of Scrumdamentalism (the mistaken belief that scrum is always the right solution). The statement “If your project failed, then you were doing Scrum wrong” means, by logical transposition, that “If you do Scrum right, your project will succeed.” Remember what Fred said about silver bullets!

So, what if scrum is being used right and the project still appears to be failing?

Diagnosis 2: Blaming the messenger

Scrum is designed to expose problems. In one case, a client canceled a project after the first sprint. Based on the velocity of the team and their estimated future velocity, the product owner realized that this project would take way too long to be profitable. So he canceled it.

Sometimes we are tempted to shoot the messenger: “Look, as soon as they started doing scrum, the project exploded!” Fortunately they didn’t do that, they realized that scrum helped them save a lot of money by killing a bad project early. Scrum caused a “good type of pain.”

When a problem is exposed by scrum, focus on the problem – not scrum.

But what if the problem appears to be caused by scrum?

Diagnosis 3: Being impatient

The first sprint for a new team is usually a mess. It takes a few sprints before a new team learns to collaborate effectively. Impatient people may jump to the conclusion that Scrum doesn’t work: “Hey, look at this mess! The team produced nothing useful during the first sprint, and they spent half of the time arguing over numbers on sticky notes!” Be patient, give the team time to make mistakes and learn from them.

When you learn to play guitar (or any musical instrument) it will sound pretty bad initially. That doesn’t mean the instrument doesn’t work, it just means you should keep practicing and watch for incremental improvement.

So, what if our patience is running out? What if the team has executed several sprints without delivering anything?

Diagnosis 4: Not adapting the process

Suppose you’ve been doing scrum “by the book” now for several months, and you keep banging your head against the same problem. If you keep doing this then you may be a victim of Sadoscrumism (the mistaken assumption that pain triggered by scrum is always a “good kind of pain'').

It is time to evolve your own dialect of scrum.

Yes, you can change scrum. And you should. But only after you have ensured that diagnoses 1, 2, and 3 don’t apply.

Spending too much time arguing over task estimates? Eliminate task estimates, or eliminate tasks altogether.

Spending too much time arguing over story estimates? Estimate in t-shirt sizes instead (S/M/L), or stop estimating altogether. Velocity can be based on counting stories rather than counting story points.

Having trouble figuring out how to split 15 people into smaller teams in a consistent way? Let them form & reform organically on a feature-by-feature basis.

Does the product owner desperately want to change things in the sprint? How about letting them swap in a new story during a sprint, as long as they take out an existing story that hasn’t been started yet?

Will these changes make the situation better? You won’t know until you try.

Is this still scrum?  I’m not sure, but does it really matter? Anything that works for you is right, anything that doesn’t is wrong. Beware of Scrumbutophobia (Fear of doing scrum wrong. Symptom: Stuck in Shu)

Diagnosis 5: Using the wrong process

There are some contexts where scrum just isn’t appropriate.

Suppose we have an operations, maintenance, or support team whose primary purpose is to be reactive. They do minor bug fixes and enhancements that arrive on a daily basis. These cannot be batched into sprints, because priorities change too fast. When the team has time, they work on long running improvements. These long running tasks aren’t sized to fit snugly into a sprint; they are split and sized into chunks that represent customer value. 

In this context, sprints and the associated planning meetings will feel like a waste of time.

The other parts of scrum – the cross-functional teams, the daily meetings, all that may be fine. Iterations and other cadences may be fine. But a sprint is a time-boxed, fixed-scope iteration, and sometimes that is just not the right tool for the job.

In these contexts Kanban is spreading fast. The WIP limits of Kanban provide the same type of positive “delivery pressure” as sprints do in scrum, but in a different way. Iterations aren’t the only way to be agile, in fact iterations aren’t even mentioned in the Agile manifesto or the agile principles.

Summary: What to do when Scrum doesn’t work

The key point here is, don’t jump to conclusions. Like any good doctor, diagnose the problem before suggesting a remedy (cause-effect diagrams work nicely for this).

Distinguish between “using the tool wrong” and “using the wrong tool.” And whatever you do, don’t blame the tool. Scrum doesn’t succeed or fail, people do. People choose where, when, how, and why to apply scrum.