Ever since the November 2020 version was released, I had been curious about the what's and why's of the changes that were made to the July 2017 version. Whether we choose to drop the term "servant-leader" (to describe a Scrum Master) from our vocabulary is altogether a different (and contentious) conversation. For now, let us quickly take a look at the noticeable changes.
Development Team v/s Developers
The 2020 update does away with the concept of Development Team, which had the connotation of a team within the Scrum Team. Henceforth, we would be using the term Developers.
The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies.
Self-organizing v/s Self-managing
The Scrum Guide now uses the terms “self-managing” and “self-management” to emphasize that Scrum Teams choose “who, how and what to work on”. The 2017 version used the terms “self-organizing” and “self-organization” to describe that Development Teams chose “who and how to do work”. In both cases however, it was evident that the Scrum Team does not operate as directed by those outside the team.
Servant-leader v/s True Leader
The term servant-leader was removed, and Scrum Masters are now described as “true leaders who serve the Scrum Team and the larger organization” The Scrum Master is accountable for the Scrum Team’s effectiveness.
Though it has been almost six-months since the release of the 2020 update, the term "servant-leader" is still very much in use in all the conversations taking place within the Agile community.
The Sprint Planning ceremony now attempts to answer the following questions:
- Why is this Sprint valuable?
- What can be Done this Sprint?
- How will the chosen work get done?
The question "why is the Sprint valuable?" was added to draw more focus on the commitment that is "Sprint Goal". So, this change echoes the newly introduced concepts of Commitments.
As a stance, the Scrum Guide November 2020 version is less prescriptive and no longer lists the set of three questions like the older version. The purpose of the ceremony is clearly stated, but the structure and technique is left open-ended to the interpretations of the Developers.
Earlier, it was suggested that by the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. But now, though the Scrum Team identifies the most helpful changes to improve its effectiveness their addition to the upcoming Sprint Backlog is optional.
Accountabilities v/s Roles
The current update of the Scrum Guide is sprinkled with a generous dose of the terms "accountable" and "responsible". One of the most frequently used term "roles" has now been replaced by "accountabilities".
The Scrum Guide November 2020 version clearly outlines the commitment for each artifact.
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.
In the 2017 version of the Scrum Guide "vision" is only mentioned once in the context of the Increment.
The increment is a step toward a vision or goal.
An ode to the importance of Product Goal, the 2020 version goes on to emphasize
The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.
Definition of Done
As consequence of removing the idea of Development Teams from the Scrum Guide, the responsibility to create the Definition of Done now falls upon the Scrum Team. Earlier, it was the created by the Development Teams if there wasn't one defined by the development organizations.
In stance of being less prescriptive, the Scrum Guide 2020 update simply suggests a team size of 10 or fewer people.