What to do When Scrum DoesnΓÇÖt Work

4 February 2011

This article is a based on my keynote at the Cape Town Scrum Gathering last fall

 

 

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 it 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 & 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.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Fabrice Aimetti, CSM,CSPO, 2/5/2011 10:08:29 AM
Hi Henrik,
Great post! I've translated it into french :
http://www.fabrice-aimetti.fr/dotclear/index.php?post/2011/02/05/Que-faire-lorsque-Scrum-ne-fonctionne-pas
Regards, Fabrice
Sergey Dmitriev, CST,CSP,CSM,CSPO, 2/6/2011 3:31:27 PM
This is excellent! I┬┤ve made a Russian translation:
http://www.agilecoach.ru/news/50/

Regards,
Sergey
Joshua Partogi, CSP,CSM, 2/8/2011 6:52:17 PM
Hi Henrik,

Nice article. I found that "changing Scrum" as you mentioned is a paradox. Yes "changing Scrum" to suit you might work, but if it still does not work, whose fault would it be?
Francesc Oliva Seluy, CSM, 2/9/2011 2:42:23 AM
Hi Henrik, What a great post!
I'm sure everyone has been guilty of "Scrumwhateverism" at least once.
Sure this will help managing those situations.
I've shared it on my LinkedIn.
Thank you.
Regards, Francesc.
Henrik Kniberg, CST,CSP,CSM,CSD,CSPO,REP, 2/9/2011 3:31:31 AM
Joshua, don't worry about "whose fault" it was. Instead, ask "what did we learn, and what will we try next?".
Jan Litke, CSM, 2/9/2011 12:06:52 PM
Regarding changing scrum -- isn't that the purpose of holding a retrospective at the end of your sprint? And, as long as you hold true to the principles, it's still Agile!
Teresa Durham, CSM, 2/9/2011 3:25:58 PM
Love it! Thanks.
Juan Lopez, CSM, 2/10/2011 7:31:42 AM
Great post, thanks!
Michael Jensen, CSM, 2/11/2011 6:18:41 AM
Great Article.

Those points and general ideas is what i really like about the Agile way of thinking. Everyone will get problems / issues with SCRUM, and the best way to solve it is to adapt even though it is tending to be more SCRUMbuts then "pure" SCRUM, but the whole idea about the agile way is to adapt and overcome, and make issues visible to all.
Joe Little, CST,CSP,CSM,CSPO, 2/13/2011 7:14:04 AM
Excellent article. Some comments...

"To work" is often a subjective opinion, or based on wrong "facts". For example, if the team did not deliver by the time the manager wanted, it could be that the manager's expectations were just unreasonable.

Maybe the criteria for success are wrong. To say it more broadly.

Also, sometimes the team is just not capable (enough) or is fundamentally dysfunctional. You kind of cover this in your item #2.

Finally, some people just don't like Scrum. Personally, I cannot understand this, so I say that they are members of certain Myers-Briggs "types", that typically do not like change, adaptability and transparency. Anyway, if you force someone to do Scrum, they might not like it. And, for whatever reason they don't like it... if they don't like it, they often make sure it fails.

Finally, I feel like item #5 will be "used" too much. Scrum is hard; for many people Kanban is "easy". Too easy in my book. For example: Business people won't play with us (enough). So, rather than fight that impediment in Scrum, we adopt Kanban (which hides the impediment more).

I find that usually in the contexts you mention, there is at least some work that can be planned (thus a short Sprint Planning Meeting is useful). And we need a Sprint Review. And we need a Retrospective. So, to me, the "shorter" Sprint Planning Meeting is a minor adaptation to Scrum in this context. AND, I think Kanban should ALWAYS be added to Scrum. In fact, I say the standard Scrum Board is a basic Kanban board, right "out of the box" of beginner's Scrum. And should be enhanced for your situation. Or, so I say.

I think it bears repeating that doing real Scrum (Scrum without the buts) is typically hard, usually in many ways. And almost always it is worth the pain. Also, repeating again: You must add things to Scrum. Typically the XP engineering practices are among the first things to add to Scrum (eg, to stop building technical debt so darn fast). This also is hard. Still, Scrum is fun (and hard).
Jesper Berg, CSM,CSPO, 2/18/2011 6:21:02 AM
Once again you hit the spot Henrik. Thanks.
Vaibhav Sharma, CSM, 2/21/2011 4:31:41 AM
Excellent article carrying lots of insight.
Bent Myllerup, CST,CSC,CSP,CSM,CSPO,REP, 2/22/2011 4:37:01 AM
Great article! I had a lot of good laughs and great reflections while reading it. I recognize that the ability to write an article like this comes out of great expertise and many hours of experience.
Juan Jose Zapico, CSM,CSD,CSPO, 2/22/2011 9:13:41 AM
@Henrik: Great article. Very useful insights.
@Joe Little: Your comment is a great contribution to the topic.
Thanks
Harald Rietman, CSM, 2/24/2011 1:20:26 AM
Great article, I always mention that if something doesn't work for the team, do something that will work for the team. So listen to your team to get the maximum output.
Charlie Cheng, CSP,CSM, 3/9/2011 5:15:44 PM
This is a really good article. I have used SCRUM for a while. We always tends to modify SCRUM process a little bit. With that we are hard to find what causes problem. But I do believe follow process at start will make identifying problem easier. I am trying my best to persuade our development manager to do so at the moment. (We just finish first sprint. It is nothing like SCRUM although it is cause SPRINT). There are many issues that I can see for both short term and long term.
Glen Wang, CSM, 3/8/2013 12:22:15 AM
yes, there's a question first, then there's an answer. It's people doing, not methods doing. People use methods.

You must Login or Signup to comment.