Remove the immutability rule from the Scrum Guide#2

The immutability rule states the following:

“Scrum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.”

There’s far too much dogma and not Scrum discussions going on. In reality, most teams are not practicing Scrum, because you can nearly always find something they are doing not according to the Scrum Guide.

If people are trying to practice Scrum, they are doing Scrum. However ugly and far removed from the Scrum Guide it is. Nobody starts with a pristine version of Scrum.

Plus, it is pretty obvious, that if you follow something that has rules, and you don’t follow those rules, that you’re not doing it. It’s pretty redundant to state that and only invites more dogma than we’re already suffering from.

Plus the immutability rule is being exploited to claim that Scrum is not Agile. Many people write articles to say Scrum cannnot be Agile if it is immutable. I believe the reasoning does not make sense, but why expose Scrum to silly arguments with a rule that does not add value?

Less is more.

Thank you for adding your comment. This has got to be my biggest bugbears with the Scrum guide. Isn’t it also somewhat hypocritical given Scrum espouses inspect and adapt?

Personally, I like the intent of the immutability rule. Or, at least how I interpret the immutability rule.

What it says to me is that if someone says “Scrum”, they are referring to the roles and events and artifacts in the most recently published version of the Scrum Guide. The Scrum framework is generally immutable - only Jeff and Ken (and whoever they work with) is allowed to change the definition of what Scrum is, and that is done by making a revision to the Scrum Guide and posting it for the world to see.

Without this immutability rule, the word “Scrum” becomes meaningless. If someone can legitimately call what they are doing “Scrum”, yet change a fundamental characteristic that is defined in the Scrum Guide, the word has no real meaning anymore. If you are not doing something that the Scrum Guide says to do or doing something that the Scrum Guide says not to do, then you don’t have Scrum. Perhaps you can say that your way of working is “based on Scrum” or “like Scrum”. If you are doing “Scrumbut”, you don’t have Scrum.

The immutability rule should not be taken to mean that a team must use Scrum. There are plenty of contexts where Scrum may not be a good choice for a team or where a team may perform experiments that bring them to a way of working that conflicts with the Scrum Guide. If the team makes these changes and continues to be successful or becomes more successful, those experiments and changes should be encouraged.

So, perhaps there’s a better way to express the concept. But I do think that it’s an important concept to express in the Scrum Guide.

Although the framework is not mutable by others then those who maintain it, Scrum practice and play is anything but immutable. The very Scrum Guide reads that the rules are meant to guide interactions not to enforce them. The game is not played for its rules but for what it amounts to; enjoyment in the play and what it yields. In Scrum, this is about imagining and developing adaptive solutions for complex problems. Scrum practice is anything but immutable. Anyone who practiced Scrum knows Scrum practice is anything but immutable. The way the game is played is far from being incapable or unsusceptible to change. It’s designed to be like that. The drama comes from the misinterpretation that just because the definition is immutable, the play should also be rigid. That is naturally not the case. Although a definition of a ‘beech tree’ in an Oxford Dictionary may be considered immutable, it does not mean the trees themselves are. Each tree emerges and grows uniquely. So it is with Scrum.

@Sjoerd Nijland : since it’s already called rules of the game, and it’s obvious what happens when you don’t play by the rules of a game (you’re not playing the game). What is the added value of the immutability clause then?

What does it prevent? It definitely causes confusion and invites dogma, IMO!

What would happen if it were to be removed?

Maarten

Just because the game has rules, does not mean you can’t play the game in various ways. Also, the rules are meant to guide not to enforce or prescribe the play.

“the rules of Scrum guide their relationships and interactions.“ -SG

Also be careful not to confuse the ‘definition’ with ‘play/practice’.

As in sports you can also break the rules from time to time, but that does not mean you are no longer playing or practicing the game.

Practicing Scrum means you are aiming to get better at it. The Scrum Guide only states that not following the rules may cover up problems and it limits the benefits of Scrum. The statement simply means using the parts does not define the whole. Just because you only apply a Retrospective, does not mean you Scrum. Although one might begin Scrum practice by applying Retrospectives and taking it from there.

I agree that if you were to interpret so that you MUST follow the rules of Scrum to the letter just for the sake of it then amounting to Scrum then that invites people to stop being intelligent capable individuals. But that would not be the spirit of Scrum. If one reads the Scrum Guide as a whole they will come to understand that dogmatic appliance of Scrum is also not Scrum. You can’t be dogmatic with Scrum, because that wouldn’t be Scrum. That’s the paradox.

So one needs to read the immutability clause in the right context, not take it out of it. It’s not written so to say you cannot use only the parts. It explicitly reads you can use the parts.

The dogma and drama comes from the intention of abusing the clause, not living the Scrum Values, and therefore also not respecting what else is writting the Scrum Guide (ironically). Take this line in the Purpose section of Scrum:

“As Scrum is being used, patterns, processes, and insights that fit the Scrum framework as described in this document, may be found, applied and devised. Their description is beyond the purpose of the Scrum Guide because they are context sensitive and differ widely between Scrum uses. Such tactics for using within the Scrum framework vary widely and are described elsewhere.”

Anything in the Scrum Guide can be misinterpreted and abused when taken out of context. The immutability clause just really lends itself to be taken out of context. And for that reason I do agree that perhaps it could also read something along the lines of:

“Scrum is free and offered in this Guide which contains the only official definition of ‘The Scrum Framework’ which functions well as a container for other techniques, methodologies, and practices. The rules in this document guide individuals on how the sum of the elements work together to form the framework that leads to the benefits outlined in this document.”

Is there any value is changing immutability for “buyer beware”?

Here’s my thought…

One reason for immutability is the concern that if people arbitrarily change the scrum guide or their understanding thereof then it may lead them or for tried and true track. I have some sympathy for this view. As I’ve said before the problem to me is espousing the core value of inspect and adapt but then adding that the framework is beyond inspection and adaption.

To circumvent the hypocrisy but still keep the guide safe for those who have just started learning scrum or are not in a place to change the underlying framework with any degree of wisdom, we could simply change the immutability clause for a warning that says: The scrum guide is tried and tested and should be changed at great risk (or something like that). That way it is no longer immutable but still serves to protect those who are not best placed to understand and manage the implications of changing the underlying framework. There would still be one current version of the guide at any point in time but it would only be a guide and not a religious tome as it to often becomes.

We can agree to a definition of a tree, but each tree grows uniquely. Just because there is a definition of the Scrum Framework does not mean there is only one way it can be played and practiced.

The framework does not define what the painters paint on the canvas.

@Sjoerd Nijland the definition of a tree is a constant until we all agree that it need to be changed. Sg2017 is changed to sg2020 because “we” wanted it to change but its still scrum and a definition of scrum.
In the 20xx version it will still be named scrum but with a new and better definition

@Martin A. Schuurman absolutely. That’s why it specifically states ‘as outlined herein (referring to this specific version of the guide). Many people read way to much in this ‘immutability statement’ because they take it out of context for what it is written. Its just so that we can agree that what is defined here, in the most recent edition of the official Scrum Guide is the true definition of Scrum. Mutating the guide to something else, leaving out elements by anyone else would not constitute as official Scrum.

Scrum authors want the word, the trademark, to have a meaning, and want to control the meaning. And yet the meaning does evolve over time, only people would like to revise the rules of the game to fit their own agendas and that would render things chaotic. Nobody is forced to use Scrum. If someone wants to make its own flavour of the game just own up to it and call it something else.
I see the immutability rule as something akin to protection mechanisms democracies have. If your rule is to be flexible/tolerant/whatever, without protection mechanisms it would mean ultimately accepting inflexibility/intolerance/autocracy, shattering the intent. If the authors consider Scrum as instantiating a minimum viable framework to pursue agility, giving that up could turn into a mess. People should get focused on improving their working systems relentlessly to keep providing value, that’s what Scrum is about.

@Helder Aranha , yes this is why it is there. I really like your terminology of “Minimum viable Framework” as it resonates well. Adding to your good point, it is there to protect people changing Scrum so that it compromises the framework, yet call it Scrum and then afterwards start blaming Scrum for failer. Ken and Jeff are open to people changing Scrum, but then they simply not should call it Scrum.

It is like following a vegan recipe, then adding meat to it and still calling it a vegan recipe.

@Maarten Dalmijn In my opinion, here is one more statement that needs to be removed/ rephrased:

“The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide.” - Scrum Guide 2020.

It may be interpreted as establishing Scrum as defined in the Scrum Guide even when conditions change and it doesn’t make sense.

I remember a situation when my team decided to abandon Scrum and work with a simple Kanban board. We kept regular meetings, but it had nothing to do with Scrum. Both I and the Scrum Master supported this decision and it worked for us perfectly.

In my opinion, the Scrum Team should regularly inspect and reflect on not only their implementation of the framework, but also the framework itself.

That’s openness and courage ;)

An important not about immutability is that the scrum guide is licenced under the Attribution-ShareAlike model.

This means you can

Share — copy and redistribute the material in any medium or format

Adapt — remix, transform, and build upon the material
for any purpose, even commercially.

As long as

Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.

ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.

No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.

I think you make a relevant point @Pawel Huryn regarding the need to be open to inspect the framework itself.

Regarding the statement on the SM establishing Scrum:

“The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide”

The way I read this, and how I see it; For a team to start with Scrum, to apply it properly by the rules, to establish the full transparency that is needed to inspect and adapt, and continuously learn if the framework is right for the team, then the framework needs to be established, from the start, as defined in the Scrum Guide.