Three powerful guardrails that make it possible to shrink The Scrum Guide
The latest release of The Scrum Guide in November 2020 has some welcome changes. One of those modifications is being less prescriptive. It was already lightweight, and now, it’s even lighter—down from seventeen to eleven pages.
Many references in the new Scrum Guide allude to less prescription, for example:
- Self-managing team behavior (“who,” “how,” and “what,” and “when”).
- Explicit intent of Scrum application beyond software development.
- A heavy focus on “why” through a Product Goal and Sprint Goal instead of “what” the team is delivering.
- No hierarchies or separation between Developers, Product Owners, and Scrum Masters. Now we have one team, and the Development Team is no more.
- Less instruction on how to run the Scrum Events.
- The Scrum Team now has accountabilities rather than prescribed roles.
Scrum has always been obscure on the “how.” For instance, a working, “Done,” releasable Increment is the Artifact of the Sprint. This is a worthy goal for sure, but the new Guide remains silent in how to achieve it.
With less prescription, what do teams and organizations do when they don’t know the “how?” What do they do when their experience is low and they are starting on their journey? Is less prescription a good thing for these types of teams?
In this post, I will explore this topic. Let’s dive in.
Do we need guardrails?
The Scrum Guide now has crystal-clear guides on Scrum Theory, Values, Teams, Events, and Artifacts. It is lightweight, and it is incomplete on purpose. Scrum requires you to use transparency, inspection, and adaptation to deliver value.
While less prescription can be liberating, some might feel wary of this aspect of the new Guide. For instance, how does a team new to Scrum start to find its way? Teams need more guidance when they are learning new behavior. And less prescription means less guidance.
The Scrum Framework has always been helpful to new teams. While lightweight, it has provided enough guidance to allow teams to move away from a chaotic “try whatever we can think of” approach. If teams innovate with no boundaries, they experience more failed experiments than necessary. But if they can use the basic guardrails of Scrum to point them in the right direction, their journey will ease.
Though the new Scrum Guide is less prescriptive, the remaining guardrails are powerful. I will elaborate on three guardrails, which help teams stay focused on the prize.
Guardrail №1–The “Why” is the ultimate guardrail
A goal provides a purpose to encourage innovative team solutions. Prescribing a plan of what to build and how to build it does not.
If we have a goal, a “Why”, as our focus, the plan ceases to be the target. We begin to rely on experimentation rather than prediction. This is analogous to using a compass and responding to the terrain rather than relying only on a map.
The 2020 Scrum Guide emphasizes the “Why” through Product Goals and Sprint Goals.
It (the Scrum Team) is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
The whole Scrum Team collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.
—The 2020 Scrum Guide
When we commit to achieving the Product and Sprint Goals, we fixate on the goal and try options to reach it. We have a purpose. A purpose drives our behavior and each small step we take to reach it.
Focusing on a goal to guide us beats a fixed scope and a fixed process. It will break us free of command-and-control behaviors and an overemphasis on planning. After all, responding to change over following a plan is a primary Agile tenant.
Guardrail №2– Self-managing teams align their behavior to the “Why”
The 2020 Scrum Guide emphasizes team self-management. This moves beyond self-organization from prior versions of the Guide. A self-organizing team focuses on “who” and “how.” But the new Guide specifies a self-managing team also determines “what” they work on and “when” they work on it.
We often assume this allows a Scrum Team to work on whatever they want in whatever way they want. Then, to combat this assumption, we, in error, drive teams to commit to the Sprint Backlog. We even go as far as tracking committed Stories versus completed Stories per Sprint.
When we commit to a Sprint Backlog, we focus on the plan, not the goal. The 2017 Scrum Guide helped move past this by changing the word “commitment” to “forecast.” Now, the 2020 Scrum Guide brings back the word commitment, but it focuses on goals, not plans—a welcome change.
Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:
For the Product Backlog, it is the Product Goal.
For the Sprint Backlog, it is the Sprint Goal.
For the Increment, it is the Definition of Done.
These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.
—The 2020 Scrum Guide
Committing to a Definition of Done provides a guardrail for “how” the team works and “who” makes up the team. Delivering a potentially-releasable Increment requires collaborative, skilled teams with deliberate habits. No light remains for behaviors and team members that work against the “Done” goal.
By committing to a Product Goal and a Sprint Goal, “what” the team works on and “when” they work on it becomes constrained. Only options aligned to the Product and Sprint Goals move a team closer to their commitments. Goals help filter out the noise and apply focus on what progresses the delivery of value.
Guardrail №3–A coach enables new behavior patterns to emerge
Having a “why” and a self-managing team focused on it sounds great. But are teams and organizations able to operate like this on day one? Autonomy is not magic.
Having an experienced guide for a team or an organization new to Scrum speeds up learning. Without an expert guide, our past behavior can get in the way of learning a new skill.
“We cannot solve our problems with the same thinking we used when we created them.”
—Albert Einstein
The Scrum Master as coach
The new Scrum Guide specifies Scrum Masters as coaches for the team and the organization. They lead, train, and coach. This implies that your Scrum Masters have experience in Scrum and Agile patterns.
Scrum Masters are true leaders who serve the Scrum Team and the larger organization.
—The 2020 Scrum Guide
What do you do if your Scrum Masters are also inexperienced? In this case, it helps to bring in an experienced external coach or Scrum Master. The external guidance will support your Scrum Masters as they gain experience in the role.
Isn’t training and enthusiasm enough?
Training and enthusiasm are great, but they alone don’t translate to new skills.
When it comes to learning new behaviors, training isn’t effective without practice.
And coaching is your best support mechanism as you practice Agile behaviors. It is your highest return on investment when compared with training.
The best mix is to supplement coaching with training and knowledge sharing communities.
And you can’t train experience. Experience in a new way of working is what you get with an experienced Scrum coach.
It’s kind of like a football coach. Would you want a new football team to watch a few training videos and practice and play without a coach? It would likely take a lot longer to produce a winning team that way.
“Tell me and I forget, teach me and I may remember, involve me and I learn.”
—Benjamin Franklin, likely inspired by Confucius
“Will” is important. But “skill” is too. And knowledge does not equal skill. Take the new football team analogy. Even with enthusiasm, and after watching many training videos, the team hasn’t played the game. And if the team hasn’t played the game, they don’t have the skill.
How to learn new skills
The best way we learn new skills is by first repeating and mastering one technique, guided by an expert or coach. Before trying alternate techniques or improvisation, we must first learn one foundational technique.
A great example of how we learn is described in the Shu-Ha-Ri technique. Many other similar analogies come to mind, such as learning to play an instrument, play jazz, and dance. Let’s take, as an example, how you learn to dance.
You have a piece of paper on the floor to guide your steps and an instructor to correct your moves in the moment. Once you learn the basics through repetition, you discard the paper. And the instructor becomes less instructive. Only after you learn the basics can you venture to try new techniques and improvise.
These are the same learning patterns we need when we try Agile behaviors for the first time. We need a coach to guide us. And the Scrum Master is this coach.
So now what?
I am excited by the changes in this new Scrum Guide. The reduced prescription is a welcome change. Less instruction is balanced by the goal-driven focus of self-managing teams, supported by coaching. And this will eradicate undesirable, instructive tendencies, which erode the value Scrum can achieve.
Scrum Teams now own the entire value chain from concept to cash. They are responsible for all the required, product-related activities. This elevates the importance of teams, and it is excellent.
What experiments will you try today to focus on your “Why?”
Also published in Serious Scrum on Medium.
Related Posts
Read more below for posts related to this one:
Todd Lankford unlocks Lean Leverage in organizations to cultivate powerful, engaged product teams who maximize outcomes and impact.
His articles share his experiences and learnings along the way. Join the mailing list to get them in your inbox.