Tug-of-war

Scrum gets updated from time to time. It changes when those two gentlemen with not-so-easy personalities happen to agree on something ;). I’m speaking of Jeff Sutherland and Ken Schwaber of course. Jeff wants Scrum Guide to fatten up with explanations, practices and stories, while Ken would most likely stay with the 1998 version. The result of these two standpoints is that changes in Scrum Guide are essential and on high level. I’m very grateful for this.
/> 

So… we don’t do Scrum anymore?

Many teams fear that after the Scrum Guide will be updated, they will fall out of the frames of Scrum. But — do you know any team having decent Scrum, that has ever become in conflict with Scrum after the Guide was updated? Yeah, me neither.
In reality, if we have that corporate quasi-scrum (I’m deliberately skipping the capital letter here), Scrum Guide changes create a stampede. But other teams don’t have anything to worry about.

And now … it’s … a subjective list of the most important changes in the new Scrum Guide.

#4 Retrospective elements in the Sprint Backlog

 

“To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.”

This creates a bit of controversy. Even though vast majority of teams I know do this for years, I know situations where mandating this instead of promoting it as a good practice will not help — some teams have their own and better ideas on how to solve it and they might get confused. I hope their Scrum Masters understand how it can be implemented. But before all — I’m really glad that it shows, that the Sprint Retrospective is a natural part of work and skipping it is not an option.

#4 Changes in the Daily Scrum

 

“The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal.”

 

“The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.”

Here I’m really happy that the Daily Scrum has been emphasised as an internal Development Team event. This is the most common Scrum mistake, made by beginner Scrum Masters and managers working with Development Teams.
This time it’s clear that it’s the Development Team itself that has to create their own way of conducting Daily Scrum and they are responsible for it.
What still hurts is that the dreaded three questions stayed. Luckily — only as an example.

#2 — Uses of Scrum

This question comes up on virtually every class on Scrum I conduct. “Where is Scrum applied outside IT?”. Now it’s the Scrum Guide itself that answers this question. But this is not the most important part here.

There we have this little gem:

“When the words “develop” and “development” are used in the Scrum Guide, they refer to complex work, such as those types identified above.”

YES! Finally. It explains that “to develop” in Scrum means “to create”, and not “to write code”. This goes along with the fact that Scum is widely used in non-IT parts of IT companies.

#1 — Changes in Definition of Done

 

“During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards.”

Tiny speck of a change. But what joy! Scrum itself shows us that Scrum Teams don’t operate in vacuum. Vast majority is a part of a larger organization and they have to operate in harmony with it. You can’t just say — we’re self-organizing, so we set up all the rules. No, that’s not how it works. The Development team isn’t a separate universe, but a part of a larger ecosystem.