Key Takeaways

• Over the years, the Scrum Guide started getting a bit too prescriptive. The 2020 version brings Scrum back to being a minimally sufficient framework by removing or softening prescriptive language.
• The 2020 Scrum Guide has placed an emphasis on eliminating redundant and complex statements as well as removing any remaining inference to IT work, and is now only 13 pages long.
• The 2020 version brings together everyone as one team, the Scrum Team, while previous versions had the Development Team within the Scrum Team.
• The three artifacts, Product Backlog, Sprint Backlog and Increment now contain ‘commitments’ to them. For the Product Backlog it is the Product Goal, the Sprint Backlog has the Sprint Goal, and the Increment has the Definition of Done.
• It is important for teams to remember that Scrum is still Scrum. Scrum is a framework. It describes the bare minimum to enable a team to work on complex work.

The Scrum Guide has been updated to make it less prescriptive, using simpler language to address a wider audience. These changes have been done to make Scrum a “lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems”.

The changes between 2017 and 2020 Scrum Guides are:

1. Even less prescriptive
2. One team, focused on one product
3. Introduction of product goal
4. A home for Sprint Goal, Definition of Done, and Product Goal
5. Self-managing over self-organizing
6. Three sprint planning topics
7. Overall simplification of language for a wider audience

InfoQ interviewed Ken Schwaber and Jeff Sutherland about the changes to the guide and why these changes were needed. We also explored some of the changes to the guide in more detail: commitment, one team, self-managing, product goal, and retrospective actions.

InfoQ: What are the main changes in the 2020 version of the Scrum Guide?

Ken Schwaber: In this version, we used fewer words rather than more words – more words complicate things. We’ve also tried not to entangle too many ideas – this causes confusion. When we did our first guide it was over 100 pages long, and it is now 13 pages long and anyone can use it, not just software developers. We’ve also made it less prescriptive; we removed things like the three questions in the Daily Scrum because it only helped the people who used them and confused others. We put a lot of effort into streamlining it to be very straightforward to use for everyone across industries.

Key changes include the sprint Goal and the Definition of Done now being artifacts, and we also added the Product Goal. Each of the three artifacts now contains “commitments” to them. For the Product Backlog, it is the Product Goal, the Sprint Backlog has the Sprint Goal, and the Increment has the Definition of Done.

Jeff Sutherland: The 2020 Scrum Guide is shorter, more focused, and has One Team. In addition to tying the three artifacts to goals with commitments, we addressed two of the biggest challenges in the industry: servant leaders who don’t lead, and self-organizing developers doing whatever they want and not meeting the commitments.

After wrestling for a long time with servant leadership, we finally just changed the word order. A Scrum master is a leader who serves. Professor Nonaku, who used the word Scrum in his 1986 paper in Harvard Business Review The New New Product Development Game, has consistently pointed out that the person who holds the accountabilities we give to the Scrum master is the catalyst for organization change by managing up and managing down. This requires leadership.

Self-organization is a concept from the Complex Systems Theory where an intelligent system self-organizes to achieve a goal. So we now use the term self-managing to try to avoid teams weaponizing self-organization as a tool to avoid any commitments. The team self-manages to deliver on its commitments to meet the goals.

InfoQ: Why were changes to the Scrum guide needed? What drove it?

Sutherland: In my view, the new guide addresses the biggest problems we find in Scrum implementation around the world:

1. Scrum is now used more outside of software, so the Guide needs to move beyond being software-specific.
2. We had a Scrum Team and a Development Team. This often created a situation where the product owner would not feel part of the team and criticize the team for not getting stories done, rather than being a team member helping the team to meet the sprint goal. Also, non-software teams did not like being called a Development Team.
3. A servant leader resulted in Scrum masters being good servants, but not leaders creating a situation where 58% of Agile teams could not deliver, according to Standish Group data on millions of projects. We hope presenting the Scrum master as a leader who serves will help.
4. Self-organization was widely misinterpreted to mean that agile developers do not have to meet commitments. We hope self-managing will create a more mature attitude towards meeting the needs of the organization.

Schwaber: As the world has changed and has gotten much more complex, the scope of that complexity has gotten bigger and bigger. This updated version of the Scrum Guide is aimed at bringing Scrum back to being a minimally sufficient framework by removing or softening prescriptive language. By simplifying the Scrum Guide, it ultimately makes it easier for people to use. We worked with many people within the community across multiple domains to get it to this point.

InfoQ: In the 2017 version of the Scrum guide, team commitment was removed. In the 2020 version commitment to the goal has been added. Can you elaborate why?

Schwaber: Commitment was removed because we often saw people and teams using it as a weapon, rather than as a guide.  Adding this back in for 2020 was done to provide a greater focus for the Scrum Team on those three areas (Product Goal, Sprint Goal, Definition of Done).

Sutherland: Early on we had teams commit to deliver the sprint backlog. Unfortunately, some managers weaponized team velocity. They criticized teams for delivering a point less or sometimes even for delivering a point more directly running counter to what Edward Demming taught the Japanese. Systems have variability and if you try to control normal variability, the system will spin out of control.

So to deliver the sprint backlog, we took commitment out of the Scrum Guide in 2017 and inserted a forecast with respect to estimates, and emphasized the Sprint Goal and commitment as a core value of Scrum.

In the 2020 Scrum Guide we have reinforced commitment by using it to tie the artifacts to the goals. I think this is simple, clearer, and a more logical way to frame issues.

InfoQ: The 2020 edition no longer mentions the development team, but talks about one team – the Scrum team. What does this change intend to deliver, and what do you hope that will happen in teams and organizations using Scrum?

Schwaber: The goal was to eliminate the concept of a separate team, the Development Team, and instead have one team focused on delivering value. The separate Development Team could create ‘us and them’ behavior between the product owner, the Scrum master and developers. By removing the Development Team, we have one Scrum Team focused on the same objective. The three accountabilities describe how they all work together to deliver on that objective.

Sutherland: All our Scrum teams at Scrum Inc have product owners and Scrum masters fully dedicated to the teams and helping the teams implement the backlog needed to achieve the Sprint Goal. We have found through repeated experiments that this works best. This is particularly important for teams outside of software – in operations, sales, marketing, support teams, legal teams, finance teams, etc. The 2020 Scrum Guide one team concept reflects this way of working.

InfoQ: Instead of being self-organized as was described in the 2017 edition, the Scrum team is now expected to be self-managing. What’s the difference, and why is it needed?

Sutherland: When we started working on updating the Scrum Guide, I thought self-organization was the most widely abused term in the industry because every company told me they had developers who were self-organizing to do whatever they wanted, and not helping the team to meet the Sprint Goal. I realized that a typical developer had no training in the Complex Adaptive System Theory, and did not understand the term. We hope that self-managing will help them act more like an intelligent system.

Schwaber: Previous Scrum Guides referred to Development Teams as self-organizing, choosing who and how to do work. With more of a focus on one team, the Scrum Team, we now emphasize a self-managing Scrum Team, choosing who, how, and what to work on.

InfoQ: What is the intention of the Product Goal? What does the concept look like?

Schwaber: The Product Goal provides context to the Product Backlog. It can be thought of as the ‘why’ the Product Backlog exists and why the Scrum Team is doing the work. A good Product Goal is something to strive for, and is measurable and visible to the Scrum Team and their stakeholders.

The Scrum Guide does not prescribe what the details of the Product Goal are, encouraging Scrum Teams to form the right goal for their situation. For example, some Scrum Teams may work towards a quarterly Product Goal that is very focused, while another Scrum Team might have a Product Goal that is very aspirational and less focused. What is important is that the product owner forms a Product Goal that provides clarity and context for the work and is easy for the Scrum Team and stakeholders to understand.

Sutherland: I was working with trainers in Europe and they said there was a major problem with product owners who had no vision about why they were giving the team a backlog. This is a significant demotivator to the team. When I discussed this with Ken, he felt the way to handle it was to make it more specific to the Product Backlog and the Goal of the Product Backlog, so that we could tie a commitment to it. I think this is a good solution to the problem.

InfoQ: In the 2017 edition, a change was introduced to ensure continuous improvement, with the expectation that there should be at least one high priority process improvement identified in the previous retrospective meeting in the product backlog. This addition has been removed in the 2020 edition, which mentions that “The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.” What made you decide to change this?

Sutherland: Ken wanted to make this less prescriptive so I agreed to move this teaching to the Scrum Patterns today which are essential to team performance. The pattern “Scrumming the Scrum” has one improvement from the Retrospective in every Sprint Backlog and that is essential to avoid teams failing. The Scrum Guide has the rules, but not the Play Book. I spent 10 years working on The Scrum Book: The Spirit of the Game so we would have a Play Book that was globally agreed upon.

Schwaber: Scrum encourages teams to improve. The Retrospective event provides them with time to look at how they are working and propose improvements. But by including a process improvement every Sprint, we force the Scrum Team to prioritize improvement over other forms of value. This might not be the right choice for the product owner working with the rest of the Scrum Team. We felt that this was too prescriptive. However, we continue to believe this is a great practice and suggest all Scrum Teams consider it; it just doesn’t need to be in the Scrum Guide.

InfoQ: What are your suggestions for teams to adapt to the 2020 edition of the Scrum Guide?

Sutherland: In my view, the essentials of Scrum have not changed over the years. We have updated the Scrum Guide to clarify issues and make it easier for teams in any country and any domain to understand. The 2020 Scrum Guide addresses several of the misinterpretations that have caused thousands of Scrum teams to fail to deliver an Increment at the end of a Sprint. Our hope is that we can help significantly improve the percentage of successful Scrum teams that deliver on their commitments – the Product Goal, the Sprint Goal, and the Definition of Done – at the end of a Sprint.

Schwaber: It is important for teams to remember that Scrum is still Scrum. Scrum is a framework. It describes the bare minimum to enable a team to work on complex work. You need to be flexible to inspect, adapt and evolve. The team still follows Scrum as defined in the Scrum Guide. They will of course move to the new version over time in some cases, however Scrum is still Scrum and that has not changed. Today thousands of teams use complementary practices with Scrum to adapt it to work for them.

InfoQ: What’s your advice to Scrum trainers and agile coaches based on the changes that have been made in the guide?

Schwaber: Read the Scrum Guide and use it to help your customers deal with the complexity they face. Scrum is still Scrum and the fundamentals have not changed. It is still a framework from which processes evolve based on empirical thinking of inspection and adaptation, and requires trust across the organization. Some additional items have been added and some areas where confusion may have been caused removed.  I suggest that you look at the Scrum Guide change history for some additional guidance on the changes.  I also suggest focusing on the fundamentals and introducing the new elements to your team.  Work with your team as a coach, mentor, trainer, etc. to help the team understand the impact on them, and how they work.  As a trainer or coach, it is your role to help the team understand the application of Scrum and help them to work together on how the team organizes to deliver value.

Over 25 years ago Jeff and I started using Scrum to help us deliver software products. We are as surprised as anyone how successful it is, but we hope that you can use Scrum to make the world a better place.

Sutherland: I have been working with our Scrum trainers and Agile coaches on updating our training materials. There have been small changes in the presentation of Scrum in the product owner and Scrum master classes to reflect the current emphasis in the Scrum Guide on leaders who serve, self-managing teams, and the three commitments tied to the artifacts. The commitment to achieve the Product Goal, the Sprint Goal, and the Definition of Done for the Increment will have increased emphasis. We hope this will help people to more easily implement good Scrum practices in the beginning and avoid having to fix so many things later. That said, the Agile journey is ongoing and improvement is continuous. It never stops, so we have not heard the last word on the Scrum Guide.

Fuente: https://www.infoq.com/articles/changes-2020-Scrum-guide/