What's new? The Scrum Guide update 2020

The Scrum community and especially its two founders Sutherland and Schwaber update the main document, the Scrum Guide, every few years. After the last update in October 2017 it was time again this November. The goal of these updates is not so much to radically change Scrum and how it is done, but rather to find a better and more concise format to describe and explain Scrum.

The first thing you notice is the length - or better shortness - of the Scrum Guide: the English pdf version has shrunk from about 19 to a pleasant 13 pages. The language has also been improved: one has the impression that the guide is easier to read and less prescriptive. The big challenge for the authors is that Scrum is not only used in different contexts of software development, but has also gained popularity and now serves as a framework for any kind of knowledge work in complex spaces. With this comes the desire and necessity to avoid technical terms from the IT world as much as possible.

This becomes evident, among other things, that the “development team” has been removed from the guide. There is now only one team, the Scrum Team, consisting of Developers, Scrum Master and Product Owner. For the “Developer” as the executing role no alternative term has been included in the Guide. Many would have liked to have “team members” or something else.

Contrary to what we often hear and read, Scrum does not want to be a method but a framework. The corresponding method to the framework is empirical process control with the pillars Inspect, Adapt, and Transparency. New and valuable at this point is the reference to lean thinking and the paradigm of avoiding waste and activities that do not add value. This is an important pointer in the direction of “doing twice the work in half the time” (the title of a book by Sutherland, the founder of Scrum): speed is not an end in itself, but rather the targeted creation and delivery of value, for example by creating a clear focus.

An expression of this focus is also the newly introduced product goal, a mid- to long-term goal for the product, which is expressed in the product backlog. The product backlog is by no means a collection of ideas, but rather an outlook on the near future and the relevant issues, and is continuously adapted. The product goal can be used as an orientation especially for teams that see themselves misused as a pure feature factory (in the sense of purely working through topics with unclear benefits).

With the product goal an old acquaintance comes back into the Scrum Guide: the Commitment. Formerly misunderstood as an unalterable, binding commitment to create a work package and therefore replaced by the term “forecast” in the Guide. As it is now written: “In complex environments, what will happen is unknown.

The use of “Commitment” in the current version of the Scrum Guide is another one: based on empirical process control we as a Scrum team have to make sure that there is the highest possible transparency and focus for everyone in every step. To support this, a commitment to each of the Scrum artifacts was introduced:

• As mentioned above for the product backlog it is the product goal;
• For the sprint backlog it is the sprint goal;
• For the Increment it is the Definition of Done.

Speaking of increment: here too is an innovation. The Scrum Guide now knows multiple increments during the sprint, an adjustment necessary in times of continuous delivery: the practice that the complete work package is only published at the end of the sprint is hardly common anymore, at least in modern software development.

Sprint Planning has received a significant extension: three topics are now to be discussed. In addition to the usual “What can we do in the sprint” and “How do we get there”, we will now first consider why and how the sprint will become valuable. With this, the “start with why” (Simon Sinek) is also included in the guide. Teams are thus enabled to discuss and question the sense and nonsense of planned features.

The description of the Scrum roles has also become more nuanced. For example, the role term has been completely replaced by accountabilities (which in German is most likely to be translated as “Rechenschaftspflichten”). Thus, there is now a better description of the things and areas for which the Scrum team is accountable.

Two changes that are heavily discussed in the community are the description of the Scrum Master as ”… true leaders who serve the Scrum Team and the larger organization” (previously: “servant leaders”); and the description of the team as self-managed (previously: self-organized).

In the case of the “Servant Leaders” the criticism is that this concept has been introduced quite broadly and enough books have been written about it. Nevertheless, there seems to have been some confusion and Scrum Masters have often found themselves in a rather reactive role, more servant than leader. The new wording is intended to emphasize the pro-active part of the role.

Also the new self-managed has not only caused joy: self-organized teams or self-organization is a standing concept that is at the heart of agile approaches. Through the “self-managed” the authors do not want to declare the concept obsolete, but rather point out that the sphere of influence of teams is mainly related to the organization of their own work and working methods, less to those of the entire company. Of course this remains possible and is also handled in this way in many companies, but Scrum does not want to make any statements about this.

Like the previous versions of the Scrum Guide, the current changes (say increments) are only an attempt to make Scrum as a framework easier to understand. In the sense of “inspect and adapt” this edition is also only a temporary one and we can be curious how the changes will be accepted and interpreted.

The current version of the Scrum Guide can be found here: scrumguides.org. German version of this article on leanovate.de Blog.

Photo credit: Quino Al on Unsplash