The ‘Scrum is immutable’ clause is an invitation to experiment
And a clarification of what Scrum is
And a clarification of what Scrum is
One sentence has haunted Scrum ever since the creators decided to include it in the Scrum Guide:
“The Scrum framework, as outlined herein, is immutable.” — Scrum Guide 2020
For many, this line confirmed why they hate the framework: Scrum is not Agile as it doesn't allow practitioners to bring changes to their Scrum implementation.
I believe these people miss the mark. The line is not about disallowing practitioners to only use parts or to move away. As the following quote clearly explains:
“While implementing only parts of Scrum is possible, the result is not Scrum.” — Scrum Guide 2020
It’s just that the creators wish to make clear what is Scrum and when it is not Scrum. Because all parts of Scrum have their purpose:
“Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum. Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.” — Scrum Guide 2020
I used to wonder why the creators of the Scrum Guide believed it was important to emphasise that the sum of all elements make Scrum. Why would they discuss something in the Scrum Guide that they don’t consider to be a part of Scrum in the first place? Or even stranger, why would they choose not to mention elements that are part of the framework?
The answer may lie in the following: many criticize Scrum about aspects that are not Scrum at all (and actually false), like:
Scrum would pressure teams to deliver their items as planned Sprint after Sprint;
Scrum Teams don’t look beyond a Sprint;
Scrum doesn’t allow multiple releases per Sprint.
The list of Scrum misconceptions goes on and on. They have been so prominent, we even created a community to address these misconceptions and clarify the purpose of Scrum.
This is how I came to understand the creators of Scrum. They wanted to state what is Scrum and what not. And what it means when you change elements of Scrum. This is why Scrum is immutable. Every element has a meaning and together they form Scrum.
But this doesn’t mean teams shouldn’t be critical about their Scrum implementation. On the contrary: I see the immutability clause as an invitation to experiment. Because Scrum may be suited for you. But it can also be that only certain elements are beneficial and others are not.
Scrum is immutable. Every element has a meaning and together they form Scrum.
Scrum has a sweet spot
In my previous article, I explained how Scrum applies to a specific environment:
You create or maintain one product at a time.
You regularly have to verify if your work helps to achieve your objectives.
Your knowledge on 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.
When you tick all these boxes, Scrum — in its entirety — may be your framework of choice. When you tick only some of them, Scrum will not be your way forward. But certain elements could still be valuable. Especially when you consider the mechanics of Scrum — the three feedback loops. If a team doesn’t need all of them, they don’t need Scrum in its entirety.
Three feedback loops
Scrum is a framework to manage complexity. Scrum’s answer to complexity is empiricism: transparency — inspection — adaptation. Empiricism is everywhere in the Scrum events. In fact, Scrum acknowledges three aspects of complexity:
Feedback loop 1
The Sprint Planning and the Daily Scrum cater for the notion you can’t know upfront what work will help you to achieve your Sprint objectives. This is why teams define a Sprint Goal as their commitment. Teams create a plan to achieve their Sprint Goal, but this plan is expected to change when new insights occur. This is the first feedback loop.
Feedback loop 2
The Sprint Review centres around maximizing the value of the product. Here the complexity lies in grappling with the long term product objectives. The team and its stakeholders have well-defined product objectives as the Product Goal.
This Product Goal states the desired outcome, typically by a certain date. But the road towards the Product Goal is unclear. So the review serves to maximize this chance, resulting in a reordering of the Product Backlog. This is the second feedback loop.
Feedback loop 3
The Sprint Retrospective is about the team's effectiveness. Here they contemplate how they use Scrum and work together. Their interactions, process and tools are complex. Teams improve by trying out new ways and learning from these experiments. This is the third feedback loop.
Teams may have all three aspects of complexity. I firmly believe many are in this situation. This means that all elements of Scrum will apply to these teams.
But if your team only has one or two of these aspects of complexity, then Scrum as a whole is not the best fit. This doesn’t mean that everything about Scrum is useless for them.
Suppose a team knows exactly how to achieve their Sprint objectives, (almost) every time. The work may be complicated, but trough through analysis teams know exactly what to do.
But the journey to maximize the value of the product is complex. They need to take small steps to learn and then decide what to do next. Those teams could benefit from working in Sprints and having Sprint Reviews. But the Sprint Planning and Daily Scrums as described in the Scrum Guide may not be helpful. These teams should feel invited to experiment to find other ways to plan and control their work.
This brings us back to this statement in the Scrum Guide:
“While implementing only parts of Scrum is possible, the result is not Scrum.” — Scrum Guide 2020
And that is totally ok. You can choose to use certain elements of Scrum. They may turn out to be helpful for you. This is fine. And the creators of Scrum also think this is fine. You don’t use Scrum, only elements of the framework. Everyone will be happy it works for you.
Other aspects
Apart from the events, other elements could also be subject of change, like:
Teams may wish to experiment with everyone sharing the Scrum Master accountability.
You may wish to move away from the idea of one Product Owner;
You wish to use Scrum to manage your tasks, not to create a product.
I could think of 100 examples of ways to deviate from (the heart of) the Scrum framework. Whatever helps you and your team out, go for it.
Experiment and learn
Yes, Scrum is immutable. Because the Scrum Guide gives a clear description of what Scrum is. That’s Scrum. Nothing more, nothing less.
Many will happily use Scrum in its entirety. Others may only see the benefit in parts of Scrum and wish to experiment with ways that are not in line with Scrum. This is perfect.
But be sure to not unknowingly remove and alter things, to look before you leap. Know your environment and understand what Scrum entails. Then you can determine if Scrum fits your needs. Does it fit? Perfect. Do some parts fit and others not? Experiment!
The goal is not to use Scrum by the book. The goal is to achieve your goals. Scrum helps you achieve your goals. But if parts of it aren’t helping you, look for other ways. Experiment and learn. Inspect and adapt. You will end up working in your own unique way. Inspired by Scrum.
The goal is not to use Scrum by the book. The goal is to achieve your goals. Scrum helps you achieve your goals.
Join Medium with my referral link — Willem-Jan Ageling
As a Medium member, a portion of your membership fee goes to writers you read, and you get full access to every story…medium.com