Scrum: The Art of Doing Twice the Work in Half the Time
by Jeff Sutherland, Crown Business, 2014
What can software developers teach business executives about how to get work done? A lot, says Jeff Sutherland, author of Scrum. And even though the breathy promise of the book’s subtitle makes it sound like a self-improvement book, Sutherland backs up his claim with a 20-year-old methodology for streamlining software creation that executives frustrated with the slow pace of any kind of project should find worthy of consideration.
Sutherland, an ex–fighter pilot, academic, and software architect, co-created scrum—which is a version of agile software development—as an alternative to the traditional “waterfall” method of software design. Based on Gantt charts that were first used in World War I, the waterfall method requires development teams to spend months, even years, diagramming all the requirements of a software project and laying out every step on the way to completion before actually writing any code. As anyone who’s had any experience working on—or waiting for—such projects knows, even the most painstakingly mapped plans run into unanticipated problems in the real world. And when that happens, projects almost invariably come in late and over budget; that is, if they don’t fail.
The sheer waste this approach involves—in time, in money, and in people’s lives—offends Sutherland deeply. He is fond of quoting Taiichi Ohno, the father of the famed Toyota production system, who insisted, “Waste is a crime against society more than a business loss.”
The goal of scrum—the name is taken from the formation used to determine which team gets control of loose balls in the game of rugby—is to create value for the customer as quickly as possible. To that end, its main focus is getting project teams and team members to work together as efficiently as possible. In Sutherland’s view, teams should function like complex adaptive systems: They should be self-organizing and cross-functional, and they should work toward a single purpose, letting nothing stand in their way.
The focus of the book is on the ins and outs of scrum, giving company leaders a detailed how-to. The main idea is to break a project down into a succession of manageable pieces, with specific goals, called sprints. No planning on the scale of the waterfall method takes place; instead, Sutherland says, “Plan in just enough detail to deliver the next increment of value, and estimate the remainder of the project in larger chunks.” Each sprint is guided by the answers to three questions: Who is the customer for this task? What task needs to be done to satisfy the customer? And why does the customer want it?
Sprints are perhaps a week or two in length, during which the team works together to achieve its goals. Every day during the sprint, the team members meet to discuss their progress, asking and answering three more questions: What did each member do yesterday to further the team’s objective? What will each do today? And what if anything is slowing the team down? The goal, like Toyota’s goal, is continuous improvement in the team’s performance and thus its output. At the conclusion of each sprint, the team presents the completed product feature to its customer, then moves on to the next sprint.
It’s that simple, Sutherland insists. He offers plenty of examples of projects that were saved through this method—most notably the FBI’s failed decade-long effort to update its intelligence systems following 9/11. After adopting scrum, the bureau completed the project in a little more than a year, with a fifth of the workers employed on the earlier effort. If done right, Sutherland claims, the method can improve the productivity of any project team by 300 to 400 percent.
Sutherland claims scrum can improve the productivity of any project team by 300 to 400 percent.
Too good to be true? That, unfortunately, is hard to determine from reading this book. In Sutherland’s telling, scrum never fails, and every company that has tried it and then gone back to the old ways of doing things has seen productivity drop precipitously. But we all know that the devil is in the details, and although the scrum process is laid out clearly, the book’s examples are focused more on results than on the nuts and bolts of how scrum was implemented and adapted. Further, most of the detailed examples come from the world of software development, so it remains somewhat unclear just how to translate the method to other kinds of business projects.
Still, this is one of the relatively rare business books I actually enjoyed reading. The writing is clear, the stories are well told, and the process is intriguing—who knew that the optimal number on any team is seven? And Sutherland is a true believer: He devotes the last chapter to how scrum might change the world, in areas such as improving education, alleviating poverty, even fixing government. It’s easy to get caught up—his conviction is contagious. But the idea that showing people how to execute effectively will solve all our problems is a familiar one. And it remains to be seen whether scrum is the answer to problems outside the software development arena.
- Edward H. Baker is a longtime business journalist and a contributing editor at strategy+business.