Scrum is a mindset, an approach to turning complex, chaotic problems into something that can be used. Jeff Sutherland and I based it on these pillars:
- Small, self-organizing, self-managing teams;
- Lean principles; and,
- Empiricism, using frequent inspection and adaptation to guide the work of the teams to the most successful outcome possible.
The Scrum Guide is a body of knowledge that explicitly defines what Scrum is (and, by default, what it isn’t). The Scrum Guide doesn’t tell you how to use Scrum, how to implement Scrum, or how to build products with Scrum.
People learned what Scrum was and how to use it by going to courses, conferences, reading books and blogs, etc. but primarily by trying to create useful things from visions, concepts, and desires using their understanding of Scrum. As they went at it, Scrum started to make sense. Scrum helped them manage outcomes, But… When people tried to use Scrum, they learned that the difficulty of Scrum was getting a shared understanding of what was desired, what was possible, what their skills would allow them to create, and to work together to do their best.
In 2009, I recognized we had broken the waterfall mold. People understood – largely – that our “agile, lightweight” approach worked and was appropriate for the emerging complexity in the world. However, just like the telephone-tag game, there were many interpretations of Scrum… Sometimes this was because poor communications, inadequate mentoring, and other commercial reasons. People who felt that Scrum would tell them how to build a product to solve their needs felt that Scrum was weak because Scrum didn’t explicitly tell them how.
Exactly. As I’ve often said, Scrum is easy. Solving problems with Scrum is very hard.
So …. In 2009, when I founded Scrum.org I wrote a definition of Scrum. This was short, but retained all of Jeff’s and my important thinking and learnings. 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. A framework, not a methodology.
This was the first Scrum Guide, and it was the definitive body of knowledge. Anything not in the Guide, or contrary to the guide was not Scrum.
I created some assessments that helped people test their understanding of Scrum anonymously and for free. The initial results were scores below 40 percent correct. As people went back to the Scrum Guide and studied, these scores rapidly improved.
I wrote the Scrum Guide, and Jeff Sutherland then joined me to refine, sustain, and maintain it, so that:
- Courses could be developed based on what Scrum was, not something else.
- People who taught courses would have a solid foundation to stand on.
- We could develop assessments to test whether a person knew Scrum and how to use it to solve their problems.
- Anyone could evaluate their understanding of Scrum and whether what they had been taught or told conformed.
etc.
The Scrum Guide was created from Jeff’s and my work, and the work of everyone else that had tried to use Scrum. It has been adjusted by us since then. The Scrum Guide has no commercial purpose other than to offer a litmus test of what Scrum is.
Jeff and I maintain the Scrum Guide at https://www.scrumguides.org . We are indebted to the people who have translated the Guide and to those who help us sustain it.
REMEMBER: Scrum is simple. Stop worrying about polishing it up so it is perfect, because it never will be. Anyway, there are far too many complex, chaotic situations in our world that you are skilled to help others address. We do not need to waste our time staring at our belly-buttons.