Conway’s Law

It’s crucial to divide up work to optimize the primary business goal.

Here we see how hard it is with individuals — it’s even harder with teams.

... things had been working well as everyone just did what was needed to be done out of pure passion, so seamlessly that an observer might conclude that everyone had the ability to read each other’s mind. However, growth and increased contextualization around both the product and the team beg some kind of structure to help things run smoothly as the organization matures. You are seeking an organizational structure that will optimize the team’s ability to get things done to create the Greatest Value.

✥       ✥       ✥ 

Effective communication and feedback are at the heart of effective complex system development, and the organization structure should be optimized for the most crucial paths of communication. Communication and feedback, together with self-organization, are the agile heart. We find that the interaction of people with diverse, cross-cutting concerns lies at the heart of innovation. [1]

Development Teams working on complex product continuously struggle with the dual nature of function and form. We tend to create boundaries between development activities and organizational units along these lines. Yet function and form are just socially constructed and somewhat arbitrary categories: reliability might be just as compelling a concern for a given system, while beauty, backwards compatibility, or some other concern might dominate a given development effort. In each case, the business will best be served if the Development Team organizes itself around that concern.

As your team just starts to mature in its early days and starts moving towards building a Scrum Team, you have more people who can conveniently work as one organizational unit to cover all the functions of a business (release planning, development, and professional growth). Growth and maturity have caused discomfort and you yearn for the unstructured effectiveness of the simple days of informal work. Yet to grow, and to properly manage the product in the market, requires the discipline that accompanies some organizational structuring and at least lightweight governance.

Cultures have an intrinsic need for structure for the efficient functioning of the whole. The most effective communication always happens locally within the realm of the familiar, so it’s crucial to localize the decision-making process about the most crucial organizational concerns. It’s important in any non-trivial social organization that people quickly be able to associate any given domain of interest with the most efficient “place to go” when information is needed or when action is required in that area.

A simple partitioning (i.e. a hierarchy) is adequate in simple domains that must deal with only one set of separable concerns, but is inadequate in a more typical system with overlapping concerns. This pushes toward larger more, complex organizational units. Yet the most effective units are Small Teams, and you need to partition the work somehow.

However, no team is an island, and a development nation is more than a collection of islands. Teams collectively develop their own identity, where a natural sense of xenophobia (need for the familiar) causes teams to give only secondary stature to concerns coming from outside their social circle. If you limit the enterprise to one set of social interactions, based on a single simple partitioning, you shut down the out-of-bounds ideas that fuel innovation.

The speed of decision-making is of primary concern. Some sets of decisions must be made quickly (“we are being attacked by another tribe and must mount a defense against them”) while others, though important, tolerate or even beg longer deliberation (“what is the best location for the new meeting hall?”) (These layers are sometimes called shearing layers, after the notion of tectonic plates that move across each other, as leading up to an earthquake. The term has been adopted by architects [2] as well as in software [3] to describe structures of different rates of change in a tightly coupled system.) Organizations should be structured to quickly respond to issues in the first category without destroying the ability to respond to questions in the second.

Another agile principle is that we are outward facing: that is, that our focus and concern are on the end user, market, and customers rather than on the tools and technologies we use to do our work. The organization should reflect this concern as well, as it’s key to the value proposition and the construction of the entire Value Stream of development.

In the end, the structure of the organization should have as much to do with the structure of the process as the structure of the product.


Organize the work force into Small Teams of more or less five people, partitioned according to the most important concerns for the creation of value by the enterprise. Supplement this structure with a small number of cross-cutting structures for secondary but important concerns, never forgetting that these structures are only optimizations in what is otherwise an open environment of unconstrained cooperation.

Consider an enterprise that is building a mobile phone. They might organize their Scrum Teams around the major deliverables or purchasable options. So there may be one team for the address book, another for the calendar, and another for the more traditional phone functionality; see Value Area. Those are the primary concerns of the business. But there may be groups that come together to define practices, policies, and corporate standards (e.g., the user interface look and feel), comprising representatives from each team. Those groups don’t build product but serve as information exchanges and a sources of standards that guide development.

In most environments the primary organizing structure reflects the primary stakeholder structure, which is usually the market. For this reason, we don’t organize Scrum Teams along the partitioning of internal artifacts, nor according to the loci of domain expertise, but rather along the lines of market deliverables such as features. Organizing around features or other market deliverables is also a boon to market responsiveness and reduced time-to-market because the feature set moves much faster across the usual shearing layers of the system than do other concerns, such as the historic structure around core competencies.

For this to work, it must be supplemented by cross-cutting structures that support a second level of communication efficiency: e.g., those related to the core competencies. So this pattern almost always appears together with a pattern like Birds of a Feather and Domain Expertise in Roles. The organizational role structure cuts through the walls that naturally form between teams. Engage products within an enterprise with each other and with executive management with the MetaScrum. There should be a degree of Team Pride or other force that encourages responsibility, to help ensure that these structures remain in play in spite of the xenophobic effects of team membership.

Tie it all together with an open environment with no walls and no doors. Development Teams are units only of development commitment, and there should be no interference limiting the free interworking between developers across teams.

Any component of value is fair game for use as an organizing criterion. For example, Scrum highly values the collocation of team members, so the most basic organizational boundaries are likely to correspond to Collocated Teams.

✥       ✥       ✥ 

Note that there are two levels of Conway’s Law in Scrum. At the surface level we organize the team according to the process: that is the primary concern for both the inward- and outward-facing aspects of process. So the three spheres of process dominion are:

Scrum Development Teams are feature teams. That is, the primary organizing principle of Scrum Team aligns with successive feature deliveries along Value Streams. There is a weak, shallow hierarchical organization within Scrum that accommodates multiple Development Teams within each product development, sharing a common Product Owner, in an organization called a Scrum of Scrums. Each Development Team within a single product development builds one set of features at a time, and these features over time are tied together by the key business concerns, knowledge, and objects of the Value Stream. There are no recognized titles or subdivisions within the Development Team.

There are many ways to divide work into feature teams. A Development Team may deliver features to a given market (Organization Follows Market), or develop product for some subset of the enterprise technology spectrum (one team for phones and another for tablets, though both share much of the same software). In general, each team should be formed around some product that accounts for a component of enterprise value. See also Value Stream Fork. However, Scrum discourages a Development Team structure that maps onto parts of the product, or product subassemblies, as that leads to handoffs and delays feedback.

At the second level of Conway’s Law within Scrum, individuals channel their innate desire to improve [4] into an area of specialization for which they can develop deep familiarity and for which they can bear the corresponding pride of being able to contribute; see Domain Expertise in Roles.

Development Team boundaries, and identity, as well as Scrum Team boundaries and identity, are explicit. The notion of identity is key to Team Pride and to the efficient operation of the organization, since identity brings the social context that helps optimize decision-making. All identities beyond these two should be tacit rather than explicit or administered. Again, there are no formal titles within the Development Team other than “Developer.” If there is only one inviolate rule, it’s that no individual can use their tacit station of expertise to override a team consensus nor in any other way diminish a spirit of teamwork; see The Spirit of the Game.

There can be expertise in roles at the individual level, but it’s important to complete this pattern with Cross-Functional Teams wherever possible to optimize local decision-making.

The original Conway’s Law came out of software. [5] There are many myths associated with the origin and practice of Conway’s Law. It was long held that object orientation supported Conway’s Law by localizing market concerns inside of classes. That’s half-true: classes tend to encapsulate the long-term concerns of organizational core competency. Yet object orientation has in fact not proven its responsiveness to the emergence of new market use cases. Concerns for alignment with market structure should trump concerns for the developers’ worldview of their process and product.

The waterfall style of development had its heyday. In waterfall organizations, the primary organizational structure followed process stages: requirements analysis, design, implementation, and test. [6] Per Conway’s Law, the organization was divided according to those process concerns. The software might very well reflect those phases as well: for example, a Service-Oriented Architecture (SOA) will evidence most of the value-added requirements in the service integration layer, while the individual services are found in another layer. Waterfall puts all the features into the developers’ hands at once, which supports reasoning about interactions between features. While the design approaches of the waterfall era ended to bring the market concerns (use cases) in line with the architecture, the organizational structure cut across that taxonomy.

Because Development Teams are feature teams, they tend to focus on one feature at a time (as in Swarming). Scrum’s primary market deliverable is a feature, and in this sense, there is good alignment between the team structure and the market. Scrum is silent on the form of the product architecture, but in the spirit of agile it tends to discourage individual code ownership. Every Development Team has license to modify any part of the product. Scrum therefore can be said to balance the organizational benefits of encapsulation with the benefits of team alignment with the market deliverable. The emphasis for interactions between features (over time) is vested primarily in the Product Owner role, with support from Developers.

Consider, for example, that one team may implement the Call Waiting feature for a telecom system while another implements Call Forwarding. Because of emergence you can’t always foresee the cost of dependencies between any two given PBIs so it is in general impossible to overcome this problem by assigning PBIs to teams; in any case, such pre-assignment creates an over-constrained problem and limits self-organization at the Scrum Team level. The two features have intense dependencies between them, but the Scrum structure doesn’t give first-class stature to those interactions. A good Scrum Team strives to partition the work across Development Teams through intimate, but time-boxed, interactions between the Product Owner and the Development Team, as in events to continually re-establish a Refined Product Backlog and through Sprint Planning.

The Scrum ethos tends to focus on the people and the product, and the focus is embodied in the Scrum roles and the organizations (like the Development Team and Product Owner Team) that they represent. If Scrum is introduced into an organization with pre-existing managers, it is too easy for the Scrum effort to view the management part of the organization as other-worldly. In such situations where a management-free organization is not an option, it is crucial to Involve the Managers.

[1] Steven Johnson. Where Good Ideas Come From. New York: Riverhead Trade, 2011.
[2] Stewart Brand. How Buildings Learn: What Happens After They’re Built. New York: Penguin, 1995.
[3] Brian Foote and Joseph Yoder. “Big Ball of Mud.” In Neil Harrison et al., ed., Pattern Languages of Program Design 4. London: Pearson, 2000.
[4] Daniel Pink. Drive: The amazing truth about what motivates us. New York: Riverhead Books, 2011.
[5] Melvin E. Conway. “How do committees invent?” In Datamation 14(4), April, 1968, pp. 28-31.
[6] Dr. Winston W. Royce. “Managing the Development of Large Software Systems.” In Proceedings IEEE WESCON, August 1970, pp. 1-9. (Originally published by TRW.)

Picture from: