This is a book about Scrum. Scrum describes a way for people to work together to create, build and evolve a product. Scrum also provides a framework for people to become better and better at their work. Scrum is a simple approach to work that can be succinctly described: the formal definition of Scrum in the Scrum Guide [1] is only 15 pages long.

Scrum is a framework for creating value through a product. It is not a methodology but rather an overall architecture of a work team and of the broad form of structuring work. Scrum focuses outward, on the end user, and the product that will add value to the user community, rather than on internal structures of work organization such as traditional projects. Scrum shines in complex domains faced with initial and ongoing uncertainty about product requirements, using frequent feedback, short iterations, time boxing, and continuous workflow to clarify uncertainty and to take development forward. Scrum is probably the most widely used of all agile approaches, with application in a broad spectrum of areas ranging from journalism and advertising to software production and automobile construction. Scrum finds its roots in Japanese manufacturing, broadly from the Toyota Product Development System, and in particular from the Toyota Production System.

Scrum — Through the Lens of Experience

Scrum adoption has grown rapidly since its inception in 1993 and its introduction to the public in 1995, and yet it is still new to many organizations. For organizations new to Scrum, finding where to start can be a mystery, and for organizations using Scrum, finding where to improve can be a challenge. Over the time that the contributors here have been using Scrum (and we have been using Scrum since its inception) we have come to understand the networks of patterns that underlie its successful use: how Scrum works, why it works, and how to implement it. The authors have several person-centuries of combined experience with Scrum. This book compiles what we have learned through that experience, offering proven solutions called patterns that we have distilled while observing many Scrum Teams — both their successes and failures. These solutions will help you implement and improve your use of Scrum whether you are a beginner or an experienced practitioner. Though pragmatic and grounded in experience, this book also stands on Scrum’s deepest foundations and reflects contributions from many early shapers of Scrum, including one of its two inventors. As a rationalized oracle, this book can help dispel many of the widespread myths about Scrum and its practices. The book’s solutions draw not only on prior art and publication but also tap the experience of a community of direct contributors who represent the insights and experience of a broad international community of product developers.

The patterns in this book come from observations all over the world, from our home bases in Japan, the Nordics, the UK, Portugal, Canada, USA, Netherlands, and Australia and our experiences on just about every continent except Antarctica. They have been observed in many contexts, from organizations with thousands of staff members to small teams of three people; and in dozens of industries: telecommunications, banking, education, machine automation, and countless others. Each pattern has been through a process of detailed review by up to a dozen people, who applied their collective dirty-hands experience with Scrum to relentlessly refine each one. Dozens of candidate patterns didn’t make it to the book, as rising only to the level of anecdotal experience, or as lacking empirical validation, or as precursors to greater patterns. We believe that the patterns in this book have something special. The pattern community calls it “the Quality without a name,” or sometimes just “the Quality:” a kind of Wholeness that aspires to day-to-day excellence.

The Scrum Guide defines Scrum as: “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” [1] This definition describes both the assumptions on which Scrum is based and the perspective we develop from using Scrum. One way to recognize a complex problem is that you don’t fully understand the problem until you see the solution, and you usually can’t derive the solution from first principles ahead of time. Solving the problem begs exploration and feedback. The adaptive element to the problem is that the problem changes over time and with our engagement, our current solution meets our current needs — but these will change. An example of this kind of problem is new product development: it may be very easy to see why the product was a success after it is successful but to know this beforehand is impossible.

Speaking of the Scrum Guide, we just view it as the rulebook for Scrum. It’s important to understand the rules and it’s even useful to follow them most of the time. But reading the rulebook of chess won’t make you a great chess player. After learning the rules one next learns about common strategies for the game; one may also learn basic techniques at this level. Next is learning how to combine strategies and maybe adding some of your own. Ultimately one can transcend any formalism and proceed from the cues one receives from one’s center, from one’s instinct. This book is for people who want to understand the rules more clearly and for those who want to grow by combining ideas and by evolving the fundamental level of the structure of the system more than by refining technique. Jeff Sutherland points this out:

In recent years the Scrum Patterns Group has evolved a comprehensive set of patterns for Scrum that allow teams to try proven approaches that have worked in many companies. While the Scrum Guide provides the basic rules of Scrum, the patterns amplify the guide by showing teams how to solve problems in a specific context. — Jeff Sutherland

So the Scrum Guide is the rulebook. These patterns shape the on-the-job-training of making Scrum work for you on your way up the ladder of ongoing improvement. And some day long from now you may outgrow even these patterns as you evolve them and define your own. There are no points for doing Scrum, and these patterns are the gate through which a highly driven team passes on the road to the top echelons of performance. Patterns do their job when they help people honestly and critically search within themselves to find a path to excellence. One ignores the patterns at one’s peril, but only an unthinking organization follows them slavishly.

Patterns of Scrum

What is a pattern? One simple definition is that a pattern is a solution to a problem that arises in a specific context. The modern idea of patterns was popularized by Christopher Alexander, a building architect, as a way for communities to celebrate, socialize, and refine the design norms of their built world. [2] The pattern writing form for solutions is a way to structure written insights that describe how people build things. Alexander’s focus was on constructing towns, neighborhoods, and buildings, but the underlying theory extends to anything built in community. This book focuses on the two main structures that organizations build to realize Scrum: the organization with its roles, relationships, and periodic gatherings of people, and the Value Stream that choreographs these gatherings over time and connects them to their wellsprings and to their effluent into the market. But beyond that, patterns structure how we understand systems and how we solve problems in a way that lets us reason broadly, while applying a concrete, proven solution locally. Patterns are about form and the rules for composing these forms. Scrum patterns are the forms we create and compose when applying Scrum to organizational and process problems.

Each pattern helps you structure your thinking around an aspect of the problem, couched in some background. It presents the solution and opportunities that such change brings to the organization, as well as the consequences of applying the pattern and what they imply for choosing follow-on patterns. A carefully chosen sequence of such patterns can resolve product development issues and, importantly, help the organization come to a deeper understanding of Scrum.

Patterns come from our reflective observations about our hands-on interactions to solve problems in the world. Where we see a problem and hear the small voice within us pointing the direction to a solution, we have the first inkling of a pattern. We try the solution to see if it works in our situation; if it does then we keep using it. Repeated substantiated experiences with such solutions crystallize them and give them stature as patterns. We may eventually write them down and share them with our community.

Patterns in general come out of community, and the patterns here are no exception. The patterns have their roots in our collective experience and have been chosen from a larger candidate set so each one represents something singular, fundamental, or important, or because it communicates otherwise elusive common sense. The authors have supported each other in re-shaping and polishing these patterns to incorporate perspectives from across the whole Scrum community. They reflect input and engagement from a broad constituency and, in particular, from people who carry the foundational insights of Scrum from its inception and early practice. These patterns go beyond descriptions of vernacular practice to capture the deep nuggets of insight that often elude everyday practitioners. For example, most people believe the purpose of the Daily Scrum is to answer the Three Questions; in fact, the Wikipedia article for stand-up meetings until recently said that the main focus of the Daily Scrum was to answer the Three Questions. To set the record straight, the Daily Scrum instead exists as an event where the Development Team re-plans the Sprint: answering the questions takes only a small fraction of the time, and is done just to provide context for the re-planning. There are also widespread misunderstandings about what it means to fail a Sprint, about the Sprint Goal, and about the role of specification in Scrum. In this book, we tap into longstanding experience, timeless origins, and the most authoritative sources to set the record straight. Each pattern has been through a long journey of review and refinement so you can enjoy a powerful synthesis of informed and authoritative views on those Scrum elements that they elucidate.

Beyond being just a “solution to a problem in a context,” each pattern explores the forces at play in the complex contexts of organizational development and workflow. These forces help you relate to the why behind the pattern. They help you first to understand the problem in depth and, second, to understand why the solution might work. However, if you find something in your deepest self whispering in your ear to try something other than what the pattern suggests, you are probably best to follow that instinct. You better know your situation and problem than we can ever encode in written form. If the pattern awakens your instinct and opens a path towards higher ground, it has done its job. A pattern is not always a goal, but rather a gate through which you pass on the way to seeing and acting more clearly. And in the agile spirit, the proof is in the tasting. Patterns are often small changes that can be implemented provisionally. After inspecting and adapting you may either go on to the next pattern or may in some cases decide to take one step backwards, undo the pattern, and try something else. Scrum is an empirical framework and each pattern should offer empirical evidence that it works, to validate your decision to apply it.

We divide written patterns into sections that lead the reader on a literary journey into understanding why the pattern works. A pattern always starts with a picture that serves as a kind of visual mnemonic for the pattern. The first section of text generally describes the situation in which this pattern occurs; this is called the context of the pattern. The end of the context is delimited with three stars. The second section is a statement of a problem that occurs in this context, usually highlighted in bold. Then follow the tradeoffs that play in the solution. These are called forces, after the metaphor of the forces of gravity and wind that must be balanced in the built world. However, Scrum patterns, like Alexander’s patterns, view forces in a much more inclusive way that includes our vulgar instincts, our aspirations, and our fears. Now we can tie together our context, problem, and forces with a solution. The solution is given as a simple, direct action in bold text. The end of the solution is delimited again with three stars. In most complex domains there are always some loose ends after applying even the best of solutions, so we usually add more descriptive text detailing how to introduce the solution and to describe how it works. The application of the solution results in a new situation with a new context, with new problems to solve, leading to new patterns.

It’s tempting to cherry-pick patterns and try to apply them to solve problems in isolation. Though each pattern helps us focus on the problem at hand, context is everything. Furthermore, when we apply a pattern, the solution will itself create new forces that must be resolved at a more finessed level, so it’s also important to have hints about what to do next. As much as each pattern describes a single solution to a problem, no pattern stands alone. We must think of each pattern like the 1960s bumper sticker: “Think globally, act locally,” Alexander tells us:

Each pattern can exist in the world, only to the extent that is supported by other patterns: the larger patterns in which it is embedded, the patterns of the same size that surround it, and the smaller patterns which are embedded in it. [3]

We share this fundamental view of the world, that says when you build something you must also repair and make better the world around it. The larger world then gradually improves, becomes more coherent and more Whole. A set of patterns that work together to this end is called a pattern language. A language has a grammar that defines “legal” sequences of “parts.” In a pattern language, the parts are patterns, but the relationships between the parts are as much or more part of the language than the parts themselves. Each pattern describes the context of the patterns it counts as already having been applied, and also advises us about what other patterns might further refine our Whole to help complete this pattern. This book presents two such languages: the Product Organization Pattern Language, and the Value Stream Pattern Language.

Most importantly, patterns are about people. Those of us who engage clients in Scrum transformation often find that they want us to tell them what to do, or that they ask pointed questions about a particular decision in their journey. Those who use patterns in this way are missing the core of their power. It is true that these Scrum patterns encode centuries of hard-won experience. Nonetheless, your particular situation usually brings its own forces, tradeoffs, and opportunities, and if you’re really in touch with your team and your business, the ability to recognize a great solution already lies deep within you. Rather than serving as instruction manuals, the patterns in this book were written to inspire you to carefully consider the forces at play in a particular situation, to draw you into wrestling with problems at a deeper level than business dialectic usually affords, and to lead you to discover those gems of collective insight that lie latent in the collective experience and spirit of your Scrum Team. They may remind you of what you once knew before you learned the modern techniques of your trade or the practices of current fashion in your industry. Like Scrum, patterns provide no final answers. Both of them are ways of refining the day-to-day processes by which we build great things as we aspire to creating value.

Last, it will be a long time before you run out of patterns for improving your organization. Scrum, like patterns, is based on a passionate and ever-present spirit of improvement that the Japanese call kaizen (カイゼン). A good Scrum team celebrates the discovery of a new shortcoming, carefully ponders what allowed such a failure to arise, and then looks within itself, perhaps guided by friends and patterns, to seek solutions to the problem. Even when things are going well, great Scrum teams constantly have the question on their mind: How can we do even better? This attitude is the heart of Scrum, and it shows up in events that range from the Daily Scrum where the team re-plans the Sprint to squeeze the absolute maximum value from their work, to the Sprint Retrospective where the team collectively reflects on problems and improvement. Both the Value Stream and Product Organization Structure languages offer patterns to make problems visible and effect frequent improvements so the team gets better and better. Value increases accordingly — whether “value” means higher quality product to an end user, or whether it means a better work environment and happier team.

Getting Started

New Scrum teams can use pattern languages as a kind of roadmap to introduce Scrum into their organizations, one pattern at a time. Dependencies between patterns form a complex graph, albeit a directed graph with no backtracking. Knowing where to start can be an overwhelming challenge. We have some suggestions for getting started with pattern languages and pattern sequences.

This book contains two pattern languages. We call them “languages” because they define constraints on the combination and ordering of the parts (the patterns) the same way that a grammar does (for example, for words). One pattern language (in Chapter 3) deals with the organizational structure and another (Chapter 4) deals with the structure of the Value Stream. Don’t let the titles scare you: we’ll introduce you to anything you need to know about Value Streams if it’s important for moving ahead. Both of these pattern languages can be said to deal with organizational design, at a level above the implementation concerns germane to your organization. Each pattern can be implemented a million ways without ever being the same twice. One language is the design of the Scrum organization; the other deals with the design of the metaphorical stream along which the product flows, turning the raw materials of its tributaries into products that flow into the sea. There is usually one Scrum organization per Value Stream. We split these patterns into two languages because the patterns of each language tend to be highly coupled to each other while being loosely coupled to patterns in the other language, and we find that this structuring helps newcomers more readily understand the big picture(s) of Scrum. These languages seemed to encapsulate all the patterns we started gathering as we stumbled from whimsical notions of the language identities to a much more rigorous formation of the “grammars” of ordering that underlie the existing languages. By synchronicity, they happen to match the division of organizational design patterns found in earlier research such as in [4]. You should nonetheless freely pick and choose patterns from both chapters as you design your new organization, just as we’re about to tell you.

To get started, get together as a Scrum team. Start with the book in one hand and a pad of small stickies in the other. Read through the patterns that catch your eye and put a sticky note on the first page of each pattern that excites you, or makes you nod, or that intrigues you as being able to make your Scrum more whole. Then create a totally ordered list of the patterns you have selected in the order you choose to implement them. Don’t get too serious about it; you can change the ordering at any time if you decide you don’t like the existing one. There can be a few patterns from the Product Organization Structure language and then a few from the Value Stream language according to your team’s collective insight. It is only that each pattern must not depend on any patterns that follow it in this sequence: patterns with more extensive scope (larger context) should precede patterns at a more refined scope. In general the order of appearance of the patterns in each of the book chapters is organized from large to small, but it is almost always a matter of common sense.

What results is called, simply enough, a sequence, or sometimes a project language (which is unrelated to the field of traditional project management, and that the same word is used is merely an accident of history). We have three example sequences in the book: the Product Organization Sequence, the Value Stream Sequence, and the Product Backlog Sequence. Each of them provides one potential pathway through the language, and each can be used as inspiration for how you will build your project language. Most example sequences start at the beginning, assuming you have absolutely no Scrum structure in place; if you have already started, find your existing context in the language and start there. Start with the biggest pattern where you can create something, then move to the patterns that refine it by selecting the smaller patterns you think will apply in your situation; then work through the even smaller patterns that refine these and select the ones that help you fix your particular problem. And thus starts your journey of improvement. Agile is as agile does, and implementing Scrum is itself a process of inspecting and adapting: Implement one pattern at a time so you can unambiguously assess afterwards whether it worked (see One Step at a Time). You’ll adjust the patterns in your sequence now and again, re-ordering, taking patterns out, and inserting others.

Deciding where to start can be important to gain traction and influence in an organization. But instead of finding “the right starting point” as above you can simply start anywhere. Taking a pattern from the book and working out how it fits in your organization then implementing the solution will take you on a path to more patterns and more change. Progress will be piecemeal as you move from pattern to pattern. You will find implementing the solution in one pattern will make a change in your situation — in the world — and thus creates a new context and the opportunity to apply another pattern to further improve it. This will be a piecemeal process of changing your team or organization.

Maybe you find that something is missing. We took the patterns to as high a level of excellence as our experience would afford. Maybe you need to finish the job for us, in your particular context. A pattern is always a work in progress. As Paul Valery asserted for his poems, a poem is never finished by its author: it is only abandoned. We have abandoned them into your hands, and they will again take up vivacity only when you make them your own. Take the liberty of evolving these patterns in your own direction. Assemble the community and write your own patterns, and add them to your own pattern language. We have provided a starting point and, in spite of our experience, cannot foresee every problem that will arise and don’t have an exhaustive knowledge of solutions. Especially in local contexts, you will be able to recall broad prior experience to know what has worked before in your situation. Such knowledge too often gets lost, and it often can be found hidden among the neurons of the grey-haired folk in your organization. Build a community around this pattern-writing activity and evolve your pattern language. You need to build the pattern language for your group: this book is only a pattern language. We feel we have roughed out the big picture and we hope you take this accumulated knowledge seriously, but in the end, it’s your show.

We want to take this opportunity to implore you to attend to the links each pattern offers: both to the patterns it refines, and to the patterns that further refine it. Although you may be acting locally, everything you do is in the context of the global organization. Always think about the wholeness of the Whole you are striving to improve, about your entire organization inside and outside the Scrum parts, and about all the people whose lives are touched by your world of work.

The Fundamental Process

In the spirit of “build the right process and you’ll build the right product,” the most basic process is what the agile folk call “inspect and adapt.” Deming called it PDCA (plan-do-check-act), and Alexander calls it the fundamental process. This is the heart of Scrum, and the cycle of process improvement is Scrum’s heartbeat. The Sprint in Scrum is first a cycle of process improvement, and second a cycle of regular delivery.

In the same way that Alexander’s early work on patterns had strong links to Japanese culture and in particular to some of its philosophical writings, so Scrum finds its roots both in Japanese industrial culture and in its deeper philosophy. Christopher Alexander (the pattern guy) has in recent years greatly expanded his vision of the theory of patterns, how to apply them, and how they work. In a series of works collectively called The Nature of Order Alexander describes the process by which people interact with the built world using their fullest humanity, striving to increase the Quality in all they do. This process well applies to your Scrum journey. We offer his “fundamental process” below as a guideline that might inspire you in your application of these patterns. We include it here as much for the sake of what it conveys about the nature of required personal presence in the process as for its steps. For “centers” in the following, you can roughly substitute patterns. Note that the patterns themselves help guide the intuition of the designer and the steps that the process follows: [5]

  1. At any given moment in a process, we have a certain partially evolved state of a structure. This state is described by the wholeness: the system of centers, and their relative nesting and degrees of life.
  2. We pay attention as profoundly as possible to this WHOLENESS — its global, large-scale order, both actual and latent.
  3. We try to identify the sense in which this structure is weakest as a whole, weakest in its coherence as a whole, most deeply lacking in feeling.
  4. We look for the latent centers in the whole. These are not those centers which are robust and exist strongly already; rather, they are centers which are dimly present in a weak form, but which seem to us to contribute to or cause the current absence of life in the whole.
  5. We then choose one of these latent centers to work on. It may be a large center, or middle-sized, or small.
  6. We use one or more of the 15 structure-preserving transformations [simple structures], singly or in combination, to differentiate and strengthen the structure in its wholeness.
  7. As a result of the differentiation which occurs, new centers are born. The extent of the fifteen properties which accompany creation of new centers will also take place.
  8. In particular we shall have increased the strength of certain larger centers; we shall also have increased the strength of parallel centers; and we shall also have increased the strength of smaller centers. As a whole, the structure will now, as a result of this differentiation be stronger and have more coherence and definition as a living structure.
  9. We test to make sure that this is actually so, and that the presumed increase of life has actually taken place.
  10. We also test that what we have done is the simplest differentiation possible to accomplish this goal in respect of the center that is under development.
  11. When complete, we go back to the beginning of the cycle, and apply the same process again.

Sometimes a pattern won’t resolve the forces you have in your context. Remember that there are no silver bullets; that these patterns are based on the collected experiences we’ve been able to put together, and that your situation may be different. You will need to make local adaptations for each pattern. Each pattern can be implemented a million different ways without ever being the same twice.

A Quick Tour of the Book

This is probably not a book that you will read cover-to-cover. We’re glad you’re starting with the introduction. A good next step might be to read the very first pattern, The Spirit of the Game, to gain additional perspective on the level at which you might aspire to think when applying the patterns of this book.

At the heart of the book are the two pattern languages in Chapters 3 and 4. Each of these pattern languages offers one perspective on the multiple forms cutting across your organization: Chapter 3 on the roles, relationships, and gatherings of people, and Chapter 4 on the organization of the workflow. You may certainly pick and choose from both chapters as described above. Each pattern is numbered and patterns refer to each other by pattern number rather than by page number, in accord with the convention that Alexander used in his work. After reading The Spirit of the Game you might read the main sequences: the Product Organization Sequence, and the Value Stream Sequence. Those sequences will give you an overview of the Wholes that the pattern languages represent and may draw you into more deeply reading individual patterns that speak to you.

Chapter 5 talks about how to bring the pattern languages into your own space, and provides an example of a sequence (project language) focused on building a high-performing team.

This book builds on past work which itself contributed much to agile foundations, and which itself has a wealth of insight into making Scrum work. Rather than reiterate those patterns here, we refer back to the original source. However, we want you to be able to recognize those patterns within yourself when you come across them, and we include short descriptions of each one to help jog your memory. Chapter 6 provides patlets (small, one-sentence pattern summaries) for patterns from other sources, particularly from the Organizational Patterns book. [4] And Chapter 7 provides patlets for the patterns in the book itself — we tend to use it as an annotated topical index when we are seeking how to solve a particular problem.

History of the Patterns

The Future of the Patterns

The community behind this book has finished its work for now. The pattern languages are not complete; because of emergence, change, learning, and progress, they are never complete. Again: we have abandoned these patterns to you and, for now at least, leave their future in your hands.

We wish you the best on your Scrum journey and hope that you can grow your team to the point where you realize a kind of transcendent Quality, and perhaps even beauty, in your quotidian work life. The Scrum way is a lot different from how we have been doing things for many years, and we hope this book will help you transition to a more agile approach, one pattern at a time, and then beyond. Go out there and change the world of work.

[1] Jeff Sutherland and Ken Schwaber. The Scrum Guide.,, 2016, p. 3 (accessed 2 November 2017).

[2] Christopher Alexander. The Timeless Way of Building. Oxford, UK: Oxford University Press, 1979.

[3] Christopher Alexander, Sara Ishikawa, and Murray Silverstein. A pattern language: Towns, buildings, construction. New York: Oxford University Press, 1977, p. xiii.

[4] James Coplien and Neil Harrison. Organizational Patterns of Agile Software Development. Wiley, 2004.

[5] Christopher Alexander. “The Process of Creating Life.” In Nature of Order Volume 2. Oxford, UK: Oxford University Press, 2004, p. 216.

[6] Alfred L. Kroeber. Anthropology: Culture, patterns, and processes. New York: Harcourt, Brace and World, 1948.

[7] Ikujiro Nonaka, Slides for 2014 Scrum Gathering, Tokyo.

[8] Jeff Sutherland. “The Origins of Scrum.”, (accessed 1 October 2015).

[9] James O. Coplien and Doug Schmidt, eds. Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995.

[10] Mike Beedle. “Scrum: An extension pattern language for hyperproductive software development.” In Brian Foote, ed., Programming Languages of Program Design 4, 1999, pp. 637-651.

[11] Source: Desktop file ScrumAsOrganizationalPatterns.doc, Jim Coplien’s MacBook, creation date of 3 March 2008.