Duchess
Globally Connecting Women in Java Technology

Introduction
In my quest to grow up to be an architect I came by the book ‘Organizational Patterns of Agile Software Development’ by James O. Coplien and Neil B. Harrison. It had the words Agile and Organization in it, so it seemed to offer some advice on how to turn your organization into an agile entity. Sitting on the bench, waiting for a book about Wicket to come in, I had some spare time and started reading it. And thus I found out that it really was what it promised.

I History and introduction
It started off with exploring what a pattern and a pattern language is. Their conclusion was that to understand a pattern, you’d need to know what a pattern language is, and to know what a pattern language is, you need to know what a pattern is. Indeed, recursion. And so they set off with an incomplete definition of a pattern as a configuration rule that contributes to the overall structure of a system and that works together with other patterns to create emergent structure and behavior. A pattern language is then defined to contain patterns and rules to combine those patterns in a meaningful way. In a pattern language, patterns can be combined in many different ways depending on context. An organizational pattern language is usually though of as describing the architecture of an organization. In this book they describe four different pattern languages, which will usually be used in parallel: Project Management, Piecemeal Growth, Organizational Style, and People And Code. The rest of part one talks about how they came to the patterns and how to use the book, which I will not go into in this review. Suffice it to say that they did a lot of research and have a lot of experience.

II The pattern languages
Part two explores the actual patterns in the pattern languages. Some of the patterns could be in several of the pattern languages, and where this was the case they have described it in the language where it most seemed to fit and put a reference in the other language(s). The four languages are split up into two groups: Organizational Design Patterns and Organization Construction Patterns. The first group is about the architecture, the relationships between the parts. The second group is about the daily reality of building an organization. Project Management and Piecemeal Growth fall into the first group and Organizational Style and People and Code fall into the second.

Project Management is all about the organizational aspects of managing projects. There are 26 patterns in this language. Some samples of these are mentioned below. The explaining text is in the shape of what they call patlets, which is a short summary of the problem and solution for a pattern. The text from the patlets is taken from the appendix.
Take no small slips
If you are getting behind schedule and you need additional time resources, Then: take one large planned slip instead of creating project instability and low team morale with small, unanticipated slips.
Developer controls process
If you need to orchestrate the activities of a given location or feature, Then: put the Developer role in control of the succession of activities.
Someone always makes progress
If distraction constantly interrupt your team’s progress, Then: whatever happens, ensure someone keeps moving toward your primary goal.

Piecemeal Growth of the organization is all about the ways in which an organization grows and develops over time. There are 32 patterns in this language. Here are some samples.
Size the organization
If an organization is too large, communications break down, and if it is too small, it can’t achieve its goals or easily overcome the difficulties of adding more people. Therefore, start projects with a critical mass of about 10 people.
Self-selecting team
If you appoint people to a team, the people don’t come together as a team. People who share similar outside interests make the best team members. Therefore, teams should be largely self-selecting, performing limited screening of candidates based on their track record and outside interests.
Developing in pairs
If you want to improve the effectiveness of individual developers, Then: have people develop in pairs.

Organizational style is about the general approach to the way the organization works. There are 23 patterns in this language. Here are some samples.
Few roles
If your organization has high communication overhead and latency, Then: identify the roles in the organization and reduce the number of roles to 16 or fewer.
Producers in the middle
If your developers are somewhat lost, Then: make sure the producer roles are at the center of all communication.
Face to face before working remotely
If a project is divided geographically, Then: begin the project by inviting everyone to a meeting at a single place.

People and code is about the ways in which people affect code, and the ways in which the design of code affects people. There are 23 patterns in this language. Here are some samples.
Stand-up meeting
If there are pockets of misinformation or if people are out of the loop, Then: hold short daily meetings to socialize emerging developments.
Architect also implements
If an architect is in an ivory tower, he or she is out of touch with reality; yet someone needs to reconcile the high-level overview with practice. Therefore, ensure that the architect is materially involved in day-to-day implementation.
Standards linking locations
If development is separated geographically, Then: use standards to link parts of the architecture that cross geographic boundaries.

III Foundations and history
Then in part three, they investigate the principles behind organizational structure. First they explain the organization principles. Not every organization is ready for change. Dissonance often goes ahead of a resolution. This can take the shape of a team burnout, where a team feels that everything is better than the current situation. But burnout can also work against change, as the team simply tries to solve things by working harder and closing up to the outside world. But no change can take place as long as there is no open communication. Team-building excersises might be a way of bringing back trust to the organization and getting them to open up to change again. The best way to change an organization is to start with the healthiest team and go step by step. Introducing one pattern at a time. If a change doesn’t work, you should back out and try something else. So in order to change an organization, you need it to be stable. If it is ever in flux, you can’t see the results of the changes you make.
Not every pattern works for every team. Keep in mind that the patterns are meant as inspiration, to be adapted to fit the organization in question, with a little tweak a pattern might fit your team a lot better. Then there is also the issue that not every pattern can be executed by everyone, some are for developers, others are for managers. But all of them work on groups of people, not individuals. And the last point, which is mostly aimed at managers, is that people are inpredictable. It is mostly useless to determine a path through the patterns in advance. Simply go one step at a time, see what change it brings and then determine the next pattern to try.
The second chapter in part three looks at the anthropological foundations. Here the authors point to research that states that there are three kinds of learning: single loop learning, which is about changing the process, the how of things; double loop learning, which is about changes in insight, the why of things; and triple loop learning, which is about changing identity, who we are. Most organizations focus on single loop learning and process. But process alone does not suffice as software development is still not predictable enough. Organizations that focus on product function a lot better than those who focus on process, as the structural elements of the product will reflect itself in the structure of the organization. Focusing on process work only in a mature domain with predictable steps. In fact process must emerge from the structures of communication and production beneath it. Those structures, in turn, are held in place by the values of the organization. So why focus on roles instead of process. Roles define what is done, which is more stable than how it is done. And second, people identify with roles.

IV Case studies & Apendices
The fourth part of the book goes into some case studies, and shows how the patterns were at work there. Then in the appendix they give a nice summary of all the patterns (the above mentioned patlets).

Conclusion
Not all the patterns are equally clear to me, because sometimes two to three pages of description is just too short. But it is still a very good book. In fact every manager should read this book. It gives a lot of insight in how organizations and people work. It is also a very good read for everybody who is dissatisfied with the way their organization works, but who have no idea what to do about it.