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?

🇩🇪 Zur deutschsprachigen Version des Artikels: Wann ist es Zeit, mit Scrum Schluss zu machen?.

🗳 Update: Join the poll and its lively discussion on LinkedIn.

🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 36,000-plus other subscribers.

🎓 Join Stefan in one of his upcoming Professional Scrum training classes!

🖥 💯 🇬🇧 Advanced Professional Scrum Master Online Training w/ PSM II Certificate — December 12-13, 2022.

📅 💯 🇬🇧 December 7, 2022: Join 150-plus peers at the 48th Hands-on Agile Meetup: Hands-on Agile 48: How Elon Musk Would Run YOUR Business with Joe Justice.

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?

Cannot see the form? Please click here.

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?

📖 Recommended Articles

Regarding the decision on when to stop using Scrum, I recommend the following literature on Scrum, Scrum Master, and team building:

Poll: Can a Scrum Team decide to abandon Scrum, given that self-management is a first principle of Scrum?

Abandoning Scrum: Can a Scrum Team Decide to Quit Scrum?

Scrum’s Nature: It Is a Tool; It Is Not About Love or Hate

How to Manage a Product in the Maturity Stage of Product Life Cycle

Download the 73 Scrum Master Interview Questions for free.

📅 Scrum Training Classes, Workshops, and Events

Delve into understand Scrum with our Scrum training classes, workshops, and events. You can secure your seat directly by following the corresponding link in the table below:

See all upcoming classes here.

You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.

✋ Learn More About When to Stop Using Scrum — Join the 12,000-plus Strong ‘Hands-on Agile’ Slack Community

I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

Support your Scrum team in its decision process on when to stop using Scrum by pointing to the free Scrum Anti-Patterns Guide: