Home > Articles > Software Development & Management > Agile

This chapter is from the book

Two Design Principles

When there is more than one team in your organization, things need to be coordinated. Whether it is the choice of logging framework, the location of the refrigerator, or the availability of the demo room, people need to agree on things that are shared across multiple teams.

Psychologist Fred Emery distinguished two basic patterns for coordination of activities across multiple teams. He named them the first design principle and the second design principle.

In the first design principle (DP1), the location of the fridge is determined by people who are positioned one level above the teams. They are either the line managers of the teams or else a dedicated Fridge Manager who is appointed by the line managers. Either way, the teams have no say in the location of the fridge. Only the Fridge Manager is authorized to decide (see Figure 13.5).

Figure 13.5

Figure 13.5 First design principle: a manager coordinates.

In the second design principle (DP2), regulation of the location of the fridge is built into the teams themselves, meaning that the teams take care of coordination across their boundaries. In practice, this means that teams have to negotiate with each other and agree on some rules, such as voting on the location of the fridge, pricing the availability of the fridge, daily fridge rotation, or fridge roulette. The teams may even agree on their own Fridge Manager and bestow authority on her to make decisions for the teams. With DP2, the authority ultimately lies with the teams, not with the line managers (see Figure 13.6). (And then informal emergent leadership inside the team could become a necessity to prevent a consensus culture with endless discussion.)

Figure 13.6

Figure 13.6 Second design principle: The teams coordinate.

The second design principle closely resembles the solution that complexity scientist Stuart Kauffman describes as "patches":

  • Kauffman says break up the organization into patches, yet emphasizes that these patches must interact. This advice is different from the old management standby of the independent, self-sufficient business unit. It is in the nature and quantity of the interactions that Kauffman finds that the organization as a whole can be moved toward a global optimum, even though each patch is acting selfishly. Interactions require language or some other mechanism of fairly continual communication. He stresses that the patches must be coupled. In management jargon, the pieces must communicate, and not just at quarterly review sessions.7

In this analogy, patches are self-organizing teams, not controlled departments. The adaptability of these patches (DP2) compared to hierarchical management (DP1) follows directly from the organic way of problem solving. Every team tries to solve one part of a bigger problem. But because of the couplings between teams, the solution found in one team will change the problem to be solved in adjacent teams. And the adaptive moves of those teams in turn will alter the problems to be solved by other teams. Ultimately, you end up with an ecosystem of teams, or patches, solving a big problem together. [Kauffman 1995:252]

It is clear that the principle of patches (DP2) is the best option for decisions on the choice of logging framework, the location of the refrigerator, the availability of the demo room, or anything else that needs to be coordinated across teams. When some issue needs to be resolved across multiple teams, tell them to coordinate the solution among themselves. DP1 (that's you or some other manager making the decision for them) will only be a viable solution when you realize that DP2 doesn't work well. For example, when competence issues have not been resolved yet.

  • + Share This
  • 🔖 Save To Your Account