A Deeper Look: Top Changes in the New 2020 Scrum Guide for Agile Practitioners

A new version of Scrum guide was released in November, 2020. There are quite a few changes in the guide, as well as new additions. While the outline and structure of the guide have remained almost the same, as you go through the guide, you will immediately notice three high-level changes:

• The new guide is a much lighter and smaller version.
• It’s less prescriptive and seems to be intended for a wider audience group, particularly non-software users.
• It contains commitments for each of the Scrum artifacts.

In this article, I’ll outline the top changes and the deeper meaning associated with each change. My perspective is based on my analysis, my own interpretations, and the interactions I’ve had with Agile practitioners who follow my publications, books, and/or courses. 

Product Goal

The Product Goal has been defined clearly. It’s not an introduction because it existed earlier, but in the previous version, it was mentioned along with the vision.  

As per the guide, the Product Goal is the future state of the product. This definition of the ‘goal’ can create confusion for many who understand project-program-portfolio management and how goals aligns with the vision, mission, strategy, and objectives of an organization.

Ideally, the vision is the future of a product or program/portfolio or an organization. A vision is always associated with goals, without which a vision has no value or meaning.

However, as you look closely at the new guide, a big picture emerges:

• The Product Goal is the long-term objective of the team.
• A team works on and fulfills a single objective at a time.
• Before tackling another objective, the team has to fulfill (or abandon) the objective they are currently working on.

In other words, the goal is written with one or more objectives for the team. As the product roadmap is prepared, it gives further directional clarity to the product goal. The product goal should be linked to the strategic goals of the organization. One could summarize this by saying:

• The Product Goal is more strategic in nature, whereas,
• Sprint(s), mentioned as a project in the guide, will be tactical in nature.
• With each Sprint (iteration), the product moves closer to the product goal.

The Product Owner (PO) is the person who is responsible in building, and clearly communicating product goal to the team. The items in the product backlog (PBIs) should map to the Product Goal. Product Goal also reflects one of the values of Scrum: “Focus.” The team, as earlier noted, should focus on one objective at a time.

Now, you may be wondering what happens when multiple teams are working on the product backlog?

Regardless of the number of teams, there will be a single product backlog, a single PO, and a single product goal. This is depicted in the figure below.

 

Commitment based Artifacts

Now, every artifact in Scrum comes with a commitment.

The formal artifacts in Scrum are three:

• Product Backlog
• Sprint Backlog
• Increment

Now, all these artifacts come with commitments to ensure transparency and progress.

• For Product Backlog, the commitment is the Product Goal.
• For Sprint Backlog, the commitment is the Sprint Goal.
• For Increment, the commitment is the Definition of Done (DoD).

While Product Goal is newly introduced, Sprint Goal and DoD (earlier called “done”) existed earlier. In the new guide, all of these have found homes. For example, the home of Product Goal is the Product Backlog. 

At this point, it may be useful to note that “Commitment’ is also one of the values of Scrum, others being Focus, Openness, Respect, and Courage. Hence, one can say that commitment-based artifacts are reflections of one of the Scrum’s values. Commitments also increase “Focus,” another Scrum value.

I’ve mentioned the values here, because I believe they are very important, but you shouldn’t confuse values such as openness, courage, honesty, etc. with the value that you get while delivering an increment, although the latter is also important.

As the saying goes, “Culture eats strategy for breakfast.”

In my view, it’s actually the values and value-system which eat strategy for breakfast. Strategy execution is the downstream of culture. Culture is the downstream of human, team, or organizational values. And values are the downstream of the philosophy on which civilizations (or a team/organization) is based.

At times, values are thrown around like punchlines, brandished as political weapons, or misused for self-serving interests. It’s true adherence to values that really matters because without values, nothing really works. This is true for a person, team, organization, or even a civilization.

As we proceed through the other changes, I’ll continue to reflect on the Scrum values. 

Multiple Increments

Earlier it was mentioned that an Increment will happen at the end of Sprint. Now, within a Sprint, multiple Increments can happen.

An Increment happens when a backlogged item meets the DoD. Hence, an Increment can be created at any point of time during a Sprint. This is depicted in the below figure. 

As shown, at the end of the Sprint, we have Increments. Increments can also happen at any time during the Sprint. The new guide clearly informs that Sprint Reviews should not be considered “gates” for releasing value.

As there can be multiple Increments, the sum of all these Increments are presented to the (key) stakeholder at the Sprint Review. 

Introduction of Cadence

For the first time, we are introduced of a concept called “Cadence.”

This is an important introduction, which is missed by many Agile practitioners. Cadence is used in other Agile frameworks such as Kanban, and is basically a rhythm that gets developed as one continuously follows a set of events over a period of time.

In Scrum, the cadence is provided in the form of five events:

• Sprint – the container event
• Sprint Planning, Daily Scrum, Sprint Retrospective, and Sprint Review – the contained events within a Sprint

I’ll suggest that you read this change along with the previous change of “Multiple Increments.” As you go through these updates together, you can see two things emerge:

• Development is happening in cadence, whereas,
• An Increment can be there at any time during the Sprint.

You can say development (or build) of the product and incremental delivery have been decoupled. In fact, they can be thought to be of two streams as shown below.

As shown, the stream for cadence is decoupled from the stream for increment. The diamond shapes in the cadence stream denote the Sprint Reviews. While there is an increment at the end of the review, on-demand increments can happen at any time, as we see in the increment stream.

Cadence helps with inspection, which is one of the pillars of empiricism. This, in turn, drives another value of Scrum: “Openness.” 

Lean Thinking

Earlier the guide referred to empiricism. Lean thinking has appeared for the first time.

Empiricism is a practice which is based on knowledge coming from experience and what you know or have observed. The three pillars are: Transparency, Inspection, and Adaptation.

To include and encourage lean thinking, the wording in the guide has changed in quite a few places. For example, the guide notes: “Transparency enables inspection. Inspection without transparency is misleading and wasteful.” Again, remember that “Transparency” (or Openness) is one of the values in Scrum.

A key principle of lean thinking is to avoid “Muda,” a Japanese term meaning “waste.” When work is not done after being taken into a Sprint, the result is Muda. With DoD, Muda is avoided. Do remember DoD is the commitment for an increment. With DoD:

• You know exactly what it means to have an increment.
• The team is compelled to complete the items taken, not start taking new items.
• One can say it’s about: Start Finishing, Stop Starting.
• From that perspective, some elements of Kanban have been absorbed into Scrum.

Introduction of “Why” in Sprint Planning

Other than “what” to do in the Sprint and “how” to do it, the “why” aspect has been introduced.

Earlier, before the start of Sprint Planning event, two questions were emphasized:

• Topic – 1: What should be done in this Sprint?
• Topic – 2: How do we do it within the Sprint?

In the new guide, emphasis has been given to Sprint Goal. Hence, we now have three aspects:

• Topic – 1: Why is this Sprint valuable?
• Topic – 2: What should be done in this Sprint?
• Topic – 3: How do we do it within the Sprint?

This is shown in the below figure. 

Sprint Goal has to be collaboratively defined by the entire team. The introduction of Sprint Goal in the Sprint Planning event, reemphasizes a value of Scrum: “Focus.”

Single Scrum Team

Earlier, there was a Development Team within the Scrum Team. There is no ‘team within team’ now.

A Scrum Team is one, and it consists of the Product Owner, Scrum Master, and Developers. This is a step away from the “us-vs-them” mentality created with the term “Development Team” earlier. It also avoids a “throw-over-the-wall” mentality (i.e. my or my group’s work is done and now is the time to throw it over the wall, so that the other group takes care of it!)

Now, the team is considered to be a cohesive unit of people focused on the Product Goal. The PO, SM, and Developers are all intrinsic parts of the Scrum Team. The new version of the guide also notes that the team is the fundamental unit of Scrum.

The single Scrum Team concept enables two values of Scrum: “Respect” and “Openness.” With a single team concept, there is less likelihood of “us-vs-them” mentality.

Also, a single team concept with no hierarchies creates a culture where everyone knows that the team succeeds or fails together, hence candor goes-up. It’s likely to stop compartmentalization of members, prohibit group or community biases, reduce politics, and cripple finger-pointing, and eliminate blame-games and back-biting. If one team member is failing, it means the whole team is likely to fail with their ability to meet the goals of Sprints, the goal of the Product, or the honoring the DoD. The team moves towards, or strives to be, an indivisible whole.

Self-Managing Team

Instead of “Self-organizing,” the team is now “Self-managing.”

Agile teams are cross-functional meaning that they have all the needed skills to do the work and create value in each Sprint. Along with that, whereas the team was described to be self-organizing in the earlier edition, the terminology has now been changed to self-managing. There is a subtle difference between these two terms. Self-managed teams go one step ahead of self-organized teams.

A self-organizing team chooses who will work and how to do the work. A self-managing team, on the other hand, chooses who, how, and what to work upon. In my view, the team can consider the new aspect of “what,” because the PO is now explicitly part of the team.

It’s not that a team will be self-organizing from Day 1 or even within a few weeks of interactions. The team has to go through the stages of team formation, such as forming, storming, norming, and performing.

Also, with the introduction of “what,” the team decides which items are to be taken-up for the next Sprint. This, in turn, reflects another aspect of Lean Thinking: “Muri,” another Japanese term meaning “overburden.” As the team decides what items are to be taken-up, Muri is less likely to arise. When what items are determined at the beginning of the Sprint, it reflects another aspect of lean thinking: Just-in-time (JIT).

Not a Servant Leader, but a Leader who Serves

The Scrum Master being referred to as the Servant-Leader of the team has been removed.

The guide currently notes, “The Scrum Masters (SM) are true leaders who serve the Scrum Team and the larger organization.”

This enables the SM to play a larger role in the organization. The SM is not only now accountable for establishment of Scrum, the SM also leads, trains, and coaches the organization on Scrum adoption. He or she also advises the organization on Scrum implementation.

In my view, this is a positive change because I’ve noticed that the words, “Servant Leader,” have been weaponized by some teams. The SM is not a clerk or secretary to take notes during Sprint events and send meeting emails or reminders. The role of a SM is much bigger with a focus, not only on the team, but also playing a broader role in the organization. This larger aspect is emphasized by putting leadership first.

—

As you go through the new guide, you may also notice changes such as:

• The three questions of Daily Scrum are no longer mentioned.
• One process improvement item from Sprint Retrospective, which must be taken into the next Sprint’s backlog is no longer there.
• The term “useable” has been used in place of the term “releasable,” among many others.

In this article, I’ve elaborated on some of the top changes. I hope you are not only aware of these, but understand the deeper, philosophical reasonings behind these changes in the Scrum framework.

--

This article was first published by MPUG.com on 29th December, 2020.  

References

[1] Online Course: PMI-ACP Live Lessons, Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] Book: I Want To Be An ACP: The Plain and Simple Way, 2nd Edition, by Satya Narayan Dash

[3] The 2020 Scrum Guide, by Ken Schwaber and Jeff Sutherland