Pattern languages can help us understand complex systems. Read how pattern languages work, and how you can write your own. We are defining agility and its practices using a pattern language called the Agile Canon. Using the first five patterns in the Agile Canon, you can diagnose whether your team is agile, whether it can keep its agility, and whether it expands agility beyond the team’s boundaries.
People struggle to learn large ecosystems of interacting concepts. Concept descriptions in isolation make little sense, especially if they only teach us How to do something, not Why it works. We spend tremendous time and money to learn complex fields like business management, software development, environmental regulation and medicine. Yet we marvel how profoundly different the real work is from what we learned. Do we really have to be immersed in ecosystems to comprehend them?
Faced with this challenge, UC Berkeley architecture professor Christopher Alexander developed a pattern language approach to explain complex ecosystems [alex1979]. He and his colleagues spent 8 years writing a best-selling book that describes healthy towns, buildings and construction, with the unlikely title A Pattern Language [alex1977]. This huge book, with over 1100 pages, lends itself to casual, flip-through reading.
It contains 253 patterns, each of which stands on its own. The pattern Office Connections, for example, describes how to organize an office to minimizes the “nuisance factor” inhibiting communication between colleagues; The Family describes how to build structures that support extended families, including friends, live-in relatives and common space; Zen View describes how to place windows in transition areas that accent a beautiful view.
Reading a well-written pattern language creates an almost spiritual feeling. The emergent processes that create patterns and languages remind us of chaos theory, fractals and complex adaptive systems, fundamental patterns from which life, economies, societies and religions can arise.
Some software architects, marveling at the similarity of Alexander’s patterns to object-oriented programming, employed patterns and pattern languages to describe ecosystems of software classes [gemm1994], interaction design [weli2003], and software development [copl2004].
In the hands of a good writer, the pattern format’s descriptive power is stunning. Each pattern in “Alexandrian format” stands independently, describing a context, a problem, the forces that constrain solutions, a solution that reconciles the forces and solves the problem, examples that illustrate its use, and the resulting context. When we understand why a solution is needed, we remember and use it.
Pattern languages are collections of patterns organized from general to specific. They describe the whole ecosystem in a generative way. You should be able to read just the first pattern of a pattern language and gain value. Under ideal conditions, you can often invent later patterns by applying earlier patterns.
The Agile Canon Project
The Agile Canon is a project to create a “theory of everything” pattern language for agile methodologies. Pattern languages can be like mathematics. Early patterns are axioms, and later patterns can be generated from them. But like rote addition versus mathematics, agile has been practiced for years, before anyone tried to put an axiomatic framework around it.
Agile applies to all creative fields. Agile management is not just for software, so we define agile without reference to software, but to creative activities, those activities where we are producing something new, in a different way. Software is a tiny subset.
Agilists study and teach many related methodologies. Why do agilists all admire and study Scrum, XP, Kanban, Lean Startup, Getting Things Done, The Responsibility Process, Pomodoro and Lean Manufacturing? Why do they make confusing distinctions between “agile” and “lean” practices? Why does Kanban look suspiciously like “Type C Scrum”? Why do teams with perfunctory Retrospectives look moribund? Why should a Sprint be a certain length?
With this effort we hope to address the most obvious and general agile questions first: Why do all these agile methodologies work? When do specific agile techniques apply? Is a specific effort, enterprise or person agile? We hope the general answers will help people answer field specific and methodology specific questions. We also hope to guide people to the right methodology, for their particular situation.
Pattern Goals
This article can help you read, critique and write patterns better. We want you to read patterns effectively (and hopefully with greater pleasure), so you will more easily understand and more effectively apply the patterns in the Agile Canon. We want you to recognize common flaws in patterns, so you can help us make these patterns better. We want you to be able to write patterns more effectively, because they convey knowledge so effectively. Life is much more fulfilling when you are surrounded by competent people, and all the better if you helped them gain that competence. Writing down your knowledge in patterns can help.
The earlier a pattern appears in a pattern language, the more general (and generative) it is. A non-practitioner should be able to read early patterns without a background in the field. Later patterns can assume readers are familiar (though not expert) with earlier patterns.
Well-written patterns can be skimmed by reading the first sentence of every paragraph, the summary sentence. This approach improves rapid understanding of the pattern. When it is consistent, readers can rely on it to help deliver information.
Patterns greatly benefit from critique, especially from lay people. Pattern writers have been immersed in a field and typically overestimate what readers know. So if you are a lay reviewer, we beg you to tell us when you don’t understand something. Not only will we be patient with dumb questions, we want you to ask whatever dumb questions you’ve got.
Readers embrace concise patterns. Not every pattern will be short, but we want no superfluous material. A simple context paragraph should tell us whether the pattern applies. Just one or two sentences can state a problem, otherwise we must edit it down. A good pattern describes all important forces, but ideally with only one short paragraph per force. Just one or two sentences can summarize a solution, especially since details can follow.
Well-written patterns may spend many words describing the context, the problem and the forces. Unfortunately, many pattern writers skip this part, and thus fail to tell us why we need the solution and where it applies. A well-written pattern should create a growing tension, as readers discover that one obvious fix after another will not likely work, due to forces constraining any solution. Readers need a cognitive “pattern matcher” to know when to apply the pattern, and that’s what these sections provide.
Active voice drives interest. Richard Lanham developed a great approach to editing in Revising Prose [lanh2006]. If you don’t want to spend the high price for his thin paperback gem, visit Purdue’s online writing lab for a quick introduction to Lanham’s “Paramedic Method” [purd2015].
What You Can Do
Non-agile practitioners have great value as reviewers. We’ll want to understand what confuses you or what bores you. Please send us a note at info@senexrex.com to volunteer as a reviewer. Since we can barely keep up with a weekly blog post schedule, editing posts at the last minute, we’ll ask you to review within 48 hours of receiving a draft.
We want agile practitioners to review, too. Tell us what we’re missing, or what mistakes we made. You can rip into us if you want (it’s already been done). We’re thick skinned.
We want agile practitioners to contribute patterns to this effort. The major constraint is that we get the final word on content and grammar. We will teach you how to beef up (and spice up) your prose, which will improve your future writing, and we will credit you and promote you. All our patterns list the author, and you have freedom to use the patterns you write in any other context. By submitting something you give us permission to publish the material with attribution to you, but without compensation. (For major contributors, we can negotiate a more rewarding approach, but we’ll want you to demonstrate contributions first.)
Anyone who wants to write patterns in another field can, of course, use this approach as a guide. We love hearing about new patterns and pattern languages, even if they aren’t in our field. We might even write an article about your efforts.
Finally, you can write about our work either in short comments or full-on blog posts. The first five patterns in the Agile Canon are called the Agile Base Patterns. They provide a great tool to tell whether something is agile or not, and how it could be improved. You can use those Agile Base Patterns, to analyze your favorite agile practice, or critique a claim you don’t like. Let us know about it. If you want to submit it as a guest blog entry (not all our blog articles are patterns), we really like guest bloggers.
We hope you like this effort. If all you do is cheer us on, we’ll likely keep doing it.
Pattern Template
Here is a pattern template we use throughout this effort. It is similar to Christopher Alexander’s format. You can copy-paste the template into your own document, and start with all the correct headings and paragraph marks. If you are familiar with CSS stylesheets, you can customize the fonts, spacing and alignment in your patterns as you wish.
Title
{image}
Context: {one paragraph context. First sentences should explain a neutral situation. Last sentence should hint at a problem.}
{one or two sentence problem} …
{one paragraph description}
Forces
{paragraphs each succinctly describing a force that constrains any solutions}
… therefore, {one or two sentence solution}
{paragraphs succinctly describing the steps in the solution}
Examples
{paragraphs each succinctly describing an example of the pattern in operation}
Resulting Context
{paragraphs each succinctly describing how the solution solves the problem or satisfies a force}
Related Patterns
Aliases
{list of aliases for the pattern, each referring to the methodology or field where it is used}
References
{example:
[smit2007] Joe Smith, “This was my life n paradise,” National Geographic (March 2007), http://natgeo.com/life-in-paradise.
…}
Acknowledgements
{very brief thank you, listing the names of people who contributed edits or comments that shaped this work specifically. Notify them before going public, as some consider an acknowledgement an implied endorsement.} The author is responsible for all errors in this piece.
Author
Review Checklist
As an author, this simple checklist can help remind you of the bigger picture: You want your reader to understand and appreciate what you wrote. As a critic, you can use this checklist to guide your review and make our patterns more readable.
| These required elements are present in the pattern: context, bold problem summary, problem description (one paragraph), heading “Forces”, paragraphs describing the forces, bold solution summary, solution description, heading “Resulting Context”, paragraphs describing aspects of the resulting context, heading “References”, list of references to gain more depth, heading “Acknowledgements”, list of people who helped you, “Author”, your name. | |
| Nothing more than these optional elements are present: heading “Examples”, one paragraph per example, heading “Related Patterns”, one paragraph per pattern, heading “Aliases”, list of aliases and the methodology where those patterns appear. | |
| You can skim the whole pattern by reading the first sentence of every paragraph. Do you get a rough idea of the context, problem, forces, solution, resulting context? | |
| You identified the paragraphs that most caused you to want to fall asleep, and fixed them. | |
| You looked for and identified grammatical errors. | |
| You identified things that confused you. | |
| You identified redundancies (two paragraphs or sentences that effectively say the same thing). | |
| You identified paragraphs or sentences that don’t really relate to the pattern. | |
| You did something else that should be in this checklist (and you mailed the author, me, or commented on this post). | |
| You applied the Paramedic Method to remove extra prepositions, convert passive to active voice, and tighten up the prose. |
If you are a reader or critic, would you please do us the service of emailing us or commenting on the pattern you read, with any problems you identified? We have a policy of naming people who helped us with acknowledgements, and linking to their LinkedIn profile. If you don’t want this, we are happy to keep you anonymous, just let us know.
Feedback
Christopher Alexander developed his pattern format without the benefit of rapid web feedback. We are starting to incorporate suggestions from readers on how to make the patterns more comprehensible and flowing. For example, the advice “Context: {One paragraph context. First sentences should explain a neutral situation, possibly referring to previous patterns. Last sentence should hint at a problem.}” contains the bridging idea of hinting at a problem. We invented this revision when people had difficulty understanding that the context was a setup for the problem.
We invite lots of feedback. If we communicate these concepts more effectively, we believe we can improve agile practice and the productivity and happiness of many people and organizations. How can we do better?
References
[alex1977] Christopher Alexander et al, A Pattern Language, (1977).
[alex1979] Christopher Alexander, The Timeless Way of Building, (1979).
[copl2004] Jame O. Coplien and Neil B. Harrison, Organizational Patterns of Agile Software Development, (2004).
[gemm1994] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, (1994).
[land2006] Richard A. Lanham, Revising Prose, 5th edition, Longman (July 20, 2006).
[purd2015] Purdue Online Writing Lab, “Paramedic Method: A Lesson in Writing Concisely,” https://owl.english.purdue.edu/owl/resource/635/01/.
[weli2003] Martijn Van Welie , Gerrit C. Van Der Veer, “Pattern languages in interaction design: Structure and organization,” Proc. Interact ’03, M. Rauterberg, Wesson, Ed(s)., 527–534, IOS Press (2003).
Author
Dan Greening
Senex Rex tackles challenging problems at the agile management frontier. We help companies, teams and leaders accelerate and sustain value and quality production, so we can all live better lives. We can coach and train you and your organization for the win. Contact us.
