December 3, 2021


News for Agilists

Scrum Guide 2020 — One Team, One Product | by Patrick Schönfeld | Serious Scrum | Nov, 2020

Going the extra mile to make core concepts of Scrum more clear. A commented overview of the changes in the new Scrum Guide.

Photo by Adi Goldstein on Unsplash

Big words were used to announce the new version of the Scrum Guide. Now it is finally released. In this story, I want to give an overview of the things that I took note of.

A lot has changed in this version.

Well, many changes aim to make it easier to read and understand. But that’s not all. Funny enough, that the new Scrum Guide is a demonstration of well-known Scrum wisdom. Building a potentially releasable Increment doesn’t equal an obligation to release it. But, the new guide says, delivering more often than once a sprint, is entirely valid. That only as an interesting side finding.

There are however two more significant changes I would like to look at.

One Team, Focused on One Product.
Revision history of the Scrum Guide

One team and one product could very well describe the overarching theme of the new Scrum Guide.

The team has always been important for Scrum. But with the changes, there is no longer a team in the team. Instead, the Scrum Team is seen as one team. Meanwhile, there is a new kid on the block: the product goal.

The Product Goal describes the future state of the product. It should support the team in planning their Sprints. The Scrum Guide describes it as long-term objective of the team. Unsurprisingly, the Product Owner is responsible to develop and communicate that goal. Involving the team for defining and refining the goal is certainly still valid. At least that would be in the spirit of Scrum. And after all, we are usually more likely to achieve goals if we were part of defining them.

The Scrum-Team collaborates towards that said goal. As a team they decide what happens, when and how. In fact, the Scrum Guide explicitly says that the Scrum Team handles all tasks. As examples, it lists the collaboration with stakeholders, experiments, maintenance operations among others.

Fighting dysfunctional patterns

The change tries to fight “us and them” situations and avoid the Product Owner to become a bottleneck.

We know that some patterns are unfavorable. For example, when the Product Owner acts like a proxy. Like, if he shields developers from contact with stakeholders. The one or other anecdote taught us — or even painful practical experience. This pattern does not only make the Product Owner a bottleneck. It also bears the risk that the developers lose a sense for the customers’ needs.

The Scrum Guide tries to defeat those patterns with the new approach. So that change affects many places in the guide. It changes the accountability of the different roles, for example. In fact, the Guide no longer talks about specific roles but about accountabilities.

I will not get into the details of those changes, as the new Scrum Guide is an excellent read in that aspect.

Of course, Scrum is still based on the idea of empiricism.

That’s not a new thing. But in the new Scrum Guide the authors go the extra mile to make that really, really clear. Really.

This is already evident in the Definition of Scrum. It now emphasizes what kind of environment the work of the Scrum Master should foster.

So, the Scrum Master should foster an environment, in which the whole team can focus on what is essential:

  1. Maintenance of the Product Backlog
  2. Working on the Product
  3. Inspecting the Product with the stakeholders
  4. Repeat

New in the Scrum Guide: a statement that makes it explicit, that Scrum is also founded on the ideas of Lean Thinking.

Scrum is “lightweight, simple to understand and difficult to master”, it so far said. This catchphrase is now finally gone. For the better, I would argue. Considering the many misconceptions in the wild, that always felt out of place. It just doesn’t make sense to call something simple if for many that is not the case.

In the basics, the following caught my eye:

  • Rhythm is important. The guide now clarifies that the events should contribute to a rhythm for inspection.
  • Empowerment is crucial. A note says how hard it is to adapt to findings if the team is not properly empowered.
  • The best time to adapt is right after detection. The guide clarifies when to react to findings in the inspection events. It should be as soon as possible, but ideally right after detection.

The last point in particular is very much in line with current DevOps practices. It also shows the influence of Lean Thinking. The Toyota Production System has the concept of the “Andon cord”. The idea: whenever a problem occurs, people should pull it, which would bring the assembly line to a halt. After that people should focus all their efforts on solving the problem. The logic is that defects are cheaper to fix and have a less severe impact, if they are handled early.

In the events the focus was clearly set on removing prescriptive statements. But there are also some other noteworthy details to discover.

The Sprint

Sprints are the heartbeat of Scrum, where ideas are turned into value.
— Scrum Guide 2020

The sprint is now called the heartbeat of Scrum. This emphasizes again that the Sprint is about rhythm and not about speed.

The creators decided to stay true to the name, though. Just a year ago, Ken Schwaber rejected a request to change sprint to something else. He suggested not to “wordsmith”.

Interestingly, the Scrum Guide takes a stance on complementary practices. It mentions for example Burn Down Charts and Cumulative Flow Diagrams. Useful in reality, yes, but by no means more important than empiricism. We should base forward-looking decisions only on what has already happened. The new Scrum Guide makes this clear.

The Planning

In planning, the most significant change is that the question of “Why?” is considered as an independent topic in the planning of a Sprint. As a result of this step the Sprint Goal should be defined, the latest by the end of the Sprint Planning.

Another interesting change is an extra sentence about preparing the Planning Event. The Product Owner ensures that attendees are prepared for the topics in the planning. That is what the Guide now says. The participants should be able to discuss the most important Product Backlog Items. And of course how they map to the Product Goal.

The Daily Scrum

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
— Scrum Guide 2020

The goal of Daily Scrum — to assess progress towards the sprint goal and plan the work for the day — has not changed.

However, the Scrum Guide focuses on this purpose. There are no specific rules for its implementation. And yes — even the all too familiar three questions are gone. Finally, I would say. Those often contributed for the Daily crippling into a status meeting.

Will they ever get out of people’s head? We will see.

The Sprint Review

The essence of the Sprint Review remains what it was before. It is to examine the product and its progress towards the product goal. Well, the product goal is of course new at this point.

Apart from that, the Scrum Guide is now also pleasantly vague about the implementation. In essence, it says: this event is about collaboration with the stakeholders. Apart from that, it explicitly advises against turning it into a pure presentation.

The Sprint Retrospective

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
— Scrum Guide 2020

Of course, the Retrospective is about improving effectiveness.

The Scrum Guide is now more specific. In the Retro we will examine how the last sprint went in several dimensions:

  • Individuals and Interactions
  • Processes and Tools
  • The Definition of Done

Sounds familiar, doesn’t it?

Additionally, it advises to use the retrospective to challenge assumptions that proved wrong. To clarify their origin.

The objective of the retrospective is to identify changes. Those changes should improve the effectiveness of the team. The implementation should take place as soon as possible. But the guide no longer states that any of these changes should happen in the next Sprint.

A hint suggests that such changes can become part of the Sprint Backlog for the next Sprint. Many practitioners have been recommending this for years. It makes sense because it ensures visibility within the Sprint. That hint ennobles this practice to a sort of best practice.

Without calling it that way, of course.

The artifacts now help to clarify an often debated question. What does the team commit itself to?

When it came to implementing Scrum practices, this was a point of contention for many. Is it the entire Sprint Backlog? Does the team need to swallow everyhting they put on their plate? Or is the sprint goal the decisive factor?

The sprint goal is the crucial factor. That’s been the answer for a while now, even if not everyone wanted to admit it. The Definition of Done of course were important as well. In the new Scrum Guide this is now crystal clear. Apart from that, the product goal has been added as a commitment of the team.

By the way: The word “Commitment” has now been added to the headline of the respective points. In my opinion, a very elegant way to make it obvious what the team commits to.

Arguably, the new Scrum Guide puts even more emphasis on the “Why” instead of the “How”.

Of course many things stay as they were. Scrum is still about teamwork. It is still about deciding based on what we know. And Scrum is still about collaborating towards shared goals.

The authors of the Guide go the extra mile to make all this more clear. To bring out core concepts more strongly.

But with the product goal and the one-team approach, something new is there. Besides, the Scrum Guide is now easier to read and understand. They attempted to achieve that and I would say successfully.

Now the crucial question is: what will change in the real world?

Do you want to write for Serious Scrum or seriously discuss Scrum?

Source link