Chapter
1
A Brief Introduction to Scrum
Have you read The Scrum Guide™?
It seems like a silly question. Ryan recently asked an experienced Scrum Team this question. How could a two-year-old team not have read The Scrum Guide? It’s only about 20 pages long, after all. Well, out of a team of nine, only five hands went up.
We’ve performed this experiment many times and have yet to see every hand go up. We encourage you to ask your team this question. It gives you a chance to learn how well your team understands Scrum, and you’ll likely get some good ideas for future coaching sessions. It’s also a great opportunity to have your team read The Scrum Guide together and discuss it.
Please read The Scrum Guide.[2] It’s the universally agreed-upon definition of Scrum, and is maintained by the co-creators of Scrum—Ken Schwaber and Jeff Sutherland—who update it occasionally. Admittedly, The Scrum Guide is dense. We read it regularly and often debate about our different interpretations of the nuances. There are many benefits to having you and your team read and have those same debates.
Just remember that Scrum isn’t a panacea. Scrum exposes all of the existing problems in an organization by making them transparent. It may bring to light problems that you didn’t even know existed. There are deliberate inspection points in the Scrum events that provide opportunities to harness the brainpower of your organization to solve these problems, adapt to the changing conditions you face, and create transparency every step of the way. Scrum won’t magically fix the issues it uncovers, but it does provide tools and techniques that—if applied well—can lead to success. Our goal with this book is to help ensure that you’re able to use Scrum effectively in your organization.
Scrum is a powerful framework built for the complex domain of work such as software development, which is what we focus on in this book. To learn more about complex domains of work, we highly recommend that you familiarize yourself with the Cynefin Framework[3] or the Stacey Matrix.[4] They’re both great ways to understand the various domains of work and can be fantastic resources for helping convince others in your organization to embrace empiricism (in other words, to be guided by experience) rather than crave certainty. Empiricism is at the core of Scrum. Every Scrum event is an opportunity to check your work and make new decisions as you learn more about the product you’re creating. Initially, changing direction based on experience (empiricism) may be difficult to get people to buy into, but positive results will help you win them over.
Without further ado, here’s our attempt at the world’s shortest explanation of the Scrum framework. (We’ll provide lots more details about these various elements throughout the following chapters.)
We get this question a lot in our Scrum training classes.
A framework is a supporting structure. Scrum defines roles, events, and artifacts (more on these in a sec) but is largely silent on exactly how you should go about performing the roles and facilitating the events. A methodology, on the other hand, provides a checklist of actions to complete before moving on to the next phase or step of a process.
Because Scrum is a framework and not a methodology, it forces Scrum teams to make their own decisions within the Scrum structure. The upside is that Scrum provides an environment where you have the flexibility to find creative ways to solve complex problems and deliver great products.