When Is It Time to Stop Using Scrum?

TL; DR: When Should a Team Stop Using Scrum?

When is the time to look beyond Scrum? After all, many things—ideas, practices, mantras, etc.—outlive their utility sooner or later; why would Scrum be an exception? Moreover, we are not getting paid to practice Scrum but solve our customers’ problems within the given constraints while contributing to the sustainability of our organization. Scrum is a tool, a helpful practice but neither a religion nor a philosophy. Which brings us back to the original question: Is there a moment when a Scrum team should stop using Scrum?

Setting the Context of Using Scrum To Your Benefit

When I ask whether there is a moment when a Scrum team should stop using Scrum, I am not referring to a situation in which using Scrum is useless, to begin with. For example, if you look at the Stacey Matrix below, you will notice areas colored in red—Simple and Chaotic:

• "Simple" does not require elaborate risk-mitigation strategies as best practices typically work; you do not need a Sprint Planning to prepare a [large hamburger of your choice] menu with fries and a soda.
• The focus of "Chaotic," on the other end of the spectrum, is on creating stability as anarchy lurks around the corner. As we are dealing with novel practices, a short-timed act-sense-respond approach is beneficial, which is not necessarily Scrum’s strong suit, given the importance of Sprints as the central planning instance.

Therefore, both areas are unsuited for using Scrum from the start.

I am also not referring to situations where your team fails to solve the perceived problem of your customers for technical reasons or because there is no problem to solve in the first place. (As we all know, the ground is littered with numerous start-ups that failed to identify a problem worth solving; I participated in some of those myself.) Finally, I am not referring to the pundits who believe that using Scrum is a disadvantageous decision in any situation and you should not get involved with it at all.

For this article, I refer to a Scrum team solving its customers’ problems. A team that gains a good understanding of the problem and solution space over time. I am thinking of a Scrum team that embodies the idea of sound Scrum application, enjoying a good standing in the organization. However, will that team ever face a situation where Scrum will outlive its usefulness? Or will they be scrumming happily ever after for eternity?

The Evolution that Leads to Reconsidering Scrum

What I have observed in the past is a slow but steady development resulting from the successful work of the Scrum team, moving further to the maturity stage of the product life cycle. What started as an expedition into the unknown—what is worth building in an area where the team initially had little knowledge—turned into a methodical advance, requiring increasingly less risk mitigation as the Scrum team mastered the main challenge. 

Returning to the Stacy Matrix, the Scrum team moved from "Complex" [1] to "Complicated" [2].

How Can Scrum Teams Notice When They Moved from "Complex" to "Complicated?"

Some indicators help Scrum teams understand whether their progress as a team, as well as the product’s increasing maturity, justify inspecting their original decision to use Scrum, for example:

• Increasing product maturity leads to progress becoming more steady and less volatile; there are fewer disruptions in delivering Increments.
• There are fewer match points to score, and progress becomes more incremental—focusing on minor improvements—as the “big features” are already available.
• The Scrum team experiences growing difficulties in creating team-unifying Sprint Goals; there is a growing number of Product Backlog items that cannot be clustered under one topic.
• Reduced volatility results in an expanding planning horizon. At least, there is a temptation to plan further ahead, which also suits the team’s stakeholder relationship management. (The Scrum team best creates trust with stakeholders by boring yet reliable deliveries.)
• Stakeholders gain more trust in the team’s capabilities, resulting, for example, in less engagement in Sprint Reviews. (Why breathe down the neck of the Scrum team as a stakeholder when they successfully deliver valuable Increments, allowing you to do your own planning?)
• Metaphorically speaking, the Scrum team moves from leaping forward to walking steadily.

In my experience, no unique threshold signals the completion of moving from "Complex" to "Complicated." On the contrary, noticing this slow and non-obvious process requires dedicated observation from the Scrum Master and all team members. Moreover, it needs psychological safety to challenge what works just fine regularly. As mentioned before: We do not get paid to practice Scrum but solve our customers’ problems within the given constraints while contributing to the sustainability of our organization. 

Conclusion: When Is It Time to Stop Using Scrum? 

Choosing Scrum at a certain point does not imply that we will use Scrum for all eternity. There may be a time when we decide to stop using Scrum as it no longer serves the original purpose: figuring out what is worth building while mitigating risk. The moment we notice competition regarding our way of working by a different approach, we ought to inspect and probably adapt our decision to use Scrum if the new way of working promises a better return on investment. (Please note, though, that by referring to "return on investment," I am not merely thinking in financial terms. Other factors are, for example, team health or product quality.)

As always, it is a good idea to include all team members early in this process.

Have you ever worked with a team that decided to stop using Scrum? If so, please share with us in the comments: What steps they took to come to that conclusion, and how did it work out for them?