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 overwhelming. This section will help you get 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) in the same way that a grammar does (for example, for words). As mentioned earlier, one pattern language (in Chapter 2) deals with the organizational structure and another (Chapter 3) 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 pattern languages are broadly about organizational design, at a level above the implementation concerns germane to your organization. You can implement each pattern in a million different ways. One language describes the design of the Scrum organization; the other describes the metaphorical stream along which the product flows, turning the raw materials of its tributaries into products that flow into the market. 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, but loosely coupled to patterns in the other language. We find that this structuring helps newcomers more readily understand the big picture of Scrum. The connections between patterns became more clear as we added new patterns, and they started to fit together like puzzle pieces that belonged in two separate puzzles. Then we fine-tuned the languages’ structure and content by evaluating sequences that they generated, to form a more rigorous “grammar” of ordering. By synchronicity, our overall result matches the division of organizational design patterns found in earlier research such as in Organizational Patterns of Agile Software Development [CH04]. As you design your new organization, you should freely pick and choose patterns from both chapters.

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 follow your intuition and change the ordering at any time. 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. To order your patterns, place ones that have more extensive scope (larger context) before those with a more refined scope. For example, if you are a Product Owner and already have a vision for your product, you might start with a Product Roadmap and then introduce a Product Backlog and Product Backlog Items. Maybe you decide to hire someone to help you through the Scrum process from this point on so you bring a ScrumMaster on board. Alternatively, you may hire a Development Team and let it take the lead to hire a ScrumMaster. Eventually you start working towards a Refined Product Backlog. Ordering your list of patterns is always a matter of common sense.

Pattern Sequences

We call this ordered list of candidate patterns 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 present five example sequences in the book: the Product Organization Sequence, the Value Stream Sequence, a Product Backlog Sequence, a A Scaling Sequence, and a sequence called A Project Language of Highly Effective Teams. Each sequence describes one typical path through the language, and you can use them as inspiration for your own 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 even further, 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 ​¶88 One Step at a Time​). You’ll adjust the patterns in your sequence now and again, reordering, taking some patterns out, and putting others in.

Piecemeal Progress Toward Wholeness

Deciding where to start can be important to gain traction and influence in an organization. But instead of finding “the right starting point” as described earlier, you can simply start anywhere. Taking a pattern from the book and working out how it fits in your organization and implementing the solution will take you on a path to more patterns and more change. Progress will be piecemeal as you move from one pattern to the next. 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 could 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 pattern 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 offered a starting point, and in spite of our experience, we can’t foresee every problem that will arise. We certainly don’t have an exhaustive knowledge of solutions specific to your situation. Especially in local contexts, you will be able to recall broad prior experience to know what has worked for you before. Such knowledge too often gets lost, and one can often find it hidden among the neurons of the gray-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: each of the book’s two major chapters comprises only a pattern language. We feel we have roughed out the big picture. 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 you touch in your world of work.