Reflections on the Scrum Guide 2020 — Part 1: Purpose of the Scrum Guide
In a previous article I shared my thoughts on the two kinds of Scrum enthusiasts, and confessed that I used to belong to the Superficial Kind.
I used to have a superficial understanding of Scrum, “coach” teams to follow the rules to the letter and never bothered understanding the why behind each element. I was in a mental state in which Zombie Scrum (or pragmatic Scrum) was totally acceptable, yet I was doing a disservice to my teams!
However, I made a conscious decision to evolve to the Reflective Kind. Over the last few years, I have been on a personal journey to not only increase my self-awareness but explore and reflect at Scrum at a deeper level. Stay tuned as I explore the new Scrum Guide 2020 over a series of articles!
Some parts of the text in the Scrum Guide are more interesting than others, however, I will be reflecting on each paragraph irrespectively.
Right… now that we got that out of the way, let’s dive in and take a closer look at the new Scrum Guide’s introductory section.
Purpose of the Scrum Guide
The Purpose of the Scrum Guide section has changed massively, increasing from the mere three lines in the 2017 edition to four (4) paragraphs in the new 2020 edition.
Let’s break it down and discuss what has been added
We developed Scrum in the early 1990s. We wrote the first version of the Scrum Guide in 2010 to help people worldwide understand Scrum. We have evolved the Guide since then through small, functional updates. Together, we stand behind it.
We are now on the 6th iteration of the Scrum Guide with the first version released back in 2010. What I find extremely interesting is the fact that the Scrum framework was developed in the early 1990s and it took almost 20! years for the first version of the Scrum Guide to be developed. How did knowledge of the Scrum framework spread all these years before the Scrum Guide?
Since the release of the first version of the Scrum Guide, the Guide has indeed evolved with new versions been released in 2011, 2013, 2016, 2017 and the latest in 2020. You can get more information on the revisions here!
As far as the last sentence goes, I just love it!
Together, we stand behind it.
It is incredible that after so many years, Ken and Jeff are still committed to coming together to inspect and adapt the Scrum Guide, in their continuous effort to “help people worldwide understand Scrum”.
The Scrum Guide contains the definition of Scrum. Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum. Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.
This is quite an important paragraph, and I am pretty sure that many people will just skim over it or never bother to read, as they are anxiously scrolling to get to the important parts of Scrum in the Scrum Guide.
The message is super clear in this paragraph and if I can summarise the paragraph in one sentence, it would be as follows:
“You have adopted Scrum when you follow its rules and utilise all its elements as intended — else you are NOT doing Scrum.”
Simple as that… There are no optional elements, there is no flexing or bypassing the rules, there is no mix-and-match happy hour where you “are Agile” by choosing what works for you. Scrum is already a framework of the bare minimum elements, rules and values that will allow you and your team to develop, deliver, and sustain complex products; there is not need to trim it down further.
We follow the growing use of Scrum within an ever-growing complex world. We are humbled to see Scrum being adopted in many domains holding essentially complex work, beyond software product development where Scrum has its roots. As Scrum’s use spreads, developers, researchers, analysts, scientists, and other specialists do the work. We use the word “developers” in Scrum not to exclude, but to simplify. If you get value from Scrum, consider yourself included.
A couple of interesting points here for me. The first few sentences, without hiding any underlying, secret messages, simply highlight the fact that Scrum is growing in popularity and adoption — and it’s not limited to software development, but reaches any domains where complex work is performed.
And here is the first important change in the new Scrum Guide:
We use the word “developers” in Scrum not to exclude, but to simplify.
This sentence has two key points that I would like to highlight:
- All previous Scrum Guide referred to the Development Team. We have now moved to Developers, still referring to the same people that are “committed to creating any aspect of a usable Increment each Sprint”. As the Scrum Guide mentions, we are now using this term to simplify and not to exclude!
- The more subtle (hidden) point I’d like to highlight is the fact that through this change — Developers vs Development Team — the notion of a sub-team (a team within a team) has been eliminated. I have been in many conversations with fellow Scrum enthusiasts discussing the fact that a Development Team created a sub-team within the Scrum Team, and sometimes we would find ourselves into a rabbit hole discussing silos, specialties, etc. Luckily, in the new Scrum Guide, this has been clarified, so we can now move safely to more interesting debates about the Scrum framework.
As Scrum is being used, patterns, processes, and insights that fit the Scrum framework as described in this document, may be found, applied and devised. Their description is beyond the purpose of the Scrum Guide because they are context sensitive and differ widely between Scrum uses. Such tactics for using within the Scrum framework vary widely and are described elsewhere.
I really like the addition of this paragraph. It re-iterates the fact that
- Scrum should not be (and is not) used in a vacuum. As teams and organisations experience Scrum and find (in time) their balance, they will observe patterns and create processes that works best for them — obviously these won’t be described in the Scrum Guide.
- Scrum is a minimal framework that provide the necessary elements to help “teams and organisations generate value through adaptive solutions for complex problems”. The word “framework” is the keyword here, as Scrum should not work as a limiting factor but as an enabler. It will be applied in different situations and different contexts given the complex world it will be adopted within — again, we can’t expect these to be described in the Scrum Guide.
Having said that, I want to close by repeating a very very VERY important point here:
Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum… IT’S NOT Scrum!!!
So don’t use the excuse that “you are Agile” by choosing and picking Scrum elements that suit you and leave others that challenge you.
Next time we’ll be looking at the “Scrum Definition” section of the Scrum Guide, so stay tuned…
