When is it time to stop using scrum?

tl; DR: When should the team stop using Scrum?

When is it time to look beyond scrum? After all, many things—thoughts, practices, mantras, etc.—shortly lose their usefulness; Why would scrum be an exception? Furthermore, we are not getting paid to practice scrum, but solves the problems of our clients within the given constraints while contributing to the stability of our organization. Scrum is a tool, a helpful practice but neither religion nor 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 Advantage

When I ask if there is a moment when a scrum team should stop using scrum, I am not referring to a situation in which it is useless to use scrum in the beginning. For example, if you look at the Stacy matrix below, you’ll see areas in red—simple and chaotic:

  • “Simple” does not require elaborate risk-mitigation strategies as best practices usually work; You don’t need a sprint plan to prepare [large hamburger of your choice] Menu with fries and soda.
  • At the other end of the spectrum the focus of “chaotic” is on creating stability because chaos is lurking around the corner. As we are dealing with novel practices, a short-term work-feeling-feedback approach is beneficial, which is not necessarily the strong suit of Scrum, given the importance of the Sprint as a central planning example.

Therefore, both areas are unsuitable for using scrum from the very beginning.

I’m also not referring to situations where your team fails to solve your customers’ perceived problem for technical reasons or because there isn’t a problem to solve in the first place. (As we all know, the ground is littered with many start-ups that failed to identify a problem to be solved; I’ve run into some of them myself.) In the end, I’m not talking pundits. I am the one who believes that using scrum is a disadvantageous decision in any situation and you should not get involved in it at all.

For this article, I refer to a Scrum team solving problems for my clients. A team that over time gains a good understanding of the problem and solution space. I’m thinking of a scrum team that embodies the idea of ​​a sound scrum application, enjoying a good position in the organization. However, will that team ever be faced with a situation where Scrum outweighs its usefulness? Or will they continue to giggle happily for eternity?

Development That Leads to Rethinking Scrum

What I’ve seen in the past is a slow but steady growth that results from the successful work of the Scrum team progressing into the maturity phase of the product life cycle. What began as a campaign in the unknown – for what is worth building in an area where the team initially had little knowledge – turned into a systematic advance that increasingly required less risk mitigation as the Scrum team took the lead. The challenge was mastered.

Stacy returns to the Matrix, the Scrum Team departs from the “Complex” [1] for “complicated” [2],

How can Scrum teams notice when they have moved from “Complex” to “Complex”?

Some indicators help Scrum teams understand whether their progress as a team, as well as the growing maturity of the product, justifies observing their original decision to use Scrum, for example:

  • Progress becomes more stable and less volatile as the product matures; There are fewer disruptions in giving salary hikes.
  • There are fewer matching points to score, and progress becomes more incremental—focusing on minor improvements—as the “big features” are already available.
  • Scrum teams experience increasing difficulties in creating team-integrated sprint goals; There is an increasing number of Product Backlog items that cannot be clustered under a single topic.
  • Low volatility results in a wide planning horizon. At the very least, there is a temptation to plan ahead, which is also friendly to the stakeholder relationship management of the team. (The scrum team builds trust with stakeholders by boring reliable delivery at best.)
  • Stakeholders gain more confidence in the team’s capabilities, resulting in less engagement, for example, in sprint reviews. (Why breathe down the neck of the scrum team as a stakeholder when they successfully deliver valuable increments, allowing you to build your plan?)
  • Metaphorically speaking, the Scrum team moves from moving forward to progressing rapidly.

In my experience, no unique boundary indicates completion of going from “complex” to “complex”. Conversely, noticing this slow and non-obvious process requires dedicated observation from the scrum master and all team members. In addition, psychological protection is needed to challenge what regularly works fine. As mentioned earlier: We do not get paid to practice scrum, but solves the problems of our clients 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 mean that we will use Scrum for an eternity. There may be a time when we decide to stop using Scrum because it no longer serves the original purpose: finding what is worth building while minimizing the risk. The moment we see competition about our way of doing things from a different perspective, we should oversee our decision to use Scrum and possibly adapt if the new way of working promises a better return on investment. . (However, please note that by citing “return on investment”, I am not thinking only in financial terms. There are other factors, for example, team health or product quality.)

As always, it’s a good idea to get all team members involved early in the 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 did they take to reach this conclusion, and how did it work for them?

Leave a Comment