The most important changes and potential benefits of Scrum Guide 2020

After three years, we have another update of the Scrum Guide. In this text, I will try to refer to, in my opinion, the most important changes in the context of the potential benefits that these changes may cause.

Focus on the valuable elements of the product – LEAN

The previous definitions used in the Scrum Guide quite clearly specified what we use Scrum for. It was clear to all of us (and is) that by organizing work in Scrum Teams, we want to deliver the most valuable product (MVP), using the creativity and collective intelligence of the team. When thinking about Scrum many people combined the approach to building a product with the Lean approach’s features. As it turned out, it was a good lead. The new Scrum Guide officially introduces the Lean philosophy’s scope and clearly defines what the scrum team should focus on. The main principle is to focus on the key elements of the product discarding unnecessary elements as much as possible! Such an approach allows shortening the time to enter the market, and thus, through a faster feedback loop, test business hypotheses. At the same time, both the quality and functionality of the manufactured product are maintained. This approach to building a digital product works perfectly in the development of startups, which I have seen many times in Pragmatic Coders.

Empiricism as a response to the definition of unknowns

The second clear sign of the changes contained in the new Guide is the highlighting of the lack of knowledge that accompanies building a new product. The Scrum Team has the skills and experience needed to implement the project. Nevertheless, it is almost certain that there will be new challenges, technological barriers, etc. Therefore, the team should have the skills needed to build a new product and an attitude to expand their knowledge. For me, it is an important message, indicating a feature that every team member should have. Namely, openness to new challenges and willingness to adapt to the needs of achieving the goal.

Clearly define the relationship between the pillars of Scrum

The existence of an empirical process requires an iterative application of inspection and adaptation processes. As already described in previous versions of the Guide, they are based on Scrum’s three pillars (transparency, adaptation, and inspection).

In the latest version, the authors emphasized the strong relationship between these pillars. Omitting at least one of them in Scrum’s use leads to disturbances, as a result of which Scrum as a methodology/framework ceases to work effectively. Selective implementation of Scrum principles can lead to the opposite result than intended. Unfortunately, it usually involves high costs and a delay in delivering a valuable product. This is confirmed by my conversations with people working in Scrum Teams where this problem occurs.

Commitment and responsibility as a team value

Commitment and teamwork are inextricably linked with Scrum. The model with the development team was abandoned. Developers have never been a separate element of Scrum. However, calling developers a team created false expectations of its members towards each other. The entire Scrum Team is now at the heart of Scrum. Moreover, by increasing the team’s autonomy (self-management), its responsibility for the final result was also increased. I am convinced that the effect of introducing self-management will increase the possibilities of adapting the Scrum Team to dynamically changing business requirements.

A valuable product gain in every Sprint

Another successful change in the new Scrum Guide is to deliver value through an incremental approach. It was specified that the Scrum Team works iteratively to deliver a valuable and fully functional element of the product each Sprint. In my opinion, the emphasis here is on the word “each.” This approach forces the team to behave in a certain way. The result of this change will be the creation of backlog elements (taking into account the scope of work) that allow for the cyclical delivery of value.

Where are we going? – Product Goal

A Product Goal is a new Scrum Artifact which, contrary to appearances, contributes a lot to the process of planning and systematizing work. The long-term direction of the team’s activities becomes visible. It is clearly defined: scope of work, product boundaries, reach, potential users, etc. The specified goal introduces more stability in an agile project. Also, with the Product Goal in mind, the Scrum Team will be able to better manage the backlog. This will allow us to implement the Lean approach more effectively and find the most valuable and, at the same time, the fastest path to product creation.

Definition of Done, the rate of delivery of the increment

I like moving the definition of a “Definition of Done” (DoD) to the “Increment” section. The very definition of what the DoD is was clearly defined in previous versions of the Guide. Clarifying the significance of the DoD and tying this artifact firmly to the increment itself cuts off any discussion of what we call increment and when it materializes.

Summary

Assessing the new version of the Scrum Guide, I have to admit that the creators noticed the need for changes and responded to the current market requirements. The authors noticed problems in the interpretation of Scrum principles that teams face in their daily work. Clarifying the definitions of key elements, as well as the relationships between them, and shortening unnecessary descriptions, is in my opinion, a good attempt to solve these problems. In addition, the generalization of the descriptions of the rules and the departure from a language common in the IT industry encourage the recipients to use Scrum in other market sectors.
I am convinced that the new version of the Scrum Guide will result in a deeper understanding of the methodology and allow all teams using it to achieve even better results.