Scrum: The Art of Doing Twice the Work in Half the Time is a great refresh of the history and ideas around Scrum. I first learned about agile and Scrum back around 1999 and read Ken Schwaber’s book Agile Software Development with Scrum (2001). Scrum started as a way to deliver software faster, and Schwaber’s book is rooted in agile tactics for software, and, I think, Schwaber’s book talked about it as a way to do “Extreme Programming” (XP) specifically.
This new book is about organizing almost any kind of delivery via Scrum. So now we’re not just delivering complex software products, but any product. The book is a bit of a brag book, too, because Sutherland recounts the many different kinds of organizations using Scrum for various things. [Full disclosure, by the way: I was trained as a Scrum product owner by J.J. Sutherland, the co-author of the book.] Very generally, I'd say that if you know Scrum from the late 1990s or 2000s, or if you've just picked it up by osmosis, now is the time to get up-to-date with this revisioning of Scrum.
I want to pick out a few things that are emphasized here that aren’t pushed very strongly elsewhere. Some of these are rejiggerings and subtle changes in emphasis. For instance: “Scrum is the framework I built to put these values [of the agile manifesto] into practice. There is no methodology” (13; emphasis added). This is a pretty big deal. In recent years there has been a reduction in the force of Scrum because people have codified it as a “methodology.” But Scrum is highly adaptive, and asks the practitioner to “inspect and adapt” and improve the practice as you go along. Therefore, there is no strict methodology: Scrum is more of a way of practice, and this deserves triple underlining. One thing I have learned from great Scrum practitioners such as Angela Johnson is that the values come first. If you are implementing Scrum simply by “turning the crank” and using the ceremonies and roles, you may be missing the point. The book does a good job at emphasizing the Scrum retro in which the team reflects on how it can improve. It’s the critical moment of self-consciousness when one directly lives the values of the agile manifesto.
Another departure from representations of Scrum is an account of the origins. Sutherland particularly notes Scrum’s roots in the Air Force’s fighter pilot “OODA Loop” (Observe Orient, Decide, Act), and the Toyota/lean PDCA practice (Plan, Do, Check, Act) (Chapter 2, 23-39). The point here, again, is that Scrum is about its values and becoming adaptive: As the authors put it: Change or Die. Given the rapidly changing competitive landscape in most industries nowadays, you had better do that. But how? Again, Scrum is the framework, and through its practices you can become more responsive.
A couple of other rejiggerings: It is not uncommon in Scrum books and manuals to put the Scrum Master and Product Owner roles first; but in this book, the idea of the team comes first. Based on my experience with Scrum, I think this is entirely appropriate (a recent book, The Art of Business Value, even wonders if we really need Product Owners . . . but I digress). The team should be self-contained: “When you look at the best teams . . . there isn’t this separation of roles. Each team has all the people on it to do everything, soup to nuts”; you need “all the skills necessary to get the job done” (53; 54). While people are brought into the team to cover all of its needs as a unit, you might still cross-train to reduce the bottlenecks of specialization (54). However, there is a tricky unresolved puzzle here in Scrum: While people are brought into the team to ensure that all needs are covered internally (implying specialization at formation, I would think), the creation of multiple communications paths through the specialists is a cost: “how could we get that kind of saturation [few communication paths through specialists] on our team? The thing that cripples communication saturation is specialization — the number of roles and titles in a group. If people have a special title, they tend to do only things that seem a match for that title. And to protect the power of that role, they tend to hold on to specific knowledge. So we got rid of all titles” (78). Based on what I have seen, this is why Scrum and institutional change are so tied together: For a small team to work efficiently, everyone must know everything, so that no one is a bottleneck. This is quite difficult in practice. There could be a whole additional chapter on how to change your organization so that knowledge isn't siloed and team members can fill in everywhere.
Another new rejiggering is the focus on time management: E.g., against multitasking (88-94), for small batches (94-97), getting it right the first time so as not to repair stuff later (97-100). Here Sutherland brings in a number of sound management discoveries from the last 40 years. But, really, this is something of an extension of Scrum as it has been developed over the last couple of decades. This is a bit of a flaw in the book: There’s Scrum and “extras,” and the book tends to bind into Scrum a lot of the extras: For instance, estimation and burndown charts (Chapter 6). Yes, there’s estimation in the Scrum Guide but the approach here is pretty prescriptive. Burndown charts are mentioned only in passing in the Scrum Guide. In other words: Not core Scrum. In my opinion, a significant part of the benefit of Scrum is its limitation in scope. You can build other things on top of it, but only the ceremonies and roles are really essential.
The last thing I want to pick out is what is to my mind the great gap in Scrum: the framework does not extend upwards to business strategy. Scrum is truly demarcated by the perspective of the product / product owner. So, on p. 50, we are told that it’s “management’s role to set the strategic goals, but it’s the team’s job to decide how to reach those goals.” OK, that’s great: I love the distinction between management’s saying “what” will be delivered while the team decides “how”; but Scrum is really a framework for delivery only. Where does that strategy come from? Who decided that this product is going to be built? Is it just given to the Product Owner on tablets from heaven? This leaves a lot of people scratching their heads wondering how Scrum deals with strategy. Note that Sutherland says “I rarely recommend that CEOs or other senior executives be Product Owners” (179). So here you see that there is a distinction between Scrum (delivery) and not-Scrum (strategy). Then Sutherland says that “The key is to decide what the measure of value is and hold the Product Owner accountable for delivering more of it” (180). So where do these measures come from? Sutherland doesn’t really say, except to note that “In a business context, what matters is revenue” (180). I guess so! I think this is the big gap in Scrum: A lack of an account of how to couple a company’s vision, strategy, and delivery. Scrum has tried to articulate some of this via the idea of a “Scrum of Scrums” or through “Scrum at Scale” or SAFe: But since this book is supposed to be a short vade mecum for Scrum, and this is isn’t addressed . . . I’d call this a sort of bug (not a feature) in Scrum. In the book, we get some thoughts on organizing a whole company in a Scrummy way through the example of Valve, which has no managers: But that is skimmed over. There’s a real story here that might be about the combination of frameworks more dedicated to strategy (such as OKRs) and Scrum (for delivery only).