Introduction

I offer you Scrum, a most perplexing and paradoxical process for managing complex projects. On one hand, Scrum is disarmingly simple. The process, its practices, its artifacts, and its rules are few, straightforward, and easy to learn. In 2001, Mike Beedle and I wrote a short, straightforward book describing Scrum: Agile Software Development with Scrum (Prentice Hall). On the other hand, Scrum’s simplicity can be deceptive. Scrum is not a prescriptive process; it doesn’t describe what to do in every circumstance. Scrum is used for complex work in which it is impossible to predict everything that will occur. Accordingly, Scrum simply offers a framework and set of practices that keep everything visible. This allows Scrum’s practitioners to know exactly what’s going on and to make on-the-spot adjustments to keep the project moving toward the desired goals.

Common sense is a combination of experience, training, humility, wit, and intelligence. People employing Scrum apply common sense every time they find the work is veering off the path leading to the desired results. Yet most of us are so used to using prescriptive processes—those that say “do this, then do that, and then do this”—that we have learned to disregard our common sense and instead await instructions.

I wrote this book to help people understand how to use Scrum as they work on complex problems. Instead of further describing the framework and practices of Scrum, I offer a number of case studies in which people use Scrum to solve complex problems and perform complex work. In some of these case studies, people use Scrum correctly and the project in question ends up achieving their goals. In other case studies, people struggle with Scrum and their projects are less successful. These are people to whom Scrum is not intuitive. I’ve worked to understand how this can be possible. After all, Scrum is a very simple process for managing complex projects. Compared to many traditional approaches to project management, Scrum is almost effortless. Or at least I used to think it was.

Most people responsible for managing projects have been taught a deterministic approach to project management that uses detailed plans, Gantt charts, and work schedules. Scrum is the exact opposite. Unlike these tools, which practically fight against a project’s natural momentum, Scrum shows management how to guide a project along its optimal course, which unfolds as the project proceeds. I’ve heard that traveling along a learning curve starts from a point where you have to think everything through step by step and ends at a point where you can perform the work in question unconsciously. This is particularly true of Scrum because those steeped in traditional management practices have to unlearn many of them.

I recently helped a software development company adopt Scrum. Initially, the company had planned for two releases over the next 12 months. Because of its success in using Scrum, however, most of the functionality from the two releases was ready within 5 months. But when I visited the engineering organization, the staff was working weekends and nights to put even more functionality into the release. Even though the engineers had been wildly successful, marketing still was berating them for not delivering enough and living up to “commitments.” The engineers were feeling guilty for not doing everything that marketing said was necessary, and they were ruining their personal lives to try to do everything marketing requested. This pathology had persisted despite the fact that the engineers had already accomplished the work involved in two releases in the time usually allotted for one. Old habits die hard.

Another change that Scrum engenders can best be described by thinking of how a house is built. The buyer of the house cannot move into the house until the entire house is completed. Suppose that there were an incremental, iterative approach for home construction. Suppose that using this approach, houses were built room by room. The plumbing, electrical, and infrastructure would be built in the first room and then extended to each room as it was constructed. Buyers could move in as soon as they had decided that enough rooms had been completed. Then additional rooms could be constructed depending on the needs of the buyer. Scrum lets buyers have software built in this fashion. While the infrastructure is deployed, pieces of functionality are delivered to buyers so that their organizations can start using parts of the system early in the development cycle. As the system is experienced, the buyer can determine which parts of the system will be constructed in what order and use these parts as they are completed. Buyers might even choose not to have the entire system built if they are satisfied with only a subset of the total functionality they’d initially envisioned.

I used to teach people the theory, practices, and rules of Scrum. Now I teach them what Scrum feels like as it is implemented. I teach them how to recognize when things are going right and when they are going wrong. I provide exercises and discussions that let them experience the epiphanies so that they know what Scrum should feel like. Just as you don’t really know what it’s like to be someone else until you’ve walked however many miles in his or her shoes, you might not fully understand Scrum until you implement it yourself. But as you read this book, you will begin to understand what Scrum feels like and how you might feel using Scrum in your organization.

How should you read this book, which is in essence a book of case studies about Scrum? I’ve provided some of the background for each story, described how Scrum was used in that situation, and presented some of the lessons that can be learned from the way Scrum was used. The case studies are organized into topical chapters, through which you should feel free to browse. The chapter topics are Chapter 1, “Backdrop: The Science of Scrum; Chapter 2, “New Management Responsibilities”; Chapter 3, “The ScrumMaster”; Chapter 4, “Bringing Order from Chaos”; Chapter 5, “The Product Owner”; Chapter 6, “Planning a Scrum Project”; Chapter 7, “Project Reporting”; Chapter 8, “The Team”; and Chapter 9, “Scaling Projects Using Scrum.” Sometimes I indicate that the background for a story has been provided in a previous chapter.

Appendix A, “Rules,” lists the rules that are used in various Scrum practices and meetings. These rules hold Scrum together. If you are familiar with Scrum but you come across terms that you do not fully understand, you should look them up in Appendix B, “Definitions.” If you are unfamiliar with Scrum, you should read Chapter 1, “Backdrop: The Science of Scrum,” for a recap of Scrum theory, flow, practices, artifacts, roles, and meetings. Appendix C, “Resources,” provides a list of resources that you might want to access to get a deeper understanding of Scrum.

Appendix D, “Fixed-Price, Fixed-Date Contracts,” and Appendix E, “Capability Maturity Model,” are the odd ducks of this book. They contain material that might help you use Scrum in rather unique circumstances that aren’t described in the case studies that constitute the body of this book.