Team culture and software architecture have this in common: once the basic patterns have been established in each, it is relatively hard to change them, even though, at the same time, incremental change is a necessary part of their growth.

To set the stage, here are some examples of hard-to-change team patterns I have recently experienced:

• Rigid individualized work schedules. Strict nine-to-fivers would have little to do with fitting their schedules to the conditions and priorities on the ground and to the rest of the team.
• Team division into engineering and product management. The lowest common manager was high up in the management chain. So differences between the groups could not be resolved quickly and amicably by escalation to an engaged team lead.

Coplien and Harrison report in their book Organizational Patterns of Agile Software Development that the decomposition of team functions into roles, and the endowment of responsibility and authority to these roles, tends to get quite ingrained early on, and to remain relatively stable for long periods of time.

A similar tension between established patterns and change exists in software architecture. There are design decisions that are hard to change incrementally: the basic layering stack and the associated layering design patterns of a web application, for example. It is important at least to try to get such decisions right early on, even as we recognize that we may fail, and that the decisions will evolve over time.

The duality between establishing sustainable patterns and welcoming change is a fact of life. Different trends and methodologies tend to emphasize one or the other pole in this duality. In fact, both poles are important. And for each pole there is an obvious take-away.

First, because changing established norms often requires a major effort, the team culture should encourage extensive initial due diligence in setting cultural ground rules and in basic architectural design.

Second, because requirements and external conditions can change, and because our established norms may turn out to be wrong after all even for the conditions for which they were designed, the culture should encourage systematic incremental change over time.

There is nothing new nor I hope controversial here. And yet, it is not uncommon for teams to miss one or the other of these basic themes in team culture or in system architecture. I believe that the recognition of this duality and its simple consequences is fundamental to the development culture.

In establishing an initial team culture and in its incremental improvement, there are two dysfunctional extremes of leadership: command and control and laissez-faire. In a command and control regime, management decrees, and the troops are expected to follow. The shortcomings of this regime in terms of hindering innovation and lowering team morale are well-known. At the other extreme is laissez-faire: You throw a bunch of people together in a team and leave them to their own devices to evolve, with little leadership. Unfortunately what you may end up with is a Survivor culture, where political manipulation rules.

In both these extremes, standards end up being established without a serious opportunity for critical evaluation.

Even though the shortcomings of these approaches are well-known, development organizations in which elements of these extremes are palpable and sometimes even dominant are not uncommon.

Fortunately, autocratic command and control is considered politically incorrect nowadays, although management railroading with token nods to rank and file opinion is not that rare. Far more common these days is laissez-faire, disguised in the positive spin of self-organization. Of course, self-organization is a good thing, as long as leadership is exercised to keep it fair and amicable.

My bias is for a process of initial and incremental due diligence which may be called deliberative cultural evolution, meaning that to the extent possible, the culture would be driven by conscious deliberation. This type of due diligence has been talked about for years by people like Alistair Cockburn (see, for example, the techniques of methodology shaping and reflective workshop in Crystal Clear, A Human-Powered Methodology for Small Teams). At its best, deliberative cultural evolution allows everyone’s collective experience to be molded into a coherent and accepted set of norms of behavior in the team, with proper respect for all opinions, but with enlightened deference to experience and accomplishment. It takes skilled leadership to keep this process on track.

Too often in my experience, the team is so excited, or pressured, by the challenges of the work at hand, that it fails to treat the establishment and evolution of its culture deliberately, until it is too late. At other times, teams buy into particular popular methodologies of the day without much discussion. Far better, I think, is to be prepared to learn from all great traditions of development teamwork, and to make conscious collaborative decisions on patterns of culture.

© Copyright 2006 Bolour Computing.