Ken Schwaber

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:

1. Small, self-organizing, self-managing teams

2. Lean principles

3. 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 taking courses, going to 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, and what their skills would allow them to create and to work together to do their best.

In 2009, I recognized that 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 of poor communication, inadequate mentoring, or 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 it 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 Scrum’s identity as a framework and eschewed inclusion of opinions, context-dependent practices, and anything that constrained 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. Jeff Sutherland joined me to refine, sustain, and maintain it.

The Scrum Guide was created from Jeff’s and my work and the work of everyone else who had tried to use Scrum. We have adjusted it since then. The Scrum Guide has no commercial purpose other than to offer a litmus test of what Scrum is. Jeff and I 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’s perfect, because it never will be. Anyway, there are far too many complex, chaotic situations in our world that you’re skilled to help others address. We do not need to waste our time staring at our belly buttons.