Scrum Is Simple
Just Use It As Is
Editor’s Note: Ken Schwaber is the co-developer of the Scrum process, and one of the dozens of expert practitioners who shared wisdom learned from his years of dealing with specific problems and challenges with Scrum. In this excerpt from 97 Things Every Scrum Practitioner Should Know, Ken provides an in-depth look into the evolution of Scrum. We’d love to hear from you about what you think about this piece.
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
- 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.
Learn faster. Dig deeper. See farther.
Join the O’Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.
Ken Schwaber is a veteran of the software development industry. He co-developed the Scrum process with Jeff Sutherland in the early 1990s to help organizations struggling with complex development projects. One of the signatories to the Agile Manifesto in 2001, he subsequently founded the Agile Alliance and Scrum Alliance. He left the Scrum Alliance to found Scrum.org in 2009. Ken has written several books about Scrum.
