Patterns of Scrum
We describe elements of the Scrum framework using a form called patterns. What is a pattern? One simple definition is that a pattern is a repeatably applicable solution to a problem that arises in a specific context. Christopher Alexander, a building architect, popularized the modern notion of patterns as a way for communities to celebrate, socialize, and refine the design norms of their built world, in The Timeless Way of Building [Ale79]. The pattern-writing form (see Pattern Form later in this chapter) structures the written insights that describe how people build things—things that aspire to a quality of Wholeness which pattern folks call “the Quality without a name.” You might have experienced the feeling of this Quality if you have seen some result in an area in which you have deep experience, that just “feels right“ or gives you a deep sense of warmth, contentment, and confidence.
Alexander’s work focused on constructing towns, neighborhoods, and buildings, but the underlying theory extends to anything built in a community. Beyond that, patterns structure broad solutions to recurring general problems, while each one unveils a concrete, proven solution in the reader’s mind. Patterns in general describe forms and how designers compose them as they create and evolve structure in their worlds. 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 out to the market. Scrum patterns are the forms we create and compose when we structure both the development organization and the development process.
Each pattern helps you focus your thinking on a single, well-contextualized problem at a time. Working in small steps reduces risk and helps teams move forward with confidence in “process improvement.” Each pattern describes the solution in enough detail to bring you to the point of that “aha” where you recognize the solution deep within yourself. Beyond that, the pattern suggests how it might change the organization, and it looks ahead to both negative and positive consequences of doing so. Patterns also draw on experience to suggest a set of next steps that are likely to make the system yet more Whole. A carefully chosen sequence of such patterns—a listing of the canonical order in which the organization designer introduces change—can resolve product development issues and, importantly, help the organization understand Scrum more in depth.
The Birth of a Pattern
Patterns come from our reflective observations about our hands-on interactions to solve problems in the world. We have the first inkling of a pattern when we see a problem and hear the small voice within us pointing us toward a solution. We try the solution to see if it works in our situation. If it does, then we keep using it and move on to the next challenge. And if it doesn’t, we back out the change and try something else. (Sounds agile, doesn’t it?) Repeated substantiated experiences with such solutions crystallize them and give them stature as patterns. We may eventually write them down and share them within 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. The authors have worked together to choose only the best from a much larger set of candidate patterns that arose along the way. Each pattern has earned its position here because it represents something singular, fundamental, or important, or because it communicates otherwise elusive common sense. The authors have supported each other in reshaping 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 ¶29 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. (Notice that we refer to patterns using a notation that starts with a “¶” semaphore followed by the pattern number and the pattern name. The section Book Notations later in this chapter describes such notations and naming conventions in some detail.) To set the record straight, the Daily Scrum instead exists as an event where the ¶14 Development Team replans the ¶46 Sprint: answering the questions takes only a small fraction of the time and is done just to provide context for the replanning. There are also widespread misunderstandings about what it means to fail a Sprint, about the ¶71 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 explain and clarify.
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 are the why behind the pattern. Through these patterns, you can understand the problem in depth and better appreciate 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 know your situation and problem better than we can ever encode in writing. 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 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 you can implement 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.
Pattern Form
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. Three stars delimit the end of the context. The second section is a statement of a problem that occurs in this context, usually highlighted in bold. Then follow the trade-offs that play in the problem. We call these forces, after the metaphor of the forces of gravity and wind that an architect or builder must balance 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 a simple, direct action in bold text, couched in a short explanation to make the solution clear. Then come the three stars again to delimit the end of the solution. In most complex domains there are always loose ends after applying even the best of solutions, so we usually add more descriptive text detailing how to introduce the solution. This text also describes how and why the pattern works, so the reader can build on his or her own insight to build the most Whole result. The application of the solution results in a new situation with a new context, with new problems to solve, leading to new patterns.
At the beginning of each pattern, we have annotated the pattern name with zero, one, or two stars. If a pattern has two stars, we believe that you ultimately will need this solution to resolve the forces to move forward in Scrum. If it has one star, we still believe that the pattern is the core of a good solution; however, we cannot argue that it is the only way. If the pattern has zero stars we still feel it works as a solution and that it is the best solution much of the time—though other good solutions exist as well.
No Pattern Stands Alone
It’s tempting to cherry-pick patterns and try to apply them to solve problems in isolation. In simple systems, we can tire-patch individual problems without being distracted by adjacent concerns. However, in a complex system such as a workplace organization, changes we make in one place may have unintended side effects elsewhere. Though each pattern helps us focus on the problem at hand, context is everything. Applying each pattern in the broader context of the patterns that are already there helps us avoid unintentional setbacks from side effects. A pattern language strives to order patterns in a way that minimizes such setbacks. We have worked hard to do that for you here.
For example, consider the patterns ¶16 Autonomous Team and ¶10 Cross-Functional Team. You might decide that team autonomy is such a central agile principle that you want to put it in place early, so you try to apply that pattern first. But then you find that the team really can’t be autonomous, as it shows signs of depending on external workers to fill gaps in their expertise as work calls for specific competencies. The commitment to becoming cross-functional needs to be in place before a team can achieve autonomy, so it will be suboptimal to consider one without considering the other.
When you apply a pattern, the solution will itself create new forces that you must resolve at the next level of detail, 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, interdependencies of complex system components imply that no pattern stands alone. We must think of each pattern like the bumper sticker from the 1960s: “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. (From A Pattern Language: Towns, Buildings, Construction [AIS77], p. xii.)
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 world at large 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 those patterns that are prerequisites for the current one. And each pattern also advises us about what other patterns might further refine our Whole to help complete this one. These relationships, or connections, form a structure, a grammar, a language. This book presents two such languages: the Product Organization Pattern Language, and the Value Stream Pattern Language.
Sometimes, you just need patience. Fixing an organization often has more of the complexity of a train wreck than that of putting on tire patches. While acting locally, think globally. Sometimes you will need to apply several patterns—maybe over several months—to solve a complex problem in the organization. Together, these patterns will resolve the forces in the organization in a way that allows the solution to emerge. We say that the patterns generate the solution, indirectly, rather than subdue the system by force. It might take some mental discipline to subdue your instincts to try to coerce the system into providing immediate gratification. In the end, you can’t control a complex system, and it may require several individually small nudges to turn the ship. But remember: apply a single pattern at a time (¶88 One Step at a Time).
Patterns Are About People
Most importantly, patterns are about people. Some of our clients want us to tell them what to do in Scrum transformations, or to answer 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, trade-offs, 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 creating patterns as instruction manuals, we wrote these 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 to engage our instinct to refine the day-to-day processes by which we build great things that add value to our community.
Kaizen Spirit
Lastly, 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 replans the Sprint to squeeze the absolute maximum value from their work, to the ¶36 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 a happier team.