My top 10 changes to the Scrum Guide update 2020

Today there was a launch event, both celebrating 25 years of the Scrum Guide and also releasing an updated version of the Scrum Guide.

The Scrum Guide was last updated in 2017, so this was an anticipated update.

I attended the launch event and have also had some time to read the new Scrum Guide and reflect on the changes made.

In general, the update brings a less prescriptive and more streamlined version. Many ambiguous phrasings have been removed and some prescriptive practices, like Daily Scrum questions and the number of improvements from a Sprint Retrospective, have also been removed.

This is my take on the 10 most important updates to the Scrum Guide, how I feel about them and how I hope they will have a positive effect going forward.

1. Product Goal

The guide has had Sprint Goals previously, but now the Product Goal has been added. This brings focus to an overall larger goal which the team is working towards.

I think this addition is a good one. A lot of Scrum teams today work from sprint to sprint and neglect to work towards a larger goal. Though, I foresee that many organizations on agile journeys will struggle with this one. One singular goal for a team will be tough. It will definitely reveal some organizational impediments.

2. Not only applies to software

Some changes have been made to remove the reference to software development in the Scrum Guide. Though software development is where Scrum started, it has found application in many other industries. Industries that face similar complex challenges and environments as there are in software development.

I have seen Scrum work in many other settings than software development, so I think it is a great change. Scrum is applicable to so many industries other than software development. And maybe this can help remove the notion of “Scrum is something they do in IT”.

3. Self organizing → Self managing team

It might come across as a small change, but the difference between being a self-organising and a self-managing team is huge. Self-managing includes areas like HR, budgets etc.

It is going to be interesting to see how this plays out. I am looking very much forward to the conversations with organizational leaders about the premise of self-managing teams. Especially the ones who were already struggling with the notion of self-organizing teams :-)

4. Shipping increments — Review is not a gate

The new guide explicitly states that the Sprint Review is not a gate to release Increments. Talking even more to the empowerment of the team. There is no mentioning of an individual approving the increment, but more a notion of the team having responsibility for what they release. And that they can do so within the Sprint and not only at the end of the Sprint.

This underlines that the stakeholders are not a Go/No Go source for the team. Implementing it in some organizations will be tough though.

5. RIP Development Team

The Development Team has been removed as a term in the guide, there is now only the Scrum Team. The phrasing of Roles has also been removed. The guide now talks about accountabilities of the Product Owner, the Scrum Master and the Developers.

There has always been a lot of confusion about the Scrum Team /Development Team. Who is on what team, and are some on both teams? I think it is a great change. It also puts more emphasis on the accountabilities and less on the job titles.

Curious about Scrum and agile? Never miss a post!
Sign up for our newsletter (in Danish) right here 👉🏻 syndicate.dk/backstage

6. Artifacts and commitments

There is now a specific commitment to each of the three artifacts, very clearly sectioned below the description of each artifact. The commitments are very much focused on the goals of the different artifacts, thereby shifting focus away from tasks and onto the goals.

I really like the way this section is structured, it makes the statements clear and precise. I also like the emphasis on goals and not tasks, which a lot of Scrum Teams struggle with today.

7. Scrum Master — Causes removal of Impediments

There has been a small phrase change from “Removing impediments to the Development Team’s progress” to “Causing the removal of impediments to the Scrum Team’s progress”

It might be a small change in wording, but the meaning is quite significant. It takes the responsibility of impediment removal away from the Scrum Master and makes the Scrum Master an enabler of impediment removal. So, it could be anyone who removes the impediment, not just the Scrum Master.

8. Definition of Done got some love

Definition of Done is now a commitment to the Increment artefact. giving it more emphasis than in previous versions of the guide where it felt a bit like an attachment.

It is good that it has gotten some focus. It is often neglected by Scrum Teams. I like that it is now a commitment to the Increment.

9. No more servant leadership

The mentioning of the Scrum Master as a “Servant Leader” is now gone in favor of just “Leader” with the reasoning that: “Scrum Masters are true leaders who serve the Scrum Team and the larger organization”.

I am not quite sure how to feel about this one. I see Servant Leadership as an integral part of being a Scrum Master. I am afraid that it might be mistaken for traditional leadership styles. In my humble opinion, I think they should have kept the Servant Leader part.

10. Now mentions Lean

There has never before been a mentioning of Lean in the Scrum Guide.

I think it is both an attempt to bridge the gap to other industries, and it might also be because Dr. Jeff Sutherland has been working with Toyota lately :-)

No matter the reason, I think it is a good addition. Older versions did mention not allowing waste, so it might not be that big of a change. However, to me, Lean is a great part of Scrum and now has its rightful place in the Scrum Guide.

All in all, I think this update is great. For me, it brings a better structure to the guide and clarifies some of the issues there has been with the guide over the years. Also, the streamlining of the text and removal of redundant information makes it a lot more clear.

What are your thoughts? Which change do you think is the most important one? Let me know in the comments below.

You can find the updated Scrum Guide here.

‍

‍