AN UPDATE IS ON THE WAY
The Next Iteration of the Scrum Guide: What to expect?
Scrum, then and now, Episode 10
What can we expect from the next Scrum Guide?
The definition of Scrum is hosted at ScrumGuides.org. Since the publication of ‘the rules of the game’ in 2010, this definition has been updated roughly once every 18 months.
The last update was in November 2017, and it looks like another is on the way. What will be added? What will be removed? What will be changed? In this post, I look ahead and try to anticipate what we can expect.
Spoiler alert: No-one can know exactly what changes to expect, but we can at least anticipate the type of change based on our knowledge of Scrum and the people who came up with it. That’s the kind of prediction you’ll find below.
First, how do we know change is a-coming?
The definition of Scrum is influenced by suggestions from the community via a site called Scrum Guides User Voice. At this site, users can register their suggestions for additions, changes and removals from the Scrum Guide, and these changes are voted on by peers.
If suggestions gets enough oxygen on this site, they are reviewed by Schwaber or Sutherland, and considered for the next revision.
When I went to the UserVoice page recently, and saw the text in the blue box above, I realised a revision is properly on the way.
What can we expect? 3 things.
1. Specific practices will not be detailed, because Scrum is a framework (not a methodology)
If you are a Scrum Professional, and like to breathe oxygen, then you have probably pined on occasion for an instruction guide for product backlog refinement. This is almost 100% guaranteed to not be added to the Scrum Guide. Let me explain.
Scrum existed long before 2010, when the first Scrum Guide was published.
In its first formal incarnation in a 1998 paper by Ken Schwaber, it was described as a methodology, but things have moved on a lot since then.
“When Ken worked on the original paper on Scrum he was CEO of a Project Management Software company selling methodologies and that crept into the paper. As we rolled Scrum out across the world it became clear that Scrum was a framework […] It did not have the detailed practices in ‘methodologies’ and was a framework for adopting additional practices that worked in various enviroments.” (sic) (Jeff Sutherland)
Schwaber and Sutherland wanted to clarify this with the first publication of the Scrum Guide in 2010. In this guide, and ever since, Scrum is described as a framework.
The definition of Scrum was added to the first Scrum Guide revision in 2011, and remains unchanged to this date.
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. — (Scrum Guide, July 2011 — Current)
In defining Scrum as a framework, Schwaber and Sutherland wanted to encourage teams to use Scrum to experiment, and ‘surface the relative efficacy’ of practices that are needed in specific contexts.
Crucially, context-specific elements are not needed by others, and so will not be included in the rules of the game.
“I made sure that it retained its identify as a framework and eschewed inclusion of opinions, context-dependent practices, and anything that restrained it to only certain applications.” (Ken Schwaber)
2. Prescriptive wording will be reduced, because Scrum is based on empiricism
If you are expecting more help with estimation in the Scrum Guide, you might want to revisit your expectation. Scrum is anything but a ‘how to’ guide.
Fundamentally, the Guide is incomplete by design because Schwaber and Sutherland wanted to avoid being prescriptive.
“All organizations have issues adopting Scrum. They are shifting from a prescriptive, manufacturing based approach to an agile, empirical approach” (Ken Schwaber)
Empiricism is about learning by doing. In this respect, the rules of the game are less important than how you play.
“Making Scrum work is like trying to win playing football. It is not about the rules. It is about how you play the game.” (Jeff Sutherland)
The existence of Scrum itself could be summed up as a reaction to a limiting, prescriptive management culture. In a nutshell, empiricism means you experiment with changes to your process. Give something new a try! Retain the things that work, and consider anything else as potential waste.
“Every time you attempt to make Scrum more specific from what you learned, you make it less useful to the rest of us.” (Ken Schwaber)
3. Reduction is more likely than addition, because Scrum is based on Lean Principles
In a post that generated a lot of positive reaction, Serious Scrum’s Willem-Jan Ageling wrote about topics that were removed from the definition of Scrum. We should expect more changes like this. Let me explain why.
Scrum is strongly influenced by principles from Lean thinking: primary among these principles is the elimination of waste.
To illustrate what I mean, here’s a story.
There is an organisation out there named SCRUMstudy, who wrote a significantly longer, more prescriptive definition of Scrum. This organisation is unaffiliated with the creators of Scrum, and their ‘Body of Knowledge’ makes Scrum more like a prescriptive methodology than the framework it is intended to be.
In this terse tweet, Ken practices what he preaches. No need to be verbose 😀
Ken’s trademark brevity is also present in the Scrum Guide. It’s used by hundreds of thousands of teams, and it is less than 20 pages long. I believe he is making a point with the word count.
In future iterations of the Scrum Guide, it is more likely that elements will be removed than added. If anything is added, I believe it is more likely to be generalised or abstract elements, such as the ‘Uses of Scrum’ section that was added in 2017.
As Ken puts it (all caps intended):
“METHODOLOGISTS ALWAYS WANT TO ADD TO SCRUM. […] In doing so, they limit the applicability.” (Ken Schwaber)
Or as Jeff Sutherland puts it:
“Scrum derives from the Lean Product Development teams viewed by Takeuchi and Nonaka. […] management provided challenging goals and then backed off and let the team figure out what to do.” (Jeff Sutherland)
So, with Lean thinking in mind, when we anticipate future changes to the Scrum guide, we should expect brevity from Schwaber, and challenging goals from Sutherland.
The kind of changes to expect:
In summary, at this point, only Ken and Jeff really know what changes they are planning. However, we can anticipate the type of changes they will make:
- Changes will reduce prescriptive detail of practices, or detail that could be interpreted as prescriptive — don’t expect a guide to refinement
- Changes will encourage experimentation and remain context-agnostic — don’t expect software-specific elements like engineering practices
- Changes will encourage lean thinking: wording will be brief, and set challenging objectives for interpretation — don’t expect ‘low-hanging fruit’
When it comes down to it, we can expect the changes to the framework to embody the defining characteristics of Scrum itself :
* Lightweight
* Simple to understand
* Difficult to master
I hope you enjoyed this post: thanks for reading.
