Introducing Scrum Without Doing Scrum
Invoking the immutability rule to disallow the gradual introduction of Scrum is nonsensical
Imagine that you’re in a situation of being able to introduce a team to Scrum where they don’t have any experience with the framework.
How would you approach this?
If you read the Scrum Guide, some Scrum practitioners interpret it to mean that there’s only one approach for introducing Scrum: all or nothing.
Their position is that you have to start by explaining Scrum completely, and then the team has to start doing everything that’s part of the framework.
Here are a few examples of the kind of statements I hear from Scrum practitioners when you suggest it is a viable option to introduce Scrum gradually:
“Scrum only works when all the different parts work together. If a Scrum Team cherry-picks parts of Scrum, then its benefits will never be realized.”
“When you only introduce parts of Scrum, teams may decide to not adopt everything that is a part of Scrum, and that means the value the framework can provide will be permanently diminished.”
“When teams don’t use the full framework, they will run into problems and then blame Scrum for the failure.”
I believe this line of thinking does not make sense. Why wouldn’t you be able to introduce Scrum gradually? I want to stress that I’m not saying you should always introduce it gradually, but why shouldn’t we at least consider it an option?
Here are the two excerpts from the Scrum Guide that influence how people think about gradually introducing 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
“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
These two paragraphs play a big role in the strong feelings some practitioners have about gradually introducing Scrum. A gradual introduction of Scrum is dangerous, and it means you’re not practicing Scrum.
When you read these two sections carefully, the Scrum Guide does not rule out the gradual introduction of Scrum. It only says that when you do that, you’re not practicing Scrum until you adopt all the elements and rules of Scrum. Selective adoption of parts of Scrum may also cover up problems and limit the benefits of Scrum.
I have a different perspective: I believe you’re already practicing Scrum when you’re trying to practice Scrum by following the rules of the Scrum Guide. It’s not helpful to claim something else, as otherwise, I believe most teams in the world are not doing Scrum. You can nearly always find something they are not doing exactly by the book, even if they are trying.
We have to separate two things: the definition of Scrum and the practice of Scrum. Ideally, people practice Scrum according to the definition of Scrum. In reality, people often do not, even if they try hard.
In the Scrum community, when a person writes something negatively about Scrum, we quickly dismiss it as “They were not doing Scrum.” Even if this often is true, it also prevents Empiricism by shifting the blame completely to the practitioner. It’s their fault. They should have been practicing Scrum. The assumption is that people intentionally interpret Scrum in the wrong way.
When I talk about ‘not practicing Scrum’ in this article, I’m referring to Scrum practitioners who believe that you can only practice Scrum by following all the rules perfectly and in its entirety.
Here are two polar opposite approaches you can follow to introduce Scrum:
You introduce Scrum fully from the start. Usually, the team will not completely grasp it and fail, especially because they are familiarizing themselves with too many new moving parts at once. Result: you’re not doing Scrum. But at least you’re trying!
You introduce Scrum gradually. The team will intentionally not be doing Scrum. With 2, the only thing you’re doing is intentionally setting the bar lower to make it easier to learn and understand the benefits of the different parts of Scrum by discovering what happens in their absence.
If you examine the two options closely, these opposites are not that different, as they both result in the same outcome: teams are initially not practicing Scrum. In the first approach it is unintentional, and in the second approach it is intentional.
Let’s examine the gradual introduction of Scrum from a different perspective. Imagine you’re learning something new, like skiing. I have zero talent for skiing, and I sucked at the beginning. My skiing teacher taught me how to ski one step at a time. They didn’t try to start by teaching me how to do parallel turns. I started turning with the snowplow method. Just like with Empiricism, they took it one step at a time.
If my skiing teacher had tried to teach me everything about skiing at once, she would have failed.
The main argument for introducing Scrum all at once is because it’s a purposefully incomplete framework that works best if all the different parts are working together. Otherwise, some practitioners argue, you’re not doing Scrum, and you’re not allowed to call it Scrum.
To that, I say, who cares?
Let’s flip that statement around. Scrum is purposefully incomplete. The point of Scrum is to support you in discovering a better way of working. Scrum expects you to take responsibility for that. Here’s the Scrum framework. It is incomplete. Please discover and add what you need to succeed.
If we expect people to be capable of doing that, why can’t we trust them to take on the responsibility of picking up Scrum gradually? And discovering and learning the purpose of each part at their own speed and volition?
Should we introduce Scrum by coercion, do everything in the Scrum Guide as we say, so that we are following the Shu approach in Shu-Ha-Ri. Or could a piecemeal introduction through small Shu slices of Scrum through invitation work?
This all sounds highly theoretical. Let’s bring it back to the real world and explain how you could introduce Scrum gradually. I want to stress that this option is only viable in an environment with psychological safety. The Scrum Master should create a safe environment for the Scrum Team, so it’s okay if they fail. If this is not possible, then this is not a suitable approach.
You also need an experienced Scrum Master who understands the purpose of each of the elements of Scrum so that they can guide the team in their learning and experimentation journey.
1. Explain the foundation with a subset of Scrum
The Scrum Master can propose the subset to start with or let the team decide after a brief explanation. A bit more guidance is probably recommended since the team isn’t familiar with Scrum yet.
Here’s an example of how you could start:
Empiricism
Scrum Roles
Sprint
Sprint Goal
Sprint Retrospective
I want to stress that it is important to explain the purpose and how the different elements relate. It’s also important to underline that what is left out isn’t that important because the point is to discover how Scrum works.
Imagine the team runs into problems or impediments during the Sprint where one of the Scrum events or rules could help. Then, the team can pull any rule or event in as necessary. But now, at least they have experienced the pain or problem of not benefiting from it.
2. Perform a Sprint Retrospective
At the Sprint Retrospective, the Scrum Teams will discuss problems they encountered. After discussing the problems, the Scrum Master runs through a board with stickies that contain missing elements of the Scrum framework and explains the purpose of each:
Product Backlog
Scrum Values
Product Goal
Daily Scrum
Sprint Planning
Sprint Review
Definition of Done
Then asks, given the problems we have encountered during the Sprint, which one of these could be helpful? Which ones do you want to try out?
The team pulls any of the elements it believes to be useful to help with the problems they have encountered and applies them during the next Sprint.
For example, you may be thinking, why aren’t the Scrum Values part of the initial list I started with? They will be pulled in when the team runs into problems, and then the team will have a deeper understanding based on experience and not just by parroting what someone tells them.
3. Repeat until all elements of Scrum have been introduced
You might be thinking, wait, if we give people such freedom, what if they decide to leave elements of Scrum out permanently and make it less powerful?
You’re worrying about the wrong things and I believe it’s important to look at the bigger picture here.
Scrum is purposefully incomplete. Without experimentation, learning, discovery, and failure, you will never deliver value with Scrum.
It’s more important to cultivate your team’s ability to learn, experiment, inspect and adapt. To place trust in your teams so that they are capable of discovering better ways of working.
Because that’s what Scrum is about: transparency, inspection, and adaptation. Self-managing teams that discover how to deliver value better using Scrum as a foundation.
What better way to show Empiricism, Respect, Courage, and Openness than by inviting people to try parts of Scrum and discover how they really work and what value they bring?
And most likely, you will still end up with Scrum according to the Scrum Guide. The difference is your team will have a richer and deeper understanding of the role each of the different parts of Scrum serves, and you’ll also have more buy-in in the end.
Isn’t that way more valuable than spoon-feeding and forcing people to do something because the rules say so?
In the words of Confucius:
“What I hear, I forget. What I see, I remember. What I do, I understand.”
I invite you to worry less about perfect Scrum and worry more about your Scrum Team being able to discover the better ways of working necessary to deliver more value with Scrum.
If you can’t trust your team to discover the value the different parts of Scrum have, how can you trust them to discover better ways of working on top of Scrum? If you doubt the judgment of your team, maybe you should reconsider your initial choice to work with Scrum? You should not underestimate how much discipline and ownership Scrum requires to succeed.
Worry whether your Scrum Teams are continuously discovering better ways of delivering value.
Scrum Guide adherence is supposed to support the team in discovering better ways of delivering value. Grant your teams the trust and freedom to discover that purpose on their terms.
Your customer does not care about Scrum Guide adherence — only to the extent it results in the delivery of value.