Imagine a stencil. It leaves the insides open to your implementation. You can place your stencil on paper, color the interiors, make intricate patterns, or trace along the boundary. The outcome holds the same shape regardless of the fill you choose to put. Similarly, your practices fill the voids within the Scrum framework, reflecting the collective intelligence of people using it.

One can understand the elements of the Scrum framework by studying the Scrum Guide, and then through practice can uncover how the underlying philosophy, theory, and structure help to achieve goals and create value.

The Scrum Framework is immutable.

The special sauce of the Scrum Framework is that it has consistently maintained itself in the goldilocks zone of “just right. “ It is neither prescriptive in its practices nor loosely defined to be misunderstood.

“The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.” – The Scrum Guide

The Scrum Guide could not be any clearer. The Scrum framework knows its boundaries and leaves gaps, much like a stencil, to be filled in by the people involved with Scrum implementation. This purposeful incompleteness is intended for practitioners to reflect on the needs of their specific context and then fill in practices that support their product goal.

People’s ability to iterate and improve their practices reflects their collective intelligence as a team and organization. Scrum is not implemented within a vacuum. Scrum puts to test the processes that your team and organization employ to develop products.

Can you develop a product increment within one sprint? This is the most basic test of the efficacy of your management practices and work techniques.

“Various processes, techniques, and methods can be employed within the framework. Scrum wraps around existing practices or renders them unnecessary. Scrum makes visible the relative efficacy of current management, environment, and work techniques so that improvements can be made” – The Scrum Guide.

Scrum is founded on values of Courage, Focus, Openness, Respect, and Commitment. The Scrum Framework is a double-loop learning framework that believes that following the rules of the Scrum game and living the Scrum values will improve the collective intelligence of the Scrum team to inspect and adapt its processes.

When the values of Scrum are ignored, and only the mechanical aspects of the framework are implemented, then the implementation devolves into Dark Scrum. Excluding instances where the spirit of Scrum was killed, I have found that the collective intelligence of a Scrum team indeed improves over time. Like any other game, the players get better through mindful practice.

For example, a Scrum team adapted their Daily Scrum to visualize their confidence in meeting the current Sprint goal commitment by developing the Team Confidence chart. 

The Team Confidence chart is a novel technique that this Scrum team utilized to align its daily efforts to meet its Sprint goal commitment.

Another more common example is the practice of User Stories from eXtreme Programming (XP). User Stories enable direct conversations between stakeholders and developers and are commonly adopted by Scrum teams.

Similarly, numerous other practices are adopted by Scrum teams worldwide. But these are not included in the Scrum guide core elements. Not including all the possible techniques, whether novel or popular, is the strength of the Scrum framework. The game’s rules need not be too few nor too many, but just right. The power of the Scrum framework is in its explicit articulation of the rules of the game. 

Playing within the rules of this game, different teams will use different techniques. Using a soccer (football) analogy, some teams prefer a tiki-taka (possession-based) approach, while others employ a more direct long-ball approach. Both these approaches to soccer require different player competencies to win games. The rules of the game are the same, but players play differently.

The Scrum Guide ends with

“The Scrum framework…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.” – The Scrum Guide.

The term immutability has been a constant source of consternation for LinkedIn “experts” who drive likes and “engagement” by bashing the immutability aspect of the Scrum Guide. I hope to clarify why the Scrum framework’s immutability is essential.

Unable to be changed

Over time the Scrum framework has evolved, and right now, at this moment, there is only one definition of what Scrum is and what it is not. To maintain its integrity, the rules of the game of Scrum must be followed to be considered Scrum. This is no different than any other professional sport. The game’s rules change over time, but there is a single set of rules to be followed at any given moment.

If you show up to a Soccer or American football game with a baseball bat intending to hit the ball, you will not be welcome. This is not to say that you don’t enjoy playing baseball, but with any team sport, check with your teammates what game you’re playing and, as a result, agree on the rules. Otherwise, you will spend significant time arguing about the rules and not have any fun playing together.

What if Scrum, as defined in the Scrum Guide, does not work for us?

Then don’t play the game of Scrum. It is not illegal or unethical to not use Scrum. However, it is dishonest to make material changes to the Scrum framework and still call it Scrum.

For example, if you drop the practice of Daily Scrum and people synchronize once every three days, then it is no longer Scrum. Your team may be better because of this modification. Have the courage to re-label your implementation as Scrum-Minus or Scrum-With-Out-Daily-Scrum or whatever other name you call it.

On the other hand, if you believe that the Scrum framework can benefit from the Theory of Constraints and concepts of Lean, then take a cue from Corey Ladas, who describes the ScrumBan approach for Scrum teams to benefit from flow-based Lean approaches. I appreciate Corey for his professional integrity in coining the term ”ScrumBan,” which utilizes elements from the Scrum Framework and Lean Kanban systems as a distinct path for people to implement and eventually grow out of the “training wheels” (Scrum).

It is not important whether I agree with ScrumBan or not. The critical point I’m trying to make is that if you implement only parts of Scrum or make modifications, you don’t call it Scrum. Give it a new name.

Unchanging over time

This is objectively false. So is it mutable? Well..No! Let’s look a little deeper.

Page 1 of the Scrum Guide states that the Co-creators of the Scrum framework have evolved the Guide since they wrote the first version in 2010, and “together, we stand behind it.” The authors (also co-creators) of the Scrum Guide state that they have continually evolved it “through small, functional updates. “

A minor change for the authors may represent a significant change for others. For example, in the 2020 update, the shift from roles to accountabilities caused a considerable stir in the practitioner community. My opinion on the specific changes is not relevant here. What is of importance is to acknowledge that the Scrum framework has gone through revisions over time.

Yet going through many changes over the last decade, it has remained recognizably immutable. Ask any practitioner to draw the Scrum framework, and they will sketch the all too recognizable double fluffy loop. The Scrum team retains autonomy over its processes, plans at the start, reviews, and retrospects at the end of the sprint. Maintains a product backlog that interfaces with stakeholders and a sprint backlog to manage work within the sprint. So yes, there have been many adjustments, but the essence of the framework remains immutable.

Who gets to decide the rules of the game?

And as it stands, the co-creators get to set the rules of the Scrum Game. Through the Scrumguides.org site, they accept proposals for future revisions to the Scrum Guide by enabling anyone to send an email to [email protected]

This is no different from the open source movement, where key contributors or founders are responsible for what a thing is and will be. And therefore retain the highest authority to decide which modification will be incorporated within the Scrum Framework.

“Cui bono” – “To whom is it a benefit” – Cicero


“Ambiguity can arise from the use of ambiguous names but cannot exist in fact themselves.” – Aristotle.

For centuries, ancients have been aware of all too human tendencies to misrepresent through the overloading of terms. The Scrum Guide serves an all too important purpose of laying the facts so anyone with reasonable acumen can ascertain whether they are following Scrum.


And it is ok if you are not interested in using Scrum, and it is also ok if you are trying your best and still falling short under your current organizational circumstances. Learning a game takes time, and it takes longer still to appreciate the game’s rules. Only experience can illuminate why certain core design elements and rules are put together the way they are. You can benefit from the collective wisdom of countless Scrum teams who have faced similar challenges and learn how to get better at playing the game. Or not.


Before you engage with another clickbait merchant, consider what they are selling. Do they have skin in the game, and are they willing to stand for their “better” approach/method, or are they simply Scrum-bashing to tap into your frustrations at the moment to get you emotionally worked up for attention?

Blau Emblemàtic (emblematic Blue)

Antoni Tàpies was a Catalan Painter, sculptor, and art theorist. I was fascinated by Blau Emblemàtic (emblematic Blue), which I got to experience at the Fundació Antoni Tàpies (The Antoni Tàpies Foundation).

The interpretation of art tells us more about ourselves than about the artifact. So forgive my interpretations, for it has driven me to reflect on the commentary surrounding the Scrum Framework’s Immutability.

A framework is abstract. This thing we call Scrum is much like the cloud. It “is” and yet “is not,” constantly changing yet retaining its form to remain recognizable and distinct. For some, it may be the fluffy white cumulus, and for others, the dark rainy nimbostratus, but it is still a cloud.

To expect that every Scrum team, in every sprint, will adhere with precision to the rules of the Scrum game is unnatural. Like every other human endeavor, there will be fouls and mistakes. The game’s rules and values are defined so these can be readily referenced.

Hopefully, you will pay heed to deviations and can steer your way back toward the game as it was designed to be played. Your experience with Scrum will depend on your organizational context and its suitability to support your team efforts. As an immutable thing, the Scrum framework has provided a consistent north star for how the product development game can be played. Some play it well, others do not, and the rest complain about why they don’t get picked to join a team.