Q&A on A Scrum Book: The Spirit of the Game

In A Scrum Book: The Spirit of the Game, Jeff Sutherland and James Coplien explore how to do Scrum well using patterns. There are more than ninety patterns which provide insight into Scrum’s building blocks, how they work, and how highly effective teams use them. 

InfoQ readers can download an extract of A Scrum Book.

InfoQ interviewed Sutherland and Coplien about the purpose that Scrum patterns serve and how we can apply the patterns to adopt Scrum to create effective teams, and asked them to describe some of the patterns from the book

InfoQ: Why did you write this book?

Jeff Sutherland: Two of the leaders of the original patterns movement wanted to focus on Scrum patterns (Cope and Neil Harrison). Ken Schwaber and I had been discussing for some time how we talk about how to play Scrum well without being prescriptive. The Scrum Guide focuses on what Scrum is, but the real magic comes from the way you implement it. The fundamental concept of Alexander of generating wholeness from patterns seems to me both right and profound. I wanted to help describe how to create great Scrum teams that are both hyperproductive and life-changing for the participants. I worked particularly on patterns that were critical to good Scrum implementation, and Neil Harrison and I published an early paper on how "Teams That Finish Early Accelerate Faster." Today I use patterns as a way to teach Scrum. 

James Coplien: I had two motivations. As someone who has worked a lot with Scrum teams, it never ceases to puzzle me how so many people could misunderstand Scrum so badly, even after being trained and having access to the Scrum Guide. The vast majority of people could not properly answer the simplest of questions, like, "Why do we hold the daily Scrum?" I thought it would be good to create a defacto standard for Scrum that explained the why behind the things we do. Second, I was sad that the pattern community had kind of lost its way with regard to striving for Alexander’s notions of wholeness and beauty in what they wrote. The whole agenda of indirect generativity, and much of Alexander’s agenda of human comfort, had been lost. The Scrum Patterns effort provided an opportunity for a clean start alongside existing pattern efforts, and to bring in some leaders from the pattern community in an attempt to help that community again find its North Star.

InfoQ: For whom is the book intended?

Coplien: There’s a little something for everyone who is in the business of making stuff. The market is largely ScrumMasters, Scrum practitioners, the people in their organizations, and the coaches, trainers, and consultants who serve them. Managers can use the book to learn to appreciate that they shouldn't meddle in production, while seriously taking the responsibility to stand behind and support those engaged in production and to reap the benefits and manage the risk of the kinds of radical changes that can take enterprises to a whole new plateau. It’s for anyone building complex products of any kind.

Sutherland: Anyone implementing Scrum who has a problem could probably find a potential solution in the patterns in this book. These patterns have gone through a rigorous workshopping process. Only after they have proven to work properly in multiple companies repeatedly, are consistent with the entire body of Scrum patterns, and are easily understood and implemented by Scrum teams, are they approved by an international body of Scrum experts. Some of the most important patterns for performance have been shown to work in dozens of companies 100% of the time. There is no other book like this, and I would not run a Scrum without it.

InfoQ: What purpose do the patterns of Scrum serve?

Sutherland: When I created Scrum, I focused on documenting what consistently worked across high performing teams. Particularly, the teams at Bell Labs had done things that are counter-intuitive. Who would say a team should be no more than 4-5 people? Only the people who  invented the C language and Unix. Who would get rid of all job titles because they slow things down? Later Cope’s research in Pasteur Project and massive amounts of other research data elsewhere proved all these fundamental concepts are right, yet there are still teams doing "Scrum" in teams too large, and too many specialists with job titles. The basics are not obvious to the typical IT group, and I figured it would take more than one lifetime for most organizations to figure out the basics. The Scrum Guide is too short to demonstrate the winning styles of play. Many dysfunctional teams will continue to suck forever if they don’t implement these patterns.

Coplien: We are all born with common sense, and build on that inborn wiring throughout our life experiences to develop a deep sense of what works and what doesn’t. Teams could leverage that deep collective insight to build great things together. Management formalisms, outdated cultural norms, desire to wield power, and corporate culture and history, often frustrate our inclinations to follow these intuitive paths. Scrum patterns help remind us of what we once knew - perhaps only tacitly - about how to organize work, and as such stand against much of what academia and professional development practices would teach us. They are not mandates to be followed literally, but rather hints that can awaken greatness within every group to create excellent teams and products.

InfoQ: In the first pattern in the book, The Spirit of the Game, you mention that "Scrum requires a spirit of interaction between people that can be difficult to define." Why does Scrum require this, and how can we verify if this spirit really exists in a team and organization?

Coplien: We took some inspiration from The Spirit of Cricket by Rob Smyth, which relates a story about how cricket umpires forced a player to remove an earpiece by which he was receiving instructions from his coach during the game. There is no explicit rule preventing such electronic communication in cricket, but there is a rule stating that anything that violates "the spirit of the game" is as much an infraction as it would be to violate any written rules. The same applies to Scrum. The Scrum Guide is the rule book that defines canonical Scrum. But Scrum is just in training wheels, with the understanding that teams will learn by falling short of the Scrum Guide or by veering off the path, falling off their bicycles and getting a few scrapes and bruises. That’s how a team learns either to follow a specific provision of the Scrum Guide, or, occasionally, learn that their own improvisation may be better. You don’t get a prize for following the rules perfectly; the focus is on results. A vision that goes beyond Scrum to the deeper and more profound notions of results, outcomes, value, passion, and fulfillment should be what drive the decisions of a Scrum Team. Measuring it? Look at how engaged the team is in their work — or look at the results.

Sutherland: The spirit of Scrum is to eliminate impediments that block productivity or the ability of the team to perform, including anything that negatively impacts the happiness of the team. The spirit of Scrum is to put the customer first, to delight them, to deliver amazing products that change their lives at a low enough cost that anyone can have them. The Spirit of Scrum is to improve organizational performance so that jobs are created, leadership is developed, and investors are rewarded. Anything not in this spirit which people call "Scrum" is a travesty.

InfoQ: How does Scrum view the management role? How can we involve managers when Scrum is adopted?

Coplien: Much of Scrum is about developing product, and Scrum is firm that managers should not tamper with day-to-day development decisions, and that they should not hold any control over product content decisions. In this regard the Scrum Team manages itself. The team continues to improve incrementally through kaizen: continual improvement. Yet there are opportunities for improvement outside the scope of product development, such as when launching a new product, allocating accumulated cash to improvement efforts, or finding economies of scale and scope across products. A manager might improve the overall value that a company provides to customers (and improve the corresponding profitability) by killing an existing product that is underperforming and redirecting corporate efforts to a more profitable product. Google has killed dozens of products to this end in the past decade. These are discontinuous changes or what the Japanese call kaikaku. These are management’s job. In addition to that…

Sutherland: Ken and I have followed Professor Kotter’s work on change for decades, and in one of his recent books, XLR8, he says he has never seen a successful agile transformation unless a separate operating system has been created running under agile principles and managed by agile leaders. At recent conferences, I have asked thousands of people how many of them had waterfall management for their agile practice. Over 90% say that this is a major problem in their organization. So I’ve documented in the Scrum@Scale Guide how to created an agile ecosystem that is lead by an Executive Action Team (EAT) that protects the agile bubble from any waterfall bureaucracy that will compromise the performance of the agile teams. That includes changing all the rules, principles, procedures, and policies that need to be changed or eliminated to maximize business agility. This is the role for managers in Scrum. They become Agile leaders, coaches of coaches, they listen to the teams, and they crush anything that gets in the way of the teams. And senior leaders in Silicon Valley companies tell me that doing this is a full-time job. Not only that, but some senior management teams working with me after running as a Scrum team have cancelled all non-Scrum meetings and non-Scrum reports for themselves and others, because traditional waterfall artifacts do not deliver value and are counter productive.

InfoQ: Let's explore some of the patterns in the book, starting with ScrumMaster Incognito. How does this pattern look. and what benefits can it bring?

Coplien: It might look like this at the Daily Scrum:

The pattern advises ScrumMasters that developers too often will treat them like their old managers, reporting status to them and expecting to be told what to do next. ScrumMasters should unambiguously and visibly disengage (go incognito) when they sense this. That sends the message that the team owns their own decisions and that they should manage themselves and organize their own work.

Sutherland: This pattern is implemented by some of the best agile coaches I have worked with when they assume a Scrum master role. For example, if you read the paper by Scott Downey and I (J. Sutherland, S. Downey, and B. Granvik, "Shock Therapy: A Bootstrap for a Hyper-Productive Scrum" in Agile 2009, Chicago, 2009), one of the key strategies used for creating hyper-productive teams is a strong Scrum master moving out of the circle in the Scrum Daily meeting and standing behind them. This only occurs after the team has booted up and is knowledgeable enough to start self-organizing by themselves to achieve the Sprint Goal.

Coplien: That "only after the team has booted up" is what, in pattern-ese, we call a Context. Some patterns require that other ones be in place before becoming actionable. The book helps readers understand what Context must be in place for each pattern to make sense. It also tells how each pattern’s Context and Resulting Context knit together the network of surrounding patterns so a team can lay out an ordered plan of kaizen.

InfoQ: What is the Organizational Sprint Pulse, and how can organizations apply this pattern?

Sutherland: In 2006 I began working with OpenView Venture Partners, and the founder and senior partner, Scott Maxwell, developed a management training program for our portfolio companies. He said all work results from a shippable increment at the end of each 

Sprint and needs to be integrated if there are multiple teams at the end of a Sprint. Therefore, the company operation needs to have integrated Scrum and financial data weekly, monthly, quarterly, and annually, and all parts of the organization will perform at a higher level with this common organizational pulse. We have almost a billion dollars invested in dozens of companies and this approach was the first thoroughly-documented training program for what we now call Scrum@Scale. Our latest fund for about a dozen companies using this approach increased their valuation from under 200M to almost 500M during 2018. The Sprint Pulse really works!

Coplien: Scrum — and human life in general — is much about rhythms. The base practice here is that teams work in cycles with a regular cadence. On top of that, cooperating Scrum Teams should synchronize with each other and with the cadence of the surrounding organization. If multiple cooperating teams get out of sync, then one team’s output may lie in inventory until it can be combined with the output of another team to create value. The Japanese would say that we want to reduce inconsistency (mura) to avoid these alignment skews. Synchronized rhythms also create a consistent context across teams, smoothing out flow and reducing stress on local development activities (reducing muri).

InfoQ: How can the High Value First pattern help us to deliver the most essential product backlog items first?

Sutherland: We find over and over that it is essential to prioritize all initiatives in an organization by value to fully appreciate that the bottom 30% of projects, releases, or initiatives have no value and should be terminated. For example, an IT services firm found that 30% of their employees were supporting Windows 7 when most users had already moved to Windows 10 and freed up hundreds of employees in one afternoon. Then looking at the remaining functions or features, we have extensive data in software and are seeing the same in hardware that two thirds of these features are never or rarely used by the customer, even when the customer says they need them when a project is specified. A primary challenge for a product owner is to not build these features, and focus all efforts on features the customer will use. Avoiding building there features will allow all projects to be completed early and is the basis for new project strategies based on Change for Free and Money for nothing. See "Update 2018: Agile 2008 – Money for Nothing and Your Change for Free" at scruminc.com. Scrum@Scale enables High Value First by specifying an Enterprise Metascrum which is a regular meeting of a Product Owner Team with stakeholders to get alignment on priorities. The Metascrum and Product Owner Team are two of the patterns in the forthcoming book.

Coplien: While this pattern is actually optimized for the special case of a fixed-cost, fixed-scope product development, it is more generally true that teams too often deliver on the basis of what salesperson yells the loudest or on the basis of "priority." Most teams want to deliver more and more, instead of delivering the right things in the right order. Yet Taichi Ōno notes that overproduction is the number one cause of waste (if the reader doesn’t believe this, just instrument your code to discover how much of it is never or rarely executed). In Scrum, we arrange the backlog in delivery order to reach for the highest value, rather in a priority order based on giving each item an independent ranking of importance and then starting with the sexy items or the ones that will go to the loudest customer. The humble concrete foundation must go in place before that lovely kitchen for which you yearn, when building a house.

InfoQ: What is an Enabling Specification, and how do they help the development team to stay in flow?

Sutherland: I ran the first FDA compliant Scrum project in 1997. Ken Schwaber was the Scrum Master. We eliminated 95% of the cost of FDA compliance. To do that we needed to trace everything back to design to get approval by the FDA. So I wanted an "Agile Specification" that would be short, clear, and rapidly executable. One of our colleagues and Agile Manifesto Signatory, Alistair Cockburn, objected vigorously and said there was no such thing as an "Agile Specification." Since I had been involved in many patent applications, I knew they averaged about six pages and were specific enough for a third party to implement without talking to the inventor so they had to be clear. The U.S. Patent law defines these as "Enabling Specifications." So I said we know what these are and they can be adjudicated in a court of law. This is what we need for design documents. A while back I was working with the head of Samsung TV in Silicon Valley, and he said, "I hate our 300 page specifications. The are hard to read, hard to understand, and hard to update. I ran Apple TV for 10 years and only had four specifications that were about six pages each!" So a major product should have only a few specifications and they should average six pages.

Coplien: How could I ever add something to that? ;-)

InfoQ: How does the Testable Improvement pattern support measuring improvement in teams?

Coplien: Continual improvement is a central focus of Scrum, as are empirically informed decisions. And Scrum recognizes that complex systems have varying performance over time. So even without doing anything, performance may occasionally increase, or may even increase if the team does something arbitrary. So, first, we measure whether performance improves in some dimension, which implies that the result must be measurable. Second, we measure whether the team in fact carried out the activity that they postulated would improve their performance. Last, we measure whether the improvement has staying power. This latter concern shows up in other patterns like Updated Velocity, while this pattern focuses more on whether the team in fact said what they did and did what they said. We find a similar notion in the Japanese notion of kamashibai, which is conformance to standard work.

Sutherland: Today, I train new ScrumMasters in the Toyota Kata, kaizen thinking. Every impediment is an improvement waiting to happen. Every sprint a team needs to prioritize the improvement that will give the most benefit for the least cost. The improvement should be small enough to measure the effect in the next sprint. This is fundamental to Lean and Scrum derives from Lean through the paper, by Takeuchi and Nonaka, who coined the term "Scrum." The Testable improvement pattern shows a team how this might be implemented.

InfoQ: How can we apply the patterns to adopt Scrum to create effective teams?

Coplien: Just dive into the patterns, let them speak to your deepest self and to the team’s sense of excitement at what might be improved, and try one at a time while measuring results. You can start by looking for the patterns that attack your most serious weaknesses, or for the ones that engage the team’s passion, or you can just go through them one at a time. Let each one guide and inspire you instead of constraining your intuition about how to roll out the solution.

Sutherland: Scrum is a set of patterns. It is not a methodology. It is a framework for implementing patterns that great teams have used repeatedly all over the world in sports, in industry, in government, and even in academia. The Scrum Patterns Group has done an amazing job staying focussed for 9 years to deliver the most important patterns written down in a way that a new team can pick them up and run with them. So if you have a problem, just look through the Scrum Patterns book. The solution may be a pattern waiting for you to find it!

About the Authors

James "Cope" Coplien (shown doing a Testable Improvement) is a contributor to and product owner of "A Scrum Book." As a consultant, coach and educator, he serves companies in their lean and agile journeys at all levels from the boardroom to the pair programming desk. He does software architecture stuff, too, and is a co-creator of the Data-Context-Interaction software paradigm. When he grows up he wants to be an anthropologist.

Jeff Sutherland if a former fighter pilot and professor of radiology. Using the operational design of fighter pilot training and his super-computing research in medicine, he became the co-creator of Scrum and creator of Scrum@Scale. He is happiest in his Tesla P100D when he punches the throttle and achieves 0-60 in 2.4 seconds.