The immutable framework definition makes it impossible to criticize Scrum

Scrum is too easy to misinterpret — are we to blame, or is it the fault of Scrum?

I want to preface this article by saying I love working with Scrum. I am not writing this from a place of bitterness but a position of affection. I’d like there to be more openness when discussing the flaws of Scrum. I also want to stress I’ve written far more positive than negative articles about Scrum.

When I publish an article where I criticize Scrum, I keep receiving the same dogmatic rebuttals from Scrum practitioners. The time is right to address the elephant in the room: let’s stop pretending Scrum is perfect.

The Scrum garden of Eden

I’m still waiting for that moment where I join a team as a newcomer, and I’m impressed by how they do Scrum. The fact this still hasn’t happened over all the years I’ve practiced Scrum is concerning.

I do realize this is anecdotal evidence. But in all the teams I’ve joined over the years, surely there should have been a team that nailed Scrum? Or at least got the fundamentals right?

Both didn’t happen. I always encounter the same problems and misunderstandings over and over again. This remains true even if a team has an experienced Scrum Master or worked together with Scrum for many years.

What does this say about Scrum?

Scrum imperfections in practice

Here are some recent examples of discussions I had as a Product Owner when I started with a Scrum Team that had an experienced Scrum Master:

“Let’s do a Sprint 0 before we do a real Sprint. We can’t start a real Sprint yet.”

“We should plan a team day so we can create a team charter and set team agreements.”

“It’s not possible to start the Sprint without setting a Definition of Ready first.”

If you’re an experienced Scrum practitioner, you’ll probably raise an eyebrow and think: “Hey! None of those things is actually part of Scrum!” You’re right. Hold on to that thought. I’m circling back to you later.

Here are even more common misunderstandings despite the supposed simplicity of Scrum:

“We can’t change the Sprint because the Sprint has already started.”

“We must have a Sprint Goal that relates to all items in the Sprint Backlog.”

“Our Sprint Burndown is erratic, and we completed less work than in the previous Sprint. We are doing something wrong.”

Now to get back to my main gripe with Scrum — every team I join sucks at doing Scrum. Either because they do Scrum wrong or because they think Scrum includes certain elements it doesn’t.

After failing to find a single team that rocks with Scrum over all those years, is there a moment where we stop blaming the people who use Scrum and start blaming the framework itself? Surely Scrum must undergo inspection and adaptation, too? Is Scrum too easy to misunderstand?

In the Scrum community, this kind of discussion is immediately silenced. Empiricism is welcome, except when you shine the light of Empiricism on Scrum itself by saying it often doesn’t work out as expected.

When Scrum fails, you always hear: “But you’re not doing it right!”.

As we say in Dutch:

“The beam of the lighthouse doesn’t shine on the ground underneath it.”

A lighthouse is a beacon of light to its surroundings, but its light doesn’t shine directly below on itself.

Just like the lighthouse, Empiricism doesn’t apply to Scrum itself. Scrum is meant to be used as-is, and you’re not supposed to change it based on experience. Only Jeff and Ken are allowed to do that.

Let’s assume that Scrum, like anything else in this world, isn’t perfect. What can we improve in the framework? How can we inspect and adapt it to be even better? What are the fundamental flaws that are present in how it is explained that should be amended?

Asking these kinds of questions isn’t appreciated. Experienced Scrum practitioners will resort to ad hominem attacks and claim you don’t get Scrum. Scrum is simple and perfect. Stop criticizing it.

It’s as if you’re talking to someone about religion instead of talking about a framework that is supposed to help deliver value. These responses are frustrating, as this prevents transparency about the state of Scrum. Transparency is something all Scrum practitioners should care about.

Scrum dogmatism in a nutshell

The Scrum dogma goes as follows: Scrum is perfect the way it is, and it’s not supposed to provide answers. Scrum doesn’t tell you what to do but shows you what is going on. It puts the ball in your court to do something about it.

The two primary arguments I hear for Scrum being flawless the way it is:

1. Scrum is a simple and purposefully incomplete framework. Scrum isn’t enough to deliver valuable products, and you need to add things to make it work. If Scrum fails, the people fail and not Scrum itself. Scrum isn’t supposed to fix your problems. That’s up to you.

2. Scrum is immutable. If you do a single thing differently than written in the Scrum Guide, you’re no longer doing Scrum. Therefore, Scrum doesn’t fail. You fail.

Scrum is a pristine and perfect creation. We Scrum practitioners are like Adam and Eve, bound to make a mistake and be banished from the Scrum garden of Eden. Failing at Scrum means you’re either no longer doing Scrum, or you’re not supplementing the framework with something it needs to succeed.

In short, Scrum never fails. The immutability of Scrum, together with that it’s a framework, is a great cop-out. It’s the perfect excuse to claim Scrum always works. Because if it doesn’t work, you’re not doing Scrum.

But if this line of thinking is reasonable, then the reverse is reasonable too: Scrum can’t be responsible for the success of any of the teams practicing it. If failure cannot be attributed to Scrum, then neither can success. Scrum doesn’t work. It’s the people that make it work.

“If failure cannot be attributed to Scrum, then neither can success.”

Scrum reminds me of the game ‘Dwarf Fortress’ — a game so challenging its tagline is “Losing is Fun.” An insanely challenging survival simulation created by two brothers, the game’s goal is to keep your dwarf stronghold alive as long as possible.

But no matter what happens, you will never succeed at keeping them alive. It’s a grueling, difficult game with an impossibly steep learning curve. Doing Scrum feels just like that: no matter what you do, you will lose at playing Scrum. And when you do, you are to blame, and not Scrum.

Is the point of Scrum to follow the rules?

The Scrum Guide has the following subtitle: ‘The rules of the game.’ The Scrum Guide provides rules to a game you can follow. If we reflect on Scrum being a game with rules to follow, what does this imply for following the rules?

Imagine you’ve never played Monopoly before. When you start playing Monopoly, after a few games, you fully understand the rules. With Scrum, many teams still don’t comprehend the rules after many years of working together. Even though there often is a Scrum Master there who should have gotten through to them by now.

Does this mean we need to improve the rules? Shouldn’t the rules be so simple that you can pass them on through the oral tradition, much like what happens in the game of Monopoly? Who reads a manual anyway?

Why wouldn’t it possible to adapt Scrum so you don’t need a dedicated Scrum Master to teach it to you? Where the team can pass it on accurately to other team members? Shouldn’t that be the goal of an Agile framework? That it’s so clearly described and reasonable that you don’t need to hire a new role to teach you?

I want to stress, I’m not saying we don’t need Scrum Masters. I’m not saying the only job of a Scrum Master is to make others understand Scrum. I’m saying you shouldn’t need a Scrum Master to understand Scrum. At the moment, even with Scrum Masters, many teams do not understand Scrum.

Let’s aim to make Scrum so simple and clear that you don’t need a Scrum Master to get it. Maybe this isn’t possible, and we won’t succeed. But I still believe we should inspect and adapt Scrum to see how far we can get.

Originally this was what happened when there was no Scrum Guide. Scrum was passed on through word of mouth and writings, with no formal definition being available. Let’s call it the ‘Wild West of Scrum’ period. But the situation has changed since then.

Now, we have an official Scrum framework definition, which is protected by an immutability rule. Scrum’s immutability and framework philosophy is phrased as follows:

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 — Scrum Guide 2020

Scrum became a success because it wasn’t immutable and passed on to others who added and expanded upon it to make it even stronger. Ken and Jeff have created Scrum, but it’s the collective work of a much larger community that made it even better and successful.

I understand why the immutability rule is present in the Scrum Guide. It’s there to prevent people from diluting the effectiveness of Scrum by only implementing parts of it as they see fit. And then claiming that Scrum fails.

Scrum requires you to experiment, and you should even experiment with Scrum. Nothing is perfect, and holding on to the assumption that something is perfect goes against Empiricism. Even if it’s as simple as Scrum purports to be.

Scrum isn’t simple. It isn’t easy to understand. If anything, it is easy to misunderstand.

We should be more open to discussing Scrum, its flaws, and what we can do to fix them. Let’s start with the perspective that Scrum is imperfect and ripe for improvement.

Could we make Scrum so easy to understand you don’t need a Scrum Master to explain it?

When a team that adopts Scrum fails, it can be the fault of Scrum too.

We need to stop blaming the people for the mistakes Scrum sets them up to make. Scrum is too easy to misinterpret. What can we do to change this without requiring a Scrum Master or expensive training to explain it better?

Why wouldn’t it be possible to create a framework that works and can be passed on accurately by the people practicing it? Why should we need an overhead role to explain the rules of the game? If we need a separate role to explain the rules of the game, maybe the rules of the game are too difficult?

We should try to make the framework as simple as possible and adjust it to be prone to fewer misunderstandings. There’s no harm in operating under the assumption we can make Scrum even simpler.

Defining Scrum as an immutable framework doesn’t provide a get-out-of-jail-free card for the misunderstandings it causes. Empiricism also applies to Scrum itself.

We should adapt Scrum so the right seeds are planted instead of having Scrum Masters removing the weeds that have already grown.

Let’s drop the dogma attached to Scrum and open the door for Empiricism.