19. Nov 2020
What the new Scrum Guide means for XITASO

The new version of the Scrum Guide was released on November 18th, 2020, and it contained substantial changes when compared with the previous adjustments. Baptiste Grand, agile coach, reports on what these changes are and how they have impacted the daily work routines at XITASO.

The new Scrum Guide 2020 includes the abolition of terms and the weakening of rigid specifications alongside the polishing and modernizing of some concepts and segments. The objective of these amendments is clear for me: fewer rigid specifications increase scope for a scrum team to experiment with its processes as well as providing more autonomy and freedom for “inspect and adapt”. It becomes more a question of the scrum team achieving a common goal. The new Scrum Guide simplifies a lot of complexity which originated from the software environment. Scrum 2020 is thereby more compatible for teams who do not come from the software development sector, like marketing, sales or hardware teams.

This article examines and discusses the main changes.

The Dev team is formally abolished

The abolition of the Dev team appears at first glance to be a fundamental change. And on the other hand, this change should have the least impact. In spite of this, it took time before I understood the intervention: why of all things would the development team, the heart and engine of Scrum be abolished? Why was this decision taken?
You will find some answers in the previous Scrum. I put many materials, my accumulated knowledge and my experience to the test, but in the end, a colleague I helped to become a professional scrum master gave me a decisive impulse:

Because everything about the Dev team or what can be said about the Dev team can just as well be said about the scrum team as a whole: self-organization characterizes both. Cross functionality as well. You can say the same thing about an increment that meets the definition of Done. If you look at the following quote, you can confidently replace the term “Dev team” with “Scrum team” without any change in the daily work.

“The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of ‘Done’ product at the end of each Sprint. [..] Only members of the Development Team create the Increment.”

So, if the term “Dev team” can be replaced by “Scrum team”, why do we need a special sub-team just for the development. Simply put, only one scrum team is necessary which is prototypically composed of developers, a product owner and a scrum master.

If, for this reason, the term “Dev team” simply disappears, we could live with that. But what are the concrete effects? For example, does anything change in the sprint backlog?

What does this mean for the sprint backlog?
To put it simply, until the update of the Scrum Guide, the Dev team was the owner of the sprint backlog, which could only be formally changed by the Dev team, in the same way that the product backlog falls under the responsibility of the product owner.

This demarcation was originally intended to serve the purpose of preventing disturbances. After all, planning should always be in the respective best hands, ensuring that the scrum team develop a “Done” increment at the end of the sprints.

Only what happens now with the sprint backlog? Who maintains the backlog if the Dev team has been abolished as owner? And if ownership falls within the remit of the scrum team as a whole, how do you deal with the potential risk of product owner or scrum master interfering in the sprint backlog to pursue their own interests?

At this juncture it is helpful to remember that Scrum gives more weight to individuals and their interactions than processes and tools.

“Individuals and interactions over processes and tools!”

Ultimately, communication was and remains one of the key criteria of a successful scrum team in preventing disruption.

The sprint goal becomes a scrum artifact

In my opinion, this change is a very good development. The ability of a scrum team to organize itself, plan and achieve its sprint goals is critical. A sprint goal creates focus and supports the decisions of what to do, or not to do, during a sprint.

The scrum team should therefore ask themselves whether they can achieve the sprint goal, every day? If not, what type of adjustments must be made to the plan? The scrum team should not be afraid to remove planned backlog items from their planned sprint if it serves the sprint target. For this reason, the topics concerning scrum planning have been adapted in the new Scrum Guide, the sprint goal has been upgraded to a scrum artifact, and the question has been added: Why is this sprint valuable?

The upgrading of the sprint goal to an artifact emphasizes strongly how important it is to deliver something valuable. Scrum teams are thereby compelled to clarify their own objectives. This helps the product owner to plan in the future or to consider what the next sprint goal could be. Or to visualize next year’s sprint goals.

The product goal becomes a new scrum artifact

The next achievement of the Scrum Guide 2020 is something completely new, namely a focus on the product goal. On the one hand, the introduction of more demanding product goals will help to create a product vision and develop effective sprint goals. On the other hand, I think there is a risk that many people will misapply these product goals to squeeze inappropriate project management techniques into the Scrum framework.

The idea behind the introduction of product goals is good in any case. It is about creating a superior hierarchy level in the product definition, features or milestones that the scrum team wants to achieve in the coming months, years or decades. Product goals are designed to help define sprint goals that lead to unambiguous product backlog items. With the help of product goals, you can plan, create a roadmap and make a product vision transparent. They focus you on the “WHY”.

Every day, a scrum team tries to agree on a (product) vision and not to choose the X top items from the backlog product, where X matches the team’s velocity.

What should instead be achieved is that the scrum team should carefully select the items to meet the current product goal. Specifically, teams use “epics” for example in tools such as JIRA, for example. However, “epics” were too often used to categorize different product backlog items there rather than recording them as large features to be developed.

The inclusion of product goals in the Scrum Guide 2020 should therefore help to clean up the product backlog and transform epics into clear and transparent product goals that the scrum team wants to achieve.

Scrum is scalable

Scrum was originally designed to be implemented by a scrum team. A scrum team with a product, a product owner, a scrum master, a Dev team, and an increment.

But as projects and tasks become increasingly complex, the need has arisen to scale scrums, to address more complex issues that one team alone cannot cope with. Nowadays, there are a variety of frameworks which access exactly this point and promise success, but work well, more or less, in practice. Compared with these frameworks, Scrum was never capable of dealing with these growing requirements, until Scrum 2020.

If scrum teams become too big, they should consider reorganizing into tighter scrum teams, each of which focuses on the same product. To enable this, they should have the same product goal, the same product backlog, and the same product owner.

The changes to the Scrum Guide 2020 provide clarity in this scenario. It is now perfectly in order for multiple scrum teams to work on the same product, as long as they pursue the same product goal, work on the same product backlog, and have the same product owner. How this affects the different Scrum Scaled Frameworks remains to be seen, but it will definitely be interesting. And Scrum is now finally scalable without having to resort to other frameworks.

Author & contact person

Do you have questions, ideas or feedback on this topic? Feel free to contact us!

Baptiste Grand
baptiste.grand@xitaso.com