The Open Closed Principle Of Teams

Change is disruptive, yet most people adapt to new situations extremely well. However, change is more disruptive to teams than to individuals, because there is an additive effect of the disruption to the individual members of the team. When change violates the Open/Closed Principle of Teams, the team may be ready for positive change with these patterns.

Or not. Read on.

Bertrand Meyer teaches a rule of object-oriented design called the open/closed principle [BibRef-Meyer2000]. It combines two ideas:

• • that a class should be closed so that other classes don't come to be preoccupied with or otherwise depend on its internals

  • that a class should be open to extension by inheritance, so it can evolve into a new entity with both new structure and behavior.

Team evolution is the same way. If a team does not have final say over its membership (SelfSelectingTeam), focus (TeamPerTask), and direction, resentment will build and the team will lose its sense of identity. Teams of course must sometimes negotiate with other individuals and organizations and sometimes must compromise, but as a rule teams should conduct their own business.

This is why ConwaysLaw is such a key pattern in two of the pattern languages in this book. Teams and groups are built around domains of specialization and expertise. And teams are staffed with the people who can serve that discipline (DomainExpertiseInRoles). Meddling from the outside only detracts from the team's focus.

So a team enjoys some autonomy in reaching a healthy steady state. But what about dealing with growth and dysfunction? And how about dealing with change? The outside world is always changing: the market, the technology, everything! The team must be open to external communication.

We can talk about this openness at two levels. As the software evolves, the architecture inevitably evolves and the teams must align their software to track architectural creep. (Actually, each team's software causes the collective architectural creep, but from the perspective of any single team it appears as though it is the rest of the world that is changing things out from underneath them.) So though the team is closed to meddling with the invariants related to its core competencies, it must be open to changes in interactions with other parts of the system. Such architectural changes may change the organization's communication network.

For example, let's say that you're working on a telephone switching system and your company is incorporating a new integrated circuit to accommodate market demand for a new protocol. The expertise about that chip resides in the heads of some people somewhere, and if you are going to be developing software that interfaces with that chip you're going to be talking to those people. Conway runs rampant in dynamic projects.

That's a simple example based on software change. Organizational change can be much more subtle. Technological change (like adding the new integrated circuit) doesn't hit people very deep with respect to their averseness to change. Organizational change, on the other hand, can be a strong threat. It can make people feel that their power base is threatened if they are made to report to a new manager. It can make people feel their job security is challenged if a new person is hired into the same area of specialty.

Empowerment

Sometimes the best laid plans of mice and men go astray. In complex systems such as human organizations, cause and effect can be far from each other in time and space [BibRef-Senge1990, p. 63]:

... a fundamental characteristic of complex human systems ... [is that] "cause" and "effect" are not close in time and space. By "effects," I mean the obvious symptoms that indicate that there are problems--drug abuse, unemployment, starving children, falling orders, and sagging profits. By "cause" I mean the interaction of the underlying system that is most responsible for generating the symptoms, and which, if recognized, could lead to changes producing lasting improvement. Why is this a problem? Because most of us assume they are--most of us assume, most of the time, that cause and effect are close in time and space.

Introducing an empowerment program is supposed to increase the energy level, to remove constraints that will free people to do what the enterprise needs to have done, and to give people a sense of control over their destiny.

Think about this from the perspective of the open-closed principle. Empowerment increases the degree of closedness of a team. Giving a team autonomy might cause the team to weaken its interactions with important stakeholders and with sources of information and constraints that are important to the successful operation of the team. Empowerment might be particularly effective in diluting information exchanges with roles that exercise control in general, and with management in particular. In theory, this might create problems with respect to the open closed principle. Unfortunately, that is exactly what we find in practice. We have seen this in some of our organizational studies, but there is also research from Rutgers that concludes that this is a general outcome of empowerment programs [BibRef-Yates1995].

Empowerment is an attempt to achieve an effect (increasing individual leverage) by directly attacking its cause (the "distractions" of coupling and communication that "get in the way of work"). But this is not a system view; the solution cuts off the very nurturing that may have powered the team to its level of performance in the first place. Empowerment is a possible contributor to burnout.

Schismogenesis

We have also seen a lighter but almost equally deadly form of this phenomenon which we describe as schismogenesis. The term dates back to the work of Gregory Bateson [BibRef-Bateson1958] in 1936 in his work with tribes along the Sepik River in New Guinea. Symmetrical schismogenesis occurs when two factions each rise in power, or fear or distrust of each other, and form cliques or splinter groups that tend to focus inward rather than resolve issues in dialogue with each other. This is also a natural outgrowth of efforts to merge separate companies: the separate groups already exist with different values and cultures. The merger, with the spectre of job cuts, sows fear and distrust just at the time the organizations need to learn to work with each other.

Complementary schismogenesis occurs when a stronger side is compelled to actions by its fear of being taken down by a weaker side. We have seen this in organizations under the stress of an impending downsizing program, where the core members of the organization become disconnected from the support arms of the organization. It also occurs in mature organizations, where power structures have become entrenched. This is the main reason for the patterns ResponsibilitiesEngage and HallwayChatter, which came out of an earlier pattern named "Buffalo Mountain" that was designed in part to address schismogenesis. The pattern TheWaterCooler can also help reduce tensions between constituencies by creating a "place" for new social structures that are allowed to violate institutional structures. The HallwayChatter pattern gives an example of an organization exhibiting schismogenesis.

It may be obvious at this point, but such organizations are not candidates for the patterns in this book. To apply the patterns requires dialogue and interaction; that's the "open" part. It also requires focus and a healthy sense of team pride (see UnityOfPurpose). There is of course no black and white here. The balance between open and closed is subjective. It is also true that burnout is a spectrum: of course organizations put in long periods of hard work. But to go more than a month with consistent 60-hour weeks is a real danger sign. Even if the organization is not going into burnout, individual effectiveness and efficiency wears down very quickly after too long of a death march.

Many of the patterns in this book address this issue, keeping the organization vibrant and healthy so that it can adapt to change. A closed organization has difficulty changing effectively. Look at PublicCharacter, who helps information flow efficiently. Or at GateKeeper, who explicitly breaks down walls around the organization, and helps balance the FireWalls pattern. HallwayChatter reflects an informal social infrastructure of both technical and friendly exchanges in the workplace. Even DevelopingInPairs can be a useful pattern for the exchange of ideas and information across groups if the pairing is done across team and organizational boundaries. And of course it's important to keep in contact with the people who pay the bills through patterns like EngageCustomers.