Foundations

Scrum's patterns

A pattern describes a problem that comes up again and again, the constraints that make it hard and a solution that others have already tried and tested. The idea comes from an architect, Christopher Alexander, and it was applied to organizations, then to Scrum. This article explains how to read a pattern from A Scrum Book and what you can expect from it.

A waiting room and a snack corner

You arrive early for an appointment and are told to wait in a corridor, on a chair, with nothing to do and no idea for how long. In a 1977 book, A Pattern Language, the architect Christopher Alexander and his co-authors describe this problem under the name "A Place to Wait". They propose a general solution: wherever people have to wait, the place should be arranged so that the waiting becomes a positive moment.

Some forty years later, Scrum practitioners described a related problem. A team works well, its reputation grows, and more and more colleagues come to ask it for advice or a hand. Every visit interrupts someone. Their solution has a Japanese name, Oyatsu Jinja ("Snack Shrine"): near the team, but not too near, you set up a table with coffee and something to nibble. Visitors settle there and wait until a team member takes a break. The authors note that their sketch is inspired by Alexander's pattern.

These two texts share the same form: each describes a problem in its situation and proposes a solution observed in several places. That is what is called a pattern.

From architecture to organizations

Christopher Alexander (1936-2022), professor of architecture at the University of California, Berkeley, published A Pattern Language in 1977 with Sara Ishikawa and Murray Silverstein, a collection of 253 patterns ranging in scale from a region to a single room. Two years later, The Timeless Way of Building set out the theory behind it. His idea is that places where people feel at ease share recurring forms, and that the people who live in them can learn to recognize and combine these forms without leaving everything to specialists.

In the early 1990s, computer scientists took up this form to describe solutions in program design. A group that would come to be called the Hillside Group met for the first time in August 1993 in Colorado, and the first PLoP conference (Pattern Languages of Programs) took place in August 1994 in Illinois. From that time on, James Coplien wrote patterns that dealt with the organization of teams rather than with code. With Neil Harrison, he gathered them in 2004 in Organizational Patterns of Agile Software Development.

Scrum and patterns crossed paths early. Jeff Sutherland has often said that these organizational patterns were among the sources of the first Scrum. With Mike Beedle and others, he presented a collection of "Scrum patterns" at a patterns conference as early as 1998. An annual conference, ScrumPLoP, has been held since May 2010. Every pattern there is reviewed and criticized by other authors, sometimes as many as a dozen. The resulting book, A Scrum Book: The Spirit of the Game, came out in 2019 from Pragmatic Bookshelf under the names of Jeff Sutherland, James Coplien and the Scrum Patterns Group, eighteen of whose members are named. Lachlan Heasman, Mark den Hollander and Cesário Ramos formed its editorial team with Coplien.

The group summed up its aim in 2011. Its mission statement observes that the Scrum Guide "doesn't tell you the rationale behind Scrum as a whole, or behind many of its successful practices", and patterns serve to put those reasons in writing so that they can be passed on.

How to read a pattern

All the patterns in the book follow the same outline, taken from Alexander. The table sets it out with the example of Oyatsu Jinja.

The forces are the most instructive part. The authors explain that they include material constraints, but also "our vulgar instincts, our aspirations, and our fears". The forces explain why the problem does not sort itself out, and they let readers check whether their own situation resembles the pattern's. When your forces are different, the proposed solution is probably not the right one for you.

Two conventions help you find your way around. Each pattern carries a number preceded by the sign ¶ (The Spirit of the Game is ¶1). Its name is also followed by zero, one or two stars, which show how confident the authors are. Two stars mean they believe every Scrum team will eventually need this solution. One star means the pattern is the core of a good solution without being the only possible one. No star means the solution often works, but others exist.

A pattern is not applied on its own

The authors warn against the temptation to pick an isolated pattern to fix an isolated problem. They give the example of an organization that decides to make its teams autonomous, because autonomy strikes it as central. It soon finds that the teams cannot be autonomous: they lack skills, and they keep depending on people from outside. It needed first to commit to bringing all the necessary skills into the team (the Cross-Functional Team pattern), and only then to aim for autonomy (Autonomous Team).

That is why patterns are organized into pattern languages. A language has a grammar, which tells you which combinations make sense. In a pattern language, each pattern indicates which ones it assumes are already in place and which ones can complete it. The book contains two languages, one for the organization and the other for the value stream, which the article on the Scrum core as patterns presents.

A sequence is a path through a language, that is, the ordered list of patterns a team decides to apply. The book gives five examples and invites each team to compose its own. The working rule is to apply a single pattern at a time, so that you can judge its effect, and to step back if it does not suit. One pattern in the book, One Step at a Time, deals with this point.

To help readers find their way among the book's 94 patterns, an appendix gives their patlets, summaries of one or two sentences that boil each pattern down to a problem-solution pair. The patlet of Small Teams, for example, reads: "Having many people working on the same thing inflates communication overhead. Therefore, use small teams of people working on serialized work rather than striving for false parallelism."

Writing your own patterns

The authors see their collection as a starting point. They invite each organization to write the patterns it is missing, and they point out that one criterion separates a pattern from a good idea: the solution must have been observed several times, in places that did not copy one another. The book recounts that in 1993 Coplien wrote one of his first organizational patterns, on working in pairs, after a discussion with Paul Chisholm and Ward Cunningham in which they had found three independently "invented" uses. The authors also say they set aside dozens of candidates that rose only to the level of anecdotal experience.

This example shows what a pattern offers beyond an instruction. The instruction would say "handover at 12:50". The pattern says in which situation the solution holds, what it costs and what it leads to.

Guide and patterns: two different standings

The Scrum Guide sets out rules and calls itself "immutable". Patterns have a different standing. The book compares the Guide to the rulebook of chess, which you need to know but which does not make a good player, and it presents its patterns as strategies you can adapt or reject. In its own words: "One ignores the patterns at one's peril, but only an unthinking organization follows them slavishly." The 2020 edition of the Guide acknowledges this division of labor: it says that patterns and practices complement the framework, and that describing them is a matter for other sources because they depend on context.

You should also know that the book was written before the 2020 edition of the Guide, and that its references cite the 2016 edition. Its vocabulary is therefore older: it speaks of the "Development Team" rather than "Developers", writes "ScrumMaster" as one word, counts three "roles" and does not know the Product Goal. On one point, it got ahead of the Guide. Its introduction explains that the Daily Scrum exists for replanning the Sprint and that the usual three questions are only a means to that end. The 2020 edition of the Guide dropped these three questions.

Limits and pitfalls

A pattern is experience put into shape. Scrum's patterns have been observed by practitioners in many teams, then reviewed by their peers. That does not make them results of controlled trials. When the book speaks of empirical validation, it means repeated observations by the community of authors, several of whom make their living from Scrum training and consulting. Teams where a solution failed without anyone writing it down do not appear in the collection. The article Criticism and the state of the evidence returns to this difference.

The stars measure nothing other than the authors' conviction. The vocabulary inherited from Alexander, which speaks of "the Quality without a name" and of "Wholeness" with a capital letter, may appeal or irritate, but it does not lend itself to verification.

Two kinds of misuse are common. The first is picking out a solution without reading its context or its forces, as in the coffee machine example. The second is turning the collection into a checklist and counting the patterns "in place", which amounts to repeating with patterns the mistake the book holds against those who apply the Guide mechanically.