First, read the patterns. We have attempted to put them in a logical order; in the order of a typical sequence through each of the languages. So begin by reading them in order.
We use Alexandrian form for our patterns: a stylized format for organizing the important components of a pattern. The body of each pattern starts with a statement of the context in which that pattern applies. A problem may arise in that context; the problem description comes next in the pattern. Then the pattern elaborates the problem with a description of the forces that define the problem. Last, the pattern presents a solution that we have validated across a spectrum of development organizations, followed by a rationale that describes why you might believe the pattern should be successful.
In HowThePatternsCameToUs, we gave a detailed description of the methodology and research technique behind the pattern. We told you that section was optional reading. Nevertheless, it's important to go into the rest of the book with some level of understanding of the source of the patterns, so we give you a summary here.
All of these patterns came out of empirical research. Most of the patterns were distilled from observations gleaned from organizational analysis exercises we conducted on dozens of organizations worldwide. These exercises were used to build organizational models. The role is the basic building block of these models. Every organization has roles: developer, manager, systems engineer, tester, and many more. Roles get their work done by interacting with other roles, and much of the success of an organization owes to how effectively roles can exchange information and work together. Each model attempts to capture these interactions between roles.
We gathered the data for the models in a role-playing exercise where each participant tracked the interactions between their role and other roles in the model as the role-play progressed. We used CRC cards -- a technique borrowed from object-oriented design -- as the tool for capturing these interactions.
These data were fed into a tool to visualize the interaction structure of a given organization. We discovered many of these patterns by looking at diagrams of the communication structures between roles or individuals in the organizations. It was easy for us to notice important features and anomalies in these pictures, and it will be easy for you to do so as well.
For example, consider the following organizational model (called a sociogram) that we cite frequently in this book:
The roles near the center are more closely coupled to the organization as a whole than are those nearer the outer edge. Roles that are near each other are more closely coupled to each other than they are to more distant roles. And roles with more coloring are more coupled to other roles than the ones with less coloring.
We can see many patterns in this picture. We can see that the roles in this organization DistributeWorkEvenly, since the amount of work -- reflected by the shading of the roles -- is spread around rather than being centralized in a handful of roles. We can see that the ArchitectControlsProduct, being central to the organization. We can validate that the ArchitectAlsoImplements because of the proximity to the Coder role. Of course, when we wrote the patterns, we had additional information that led us to these conclusions, information that came from the organization's process sequences. But these diagrams serve to substantiate and illustrate those observations.
(Don't worry that you don't yet understand these patterns; we'll get to them later on.)
That is just one kind of visual model that we can build. Here is another model of the same organization:
The axes of the interaction grid span the roles in the organization, ordered according to their coupling to the organization as a whole. If a role at ordinate position p initiates an interaction with a role at coordinate position q, we put a point at the position (p,q). The point is shaded according to the strength of the interaction. In the above model we can see that there is a dense network of communication between roles. There aren't very many large "holes" in the communication structure of the organization. Compare the above grid with this grid:
This picture tells a tale of a much different management style, one where a few core managers initiate interactions across the rest of the organization. Barring those management-initiated interactions, there just isn't much interaction between roles.
Many of the patterns in this book use these pictures as aids to understanding the context and forces described in the pattern. We describe the diagrams in more detail in the section SocialNetworkTheoryFoundations, and we recommend you take a quick look at that section before exploring the patterns in depth. For more on our research techniques, you can read the entire section HowThePatternsCameToUs.
Many of these patterns come from stories we have picked up on our travels -- stories of real problems in real organizations and the real solutions they applied. Many of our patterns start with what we believe to be a particularly poignant or appropriate selection from among such stories.
Each pattern starts with a picture. The pictures are sometimes fun, sometimes somber, and sometimes thought-provoking. Each one strives to underscore the human dimension of the pattern and to serve as a tool to help remember the pattern.
You will soon see that patterns point to other patterns, not necessarily in the same sequence. One would expect this, since there are many paths through a language. So you may find it more useful to read the patterns in a different order; feel free to do so.
Each pattern is designed to be understandable and applicable in isolation, even though each pattern gains much of its power by reinforcing the patterns around it in the pattern language. When you read the patterns, focus on understanding each on individually: don't worry unduly about the sequence. Allow yourself to get lost, to explore, to play. Of course, if you're a more linear thinker, you may want to follow a specific sequence to order your thoughts; do what is comfortable for you. There are many paths to understanding these patterns.
If you need to get a quick overview of a pattern, just read the text. That gives you the name, the problem it solves, and the solution. For convenience, there is a quick reference summary of the patterns at the end of the book; they are called "patlets." In the patlets, the problem and solution are distilled into a single sentence. Therefore, they are best used as a reference; as a reminder of what each pattern is about.
Whatever order you read the patterns in, you will find some patterns that seem particularly relevant to your organization. Some will jump out at you, and you will say to yourself, "Now here's a pattern that our organization can really use." So mark them with a little yellow sticky note. One or more of these will probably become your organization's entry into the pattern language. Note the wording above: the patterns you mark must be not only helpful, but feasible in your situation.