5 changes in the 2020 Scrum Guide you should know about
November 18th, 2020, was probably one of the most exciting days on many fellow Scrum enthusiasts' agenda. In addition to celebrating the 25th anniversary of Scrum, the long-awaited new update of the Scrum guide saw the light of day. Lo and behold - it's a major update or not?
Here's what you need to know about Scum's latest update.
Less is more
A bigger target to aim for
One team, one focus, three accountabilities
The Scrum Master is a true leader – not a secretary
1. Less is more
Ken Schwaber and Jeff Sutherland, aka the Scrum creators, always wanted Scrum to be a container in which teams could inject their techniques and tools. But in the previous versions of the Scrum guide, some bits and pieces were considered too prescriptive.
Some examples (but you can find other examples in the guide):
In the 2017 guide, a set of questions was given to help teams structure the Daily Scrum meeting. These three mythical questions are "What did I do yesterday that helped the Development Team; What will I do today to help the Development Team. And do I see any impediment that prevents the Development Team or me from meeting the Sprint Goal?"
These questions were given as examples, but many product teams used them without assessing if they worked for them as a team. You won't find these questions in the 2020 guide. It's now up to the developers to find the best way to organize this daily meeting, as long as it focuses on reaching the Sprint goal. I know, I know – it was always intended to be up to the team to decide how to structure the events, but many teams got lazy and implemented what was written in the Scrum guide.
The 2017 guide also prescribed that no more than 10% of a team's capacity should be spent on product backlog refinement. These numbers are very context-dependent and, therefore, challenging to implement. For the same reasons, the steps to be taken in case of sprint cancellation and the scrum events’ proposed structure were drastically reduced.
Scrum was already a lightweight framework, but now it's even lighter. In this way, a minimal viable framework remained that is a bit more complex (read: more generic), but on the other hand, more universally applicable (read: easier to use beyond IT-project and teams)
2. A bigger target to aim for: the product goal
This second change is my favorite one. The 2020 Scum guide introduces a larger goal that transcends multiple sprints and sprint goals: the Product Goal. The product goal is what all your Sprints should add up to. It answers the question of why we are building this product.
We are not running Sprints just for fun. Are we? The bigger goal is to ultimately deliver our product that solves the complex problem for our stakeholders. This was often called the product vision, but it was supposed to live outside Scrum. Not anymore. The product goal is now a formalized part of Scrum. It'll be interesting to see how teams will incorporate the product goal into their daily work.
This also paves the way for another change: each of the three Scrum artifacts now contains a 'commitment'. The Product Goal is the commitment for the Product Backlog, the Sprint Goal is the commitment for the Sprint Backlog, the Definition of Done is the commitment for each increment.
These commitments bring more transparency and give a clear purpose of dedication to each of the Scrum artifacts.
3. One team, one focus, three accountabilities
The 2020 update emphasizes that the Scrum Team is one team that focuses on one objective at a time, the Product Goal. That's why the term 'Development Team' got replaced with 'Developers'. The "Development team" label gave the impression of a team within a team, which often led to a tense relationship between Developers and Product Owners. No more two teams – one team to rule them all.
Moreover, Scrum Master, Product Owner, and Developers are not just 'roles' anymore. The new update focuses on what matters: not roles and titles but accountabilities. When someone is accountable, they must take care that it happens and is ultimately "accountable" for the result. That's why Scrum now talks about three accountabilities.
4. Self-managing > self-organizing
Yes, in all Scrum versions, autonomous Scrum teams play a vital role. A Scrum team is self-organizing and cross-functional. Wow – that's cool, but what does it mean? That's the problem with self-organizing: there are too many different interpretations. Additionally, many organizations put managers above the Scrum team to "manage" the Team, which puts a lot of restrictions on the Team's autonomy.
No more managers – Scrum needs self-managing teams.
Self-managing goes a few steps further than self-organizing. The Scrum team decides who does what, when, and how. This makes perfect sense! The Scrum Team does all the work and is committed to reaching the Product Goal. They should manage the work.
Yes, you're right – Scrum Teams were always supposed (stress on supposed) to be self-managing, so this doesn't make a difference. Replacing self-organizing with the term self-managing is more of a rectification than a change – but it stresses the importance of autonomy.
5. The Scrum Master is a true leader – not a secretary
In previous versions, the Scrum Master was described as a servant leader, which evoked the idea of someone who is not really contributing to the Product Goal. The "servant" part was often misinterpreted as someone who is the secretary of the team.
Of course, a Scrum Master has a much more fundamental role. Besides being accountable for improving the team's effectiveness and performance according to the Scrum principles, the new update also emphasizes that the Scrum Master serves the whole organization in leading, training, and coaching in Scrum adoption. That's not doing nothing!
That's why the term servant leader got replaced with the term 'a true leader who serves'. Sounds better, don't you think so?
Scrum hasn't changed at all—we're just getting the description better". Jeff Sutherland said that during the presentation of the new version of the guide, I think it holds one of the key takeaways. The core of Scrum is stable – now up to us to use it correctly.
These were briefly the most important changes in the new update. Interested in more? Check this article.