We Should Stop Trying to Make Scrum Fit for Every Situation
We Should Stop Trying to Make Scrum Fit for Every Situation
Scrum serves a specific purpose and no more!
Scrum serves a specific purpose and no more!
Scrum is the most popular — I should I say widely used — Agile approach in the world. Many use Scrum, perhaps as a part of a larger whole, like SAFe, Disciplined Agile or Scrum@Scale.
Scrum has become a commodity. So much so that many organisations, teams and people assume Scrum is the gold standard for software development. But this is a terrible misunderstanding of what Scrum is.
Scrum exists for a very specific situations, where:
You create or maintain one product at a time.
You regularly have to verify if your work helps to achieve your objectives.
Your knowledge of how to build the product emerges while working on it.
You can create product increments within no more than a month, preferably faster.
You need a team to build the product.
You have stakeholders that should be involved in the product journey.
All six of these prerequisites need to apply. If you don’t tick one of the boxes, then reconsider working with Scrum. Let’s unravel this a bit more.
One product
Scrum is a framework to maximize the value of your product. There should be a product, one product. Here are three different situations where this may not be the case and how it impacts the purpose of Scrum.
Multiple products
I know teams that claim to work on multiple products at the same time. These products are typically small and don’t require much work. They can’t keep a team “busy” Sprint after Sprint. To allow a team to work to full capacity, they work on two or more products every Sprint.
But Scrum isn’t suited for this purpose. It is aimed at making the best of one product at a time. This is why the Product Goal is the team’s long-term objective and why Scrum has Product Backlogs — a backlog for one product.
Scrum can still be an inspiration for teams to focus as a whole team on one product at a time, no matter how small the effort. The one product concept makes Scrum.
One component or feature
Another issue I often see is with Product Owners in name, but Component Owners or Feature Owners in practice. These people have the authority to make decisions on maximizing the value of their component or feature. But this doesn’t automatically mean they are making the best choices to maximize the value of the product as a whole.
A Scrum Product Owner should have responsibility for all aspects of the product resulting from the work of the Scrum Teams. This is the only way to manage the complexity of the product environment, the only way to make the right decisions on what works, what doesn’t work and what to target next.
Many organisations have the false notion that a Product Owner should serve one team and thus only a piece of the product. But Product Owners don’t manage a team backlog, they manage a Product Backlog.
No product
I also know teams that don’t create or sustain a product at all. They merely have a list of (unrelated) tasks or actions to work on. They may not be aware they work on a product. In that case, they should look into defining this.
A product is a vehicle to deliver value. It has a clear boundary, know stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract. — Scrum Guide 2020
But if there’s simply no product, then it doesn’t make sense to use a framework that aims to maximize the value of a product.
Regular verification of the journey
If you know what to do after a thorough analysis of the problems you wish to tackle, then you are in a position to fully plan your work and monitor the progress of the work accordingly.
When your environment is predictable, you don't need to verify if you are working on the right things. Because you know you are right. If you would be using Scrum in such a situation, you’d have a Sprint Review without a purpose.
A Sprint Review exists to increase the chances to build the right thing. You constantly need to check this with your stakeholders because your product environment is complex.
The Product Backlog intentionally is highly adaptable to allow changes and refinement. When you know these changes will not come, there’s no reason to have a Product Backlog. You can suffice with requirement documents and detailed plans.
When you don’t need a Sprint Review, a Product Backlog and refining you don't need Scrum.
How to build the Product Increment
When you define your objectives at the Sprint Planning and formulate your Sprint Goal, it can be you know exactly how to achieve this goal. You know what you need to do to create Product Increments that meet this Sprint Goal. You also know you will be able to achieve this within the Sprint.
If this is the case, you don't need the Daily Scrums to understand if you are on track to reach your Sprint Goal. What’s more: you don’t need a Sprint Goal to help you focus on what you wish to accomplish. There’s no need to discuss alternative ways to meet the goal anyway.
When you don’t need a Sprint Goal or Daily Scrums because you know what to do during a Sprint and know you will achieve it within this Sprint you don’t need Scrum.
Creating product increments within a Sprint
Scrum revolves around inspection of the Done increment to learn what to do next. A team should be able to create a product increment within a Sprint, which is a month or less.
It is totally fine (and great) when teams can create increments faster or even multiple times per Sprint. It is also ok when a team occasionally doesn’t succeed. But creating at least one product increment every Sprint should be realistic.
I have worked with teams that stated they couldn’t do this. They always needed more than a month to create a new increment. I was able to coach most of these teams to find ways to shorten timelines after all. But it didn’t work everywhere. Some teams were unsuccessful due to the nature of their environment.
I have come across multiple reasons why teams couldn’t create increments within a month. Examples are dependency on external parties, like hardware suppliers and the complexity of the product itself.
Scrum without inspection of the Product Increment at the Sprint Review has no value. If you can’t achieve this, don’t use Scrum.
The team
Scrum is a framework to create products with a team (or multiple teams). If you have individuals creating a product, Scrum makes no sense. All team-related aspects would be obsolete.
It doesn’t mean aspects of Scrum can’t be useful. The Sprint Review comes to mind. But Scrum as a framework is team-oriented, so it doesn’t apply to individuals.
Stakeholders
In Scrum, stakeholder involvement is key. Without it, it doesn’t make sense to use Scrum. Teams and their stakeholders need to discuss the Product Increment (at the Sprint Review). The whole point of Scrum is to show a new piece of working functionality to stakeholders and collaborate with them on how to proceed.
If you don’t have these stakeholders or if you have no way to include them in these discussions, don’t use Scrum.
Conclusion
I wrote this article to highlight the importance of understanding your approach. I have seen many Scrum Teams. Most of these teams have all the right reasons to use the framework. But I also coached teams away from Scrum as it didn’t fit.
It baffles me how organisations transform entire departments into Scrum Teams. They appear to view Scrum as a silver bullet to becoming “Agile”. But it doesn’t work this way.
Using Scrum or being Agile should never be the goal. It should always be: “How can I maximize the chances to achieve my goals?” Scrum can be a way to do this. But it can also be a totally wrong choice. And when Scrum is the wrong choice, you should abandon it.
That said, it can also be you are not ticking all the boxes yet. For example, you may not have your stakeholders at the Sprint Review. Or you may not work with a properly defined product yet. Then you should put effort into realizing this. Then this article can help you to accomplish the right prerequisites.
