Every few years Ken Schwaber and Jeff Sutherland, the authors of Scrum, get together to update the Scrum Framework as defined in the Scrum Guide. These are the official rules of Scrum and they have gone through many iterations.
Their latest version came out at the end of 2020, and it was simply called theScrum Guide 2020™. The goal was to simplify the framework and reduce unnecessary parts so that the framework can become more accessible to a wider audience. This is best seen in the reduction in size of the Scrum Guide (from 19 pages to 13).
They've also made several changes to the framework, and while some aren't that significant, I think some are worth considering.
Here I'll outline what I think are the top five changes, tell you why they matter (or not), and also give you my take on the changes. This is by no means a comprehensive list of changes. It's only the top 5 that I think is worth discussing.
Change 1: Responsibilities replace roles
CHANGE: The term “role” has been dropped in favor of the term “responsibilities” to label the individuals in a Scrum team.
IMPACT ON YOUR TEAM: For experienced teams, you can adopt or leave this change, as names and labels are more of an academic nature for you and your team. For new teams: you can decide to simply swap the words, or not.
BRIAN'S OPINION: Apparently some people thought the term "role" meant job title. The authors wanted to find a term more akin to a position on a sports team. For example, all players are baseball players, but each is responsible for a specific job: a catcher catches, a first baseman monitors events at first base. But of course your first baseman is also on the job every now and then, and similarly, each job title can then fill a specific Scrum team role without having to hire someone with that job title. Scrum Masters are not required to have “Scrum Master” on their resume; a project manager can play the role of Scrum Master as long as he adheres to what the Scrum Guide describes for that role. “Responsibilities” is thus an attempt to separate the two ideas: a role and a title are not the same.
However, the term “accountability” does not solve the problem. When most people (myself included) think of responsibilities, they think of responsibilities: "I'm responsible for putting my dishes in the dishwasher." The problem comes with the fact that I can be responsible for more than one thing, but the new Scrum Guide states that the Scrum team “consists of one Scrum Master, one product owner, and developers.” These terms represent an undefined word that includes multiple other responsibilities. For example, each developer is responsible for quality, makes a plan for the sprint and holds each other accountable. That missing word sounds very much like a role to me. If that's a problem for some, stick with the sports theme Scrum and call them positions. However you think about it, they are parts that people step into to play Scrum. “Accountability” just doesn't describe that in my opinion, and will only add to the confusion.
Change 2: No more development team
CHANGE: There is no longer a development team, only developers.
Scrum Guide authors Jeff and Ken stated that they had always hated having a "team within a team" by having a development team within the Scrum team. In this latest version, they fixed that by dropping the development team concept. The Scrum Team is now the only team in Scrum and consists of three responsibilities: Scrum Master, Product Owner, and Developers.
IMPACT ON YOUR TEAM: For veteran teams, this change is likely to be cosmetic only. And it harks back to the past; we once called them developers, not a developer team. But do understand that this language change is to emphasize the concept of “one team”.
For New Teams - Simply understand that now there is only the Scrum Team, which consists of three responsibilities: Product Owner, Scrum Master, and Developers.
BRIAN'S OPINION: While I understand the purpose of this change and agree that there is only one team in Scrum, I am a little concerned about the unintended consequences of this change. This is mainly due to the next aspect of the new Scrum Guide: the guidelines for developers. In previous versions, the rights and responsibilities of this group were explicitly set out. Now that's missing in the name of brevity. One sentence I find particularly saddening to see: “No one (not even the Scrum Master) tells the development team how to convert the Product Backlog into Increments of potentially releaseable functionality.” While some may consider this implicit and therefore unnecessary, I believe there are plenty of organizations out there that are not used to working this way and need this specific clue to tell them that theHowof building the product lies entirely with the developers.
So on the face of it, it should be a positive change. However, as practitioners, we need to help organizations understand that the intent of independence is still there, even if it is no longer explicitly stated.
As long as we're still tinkering with names, I'd rather update this to something like producers or makers. Developer is a software-focused term and deters many outside of software from using Scrum. I wish the new Scrum Guide had taken this opportunity to offer a word less related to the software world.
Change 3: No more servant leaders
CHANGE: The Scrum Guide has removed the term “Servant Leader” when describing Scrum Masters and replaced it with “true leader.”
IMPACT ON YOUR TEAM: For experienced teams - Probably no impact here, unless "true leader" has an alternative meaning that is not clear. For new teams: Since you have no history with this phrase, it probably won't affect you.
BRIAN'S OPINION: I think this change is the hardest to understand of the bunch. What is offensive about servant leadership as a term? And what the heck is a "true leader"?
I can only speculate about the reason for this change. Perhaps it is related to the movement in the tech world to drop the terms Master/Slave in relation to databases, as some people thought it could be considered a reference to slavery and therefore offensive. Whatever your opinion on this, I have also heard rumors in agile circles that we may need to reconsider the term Scrum Master and even Servant Leader for the same reasons.
Servant Leadership has nothing to do with slavery. Servant Leadership was a movement started by Robert Greenleaf in the 1970s that aimed to paint the image of a humble leader who serves those who want to be led. It is an incredibly powerful paradigm shift that has taken place in the business world – and the role of the Scrum Master has traditionally been associated with this term for good reason. I said above that I think "true leader" is a meaningless expression. There is no "true leaders" movement or philosophy. It sounds like someone wants to keep the meaning of servant leadership but replace the words with something similar. It would be a shame if the new term originated here; it would be based on misinformation and a lack of understanding of what servant leadership is.
I hope that the authors will reconsider, that they will re-examine the legacy and political correctness of the term "Servant Leader." I would like the term to appear in a future version of the Scrum Guide.
Change 4: Add commitments
CHANGE: Each artifact now has an accompanying “Commitment”: Product Goal for Product Backlog, Sprint Goal for Sprint Backlog, and Definition of Done for the Increment.
IMPACT ON YOUR TEAM: For experienced teams - This should not impact your team, provided you are already working with a Product Vision. For new teams - You hear less and less about a Product Vision and more about this Product Goal in Scrum. They generally seem to be synonymous.
BRIAN'S OPINION: This change is a bit trickier. Of these commitments, Sprint Goal and Definition of Done both existed in previous versions of the Scrum Guide, but not as an attached commitment to their artifacts. The Product Goal is the only new idea, at least when it comes to the Scrum Guide.
Most trainers and coaches have been teaching product owners for years about the benefits of having a product vision, which is the guiding force for the product. As Roman Pichler says, this is the "true north" of the product. Now let's see how the new version of the Scrum Guide refers to the Product Goal:
“The Product Goal describes the future state of the product, which can serve as a target for the Scrum Team to plan against.”
If you're having trouble seeing the difference between a product vision and this product goal, you're not alone. Why did the authors choose to ignore that the community was already using the term Product Vision and replace it with Product Goal? I can't think of any reason other than it fits Sprint Goal better. If there's an argument to be made for the differences between Product Vision and Product Purpose, I haven't heard it yet. So if you use Product Visions today and start calling them Product Goals, that might be all you need to do to get technically aligned with the new Scrum Guide.
There is one small detail of this addition as defined in the Scrum Guide that irks me. For both the Product Goal and the Sprint Goal, this new Scrum Guide says these items are IN their respective backlogs. If it wasn't described so explicitly, I wouldn't think about it. But how is this possible when you consider that the Product Backlog consists of everything known that is needed to produce the Product? The Sprint Backlog also contains everything known that is needed to realize the Product Increment of the sprint. In both cases, the backlog is a place where things need to be done: features, tasks, bugs, peaks, etc. So how is a goal INSIDE the backlog? Unless we redefine the backlog or create special new sections of the backlogs for targets, it doesn't seem logical for them to be IN the backlogs. I'll give the soapbox.
Change 5: Sprint planning three questions
CHANGE: The Sprint Planning has been expanded from two questions (WHAT and HOW) to three (WHY, WHAT and HOW).
IMPACT ON YOUR TEAM: Small, if any.
BRIAN'S OPINION: For years, the Sprint Planning event has aimed to answer two questions: WHAT are we going to do and HOW are we going to get there? In this latest version of the Scrum Guide, the authors have added the question at the top: “Why is this Sprint valuable?” They then explain that the Scrum team works together to create a Sprint Goal.
None of that is new.
As part of the WHAT discussion, teams have always had a Sprint Goal that the product owner represents and the entire Scrum team then works together to define it. If we're picky with words here, I'm not sure the sprint goal gives us the WHY for the sprint. It gives us the goal of the sprint, but not why that goal is important. In other words, the Scrum team doesn't need to justify their goal, they just need to define it.
I think this is an integral part of defining WHAT the team will work on. If your team needs three well-defined questions to determine the Sprint Goal, Product Backlog items, and tasks to create them, feel free.
Asking two or three questions probably won't make a difference to how Scrum teams run their sprints. I have yet to hear a valid explanation as to why this was explicitly mentioned in the new Scrum Guide.
A common theme for these changes
You probably noticed a theme here. Most of the changes in this new version will not have a substantial impact on how you run Scrum in your organization today. Of course you can change the terms you use or answer a question on a test slightly differently, but otherwise you don't have to change anything to comply with this latest version of Scrum.
The greater impact is in what has been removed. To make the Scrum Guide smaller, elements that some might consider essential have been removed. If organizations remember the 2017 Scrum Guide and don't change their methodology now, there may not be a problem. For new organizations adopting Scrum for the first time that do not have that history to rely on, there may be critical gaps in the framework that will not be filled in a manner consistent with Scrum's historical strengths. I hope these organizations will seek guidance to help with their lack of experience. If organizations learn from the Scrum Guide 2020 alone, we may not see the impact of these changes for several years.
For new teams, I suggest they read the 2017 version to better understand the 2020 version.
My advice for established teams? Keep doing what you're doing if it works for you. If not, inspect and adjust.