What Changed in Scrum? Scrum Guide 2020 – 5 Noteworthy Points

The new Scrum Guide – Scrum Guide 2020 – is on the streets, and available in several languages. And what does that mean for you? It depends on three factors:

• • Do you really use Scrum?
  • How adherent are you to the framework?
  • Do your teams have a hard time dealing with Scrum concepts?

The answers to these questions determine how much this new version of the guide can influence what you and your team do. On the day of the release the authors, other officials and several experts made some lives about the new version. We participated in some of them to gather different views and opinions on the subject. We will talk about the main changes and at the end discuss a little what happened.

The New Guide

The guide itself has shrunk. It went from more than 20 pages to 16. In addition, it was launched with the purpose of democratizing Scrum, that is, the main line of its launch was its reduction and some adjustments that were made to allow the guide to be used by others. activities other than software development. In other words, the main idea of ​​reducing the size, which also manifested itself in other aspects, is to make the guide less prescriptive, focusing more on its agile essence. A clear example of this is the case of the Daily Meeting. In its new version, the 3 basic questions of this meeting disappear – what I did yesterday, what I will do today and obstacles encountered – to focus on its essence as a meeting of micro-planning of activities.

Likewise, the authors believe that the changes now introduced make the guide more comprehensive, in the sense of contemplating areas other than IT, since Scrum is now widely used in activities other than software development.

The following changes made are noteworthy.

Team

We now have only one team: the Scrum Team. Previously the Team was defined by a PO, an SM and the Dev Team (or team of developers). In its new version, the Dev Team gives way to “Devs” (developers). Thus, a Scrum Team was formed by PO, SM and Devs. Time now exists only one. An attempt to lower internal barriers and increase group commitment.

Roles and Accountabilities

Following the same tune, the Roles that were already defined by Responsibilities  now boil down to Accountabilities. In Portuguese, both terms would be defined as responsibilities. However, according to the authors, the term Role was removed because it was being used incorrectly as a position in many organizations. In a way it seems to me that flexibility was sought again. By removing the Roles and defining accountabilities for team members, there was also the possibility of having other accountabilities associated with Team members, in addition to those defined in the guide. However, the Team continues to be formed by a PO, an SM and Devs.

Product Goal

In order to avoid that the Team is simply a manufacturer of features, running Sprints with the objective of performing as much work as possible, eventually losing the perspective of real value for the customer, the guide now introduces the concept of Product Goal. The Product Goal serves to keep the team oriented to what the customer really wants – Focus.

At the same time, this also allows the creation of good Definitions of Completed – DOD (Definition of Done) – used to evaluate the product increment, since they must always be created with a view to achieving the Product Goal.

The guide now makes it clear that for each of the following artifacts there is an associated orientation: Product Backlog oriented towards the Product Goal; Sprint Backlog oriented towards Sprint’s Goal; and Increment oriented to the Definition of Completed. If you use Scrumhalf, there is already room for everything: Product Goal in the project description, Sprint Goal in the Sprint description, and DOD in your project settings.

Still on the same path, that of providing transparency and generating focus, the guide starts to include in the planning of a Sprint, in addition to the usual questions of what to do and how to do it, the need to show why why to do it. This demonstrates Scrum’s commitment to promoting the alignment of the entire Team in one direction.

Self-management

In its earlier versions the guide stated that the team, or the Devs, were self-organizing. This time, the guide starts to define the team as self-managed, in a way establishing that the team itself can define who will perform each of the tasks. It may pass only as a rewrite, but it may have other consequences. Let’s see how this change will impact, if any.

Our Impression

It is certainly commendable to reduce the size of the guide, as well as the intention to make it less prescriptive. The changes in general are simple and effective, even if in a way they are just a new guise for existing practices, as in the case of the change from self-organized to self-managed.

The big disappointment, however, was due to the scope of the guide, especially with regard to the language used. During its launch, we had the opportunity to ask, for example, “why did the guide insist on Devs, if that is an exaggerated IT term”. The answer came well below what was expected. The panelists claim that several Teams from different areas were consulted and that the professionals considered themselves Devs, that is, developers, because they develop some type of product or service. Honestly, it didn’t convince me. Agilists who work with non-software development teams always find it difficult to use different terms than what is defined in Scrum, in order to better adapt the framework to the reality of their areas. A real change in this direction would be very welcome.

Finally, considering the current market and the organization of work in Scrum itself, the effect of removing roles, replacing them with accountabilities only, will have little practical effect, in our opinion. However, at the end, this will at least provide a topic for heated debates, as we already can see on social networks. Just to have an idea, take a look at this definitions.

I hope that user feedback will influence an upcoming version of the guide, making it really more suitable for other professional areas.

Have you read the new guide? What do you think?