Conway’s Law**

Picture credit: Manu Cornet / www.bonkersworld.net

...things are working well as everyone just does what needs to be done out of pure passion, so seamlessly that an observer might conclude that everyone has the ability to read each other’s mind. However, as the organization and product grow, so does the amount of information that teams must master, manage, and share to get their job done. Decisions are becoming more sensitive to the context (of both the teams and the products), with complexity that begs some kind of structure to keep things running 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 regular feedback, together with self-organization, are the agile heart. The interaction of people with diverse, cross-cutting concerns lies at the heart of innovation ([1]).

Development Teams working on complex products 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 be best served if the Development Team organizes itself around the most crucial business concerns—whatever they may be.

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). But growth and maturity also cause discomfort, as teams 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 a somewhat disciplined organizational structure and some 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 around 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 they need information about that area or need to take action in that area.

A simple organizational partitioning (i.e., a hierarchy) is enough in simple domains that must deal with only one set of separable concerns. But the hierarchical approach breaks down in the more typical case of development efforts with multiple overlapping concerns. This pushes toward larger, more complex organizational units that try to correct the problem with economies of scope. Yet the most effective work teams 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 individually 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 paramount. Some issues are urgent (“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?”). The term shearing layers describes related processes that move at different speeds, after the notion of tectonic plates that move across each other, such as lead up to an earthquake. Both building architects ([2]) and the field of software architecture (see [3]) have adopted the phrase to describe structures or concerns with differing rates of change in a tightly coupled system. A company should structure its organization to be able to quickly respond to issues in the first category without destroying its effectiveness for issues in the second.

Another agile principle is that we are outward facing: that is, 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.

Therefore,

Organize the workforce 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 Scrum Team. Those groups don’t build product but serve as information exchanges and as sources of standards that guide development. In healthy organizations there is nearly complete overlap between the membership of these latter groups and development team membership.

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 team is the locus of all work necessary to implement a feature. This keeps coordination within an organizational boundary. If work subassemblies or core competencies drive the organizational structure, then changes in the market or in the nature of the deliverable will likely entail coordination between multiple teams or organizations—reducing responsiveness and increasing decision-making time.

If this is the only structure, it supports only the market view, and it marginalizes a host of other valid business concerns. For this structure 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 the pattern described in Domain Expertise in Roles. The organizational role structure cuts through the walls that naturally form between teams. Engage product efforts within an enterprise to connect with each other and with executive management through the MetaScrum. Teams that have developed a degree of team pride (see Team Pride) will be more effective, as this or some other equivalent force will encourage responsibility. This helps 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. Add small rooms nearby for short periods of quiet, serious reflection and small meetings.

Any component of value is fair game 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 a good Scrum: one driven by a focus on the product, and another driven by a focus on competency areas. 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 (product) teams. That is, the primary organizing principle of a Scrum Team is that it aligns with a train of feature deliveries along a Value Stream. 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. Over time, key business drivers, shared business knowledge, and Value Stream artifacts will tie these features together. 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 (see 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 where each team owns one part of the product, or just a product subassembly. If the members of any single team can develop only one part of the system, then they will need to coordinate more development decisions with other teams. It becomes hard for teams to make decisions locally, and the results include delayed feedback and handoffs.

At the second level of Conway’s Law within Scrum, people organize around competency areas in which proficiency drives value. These Birds of a Feather help members deepen their facility in some professional or technical area as they share ideas or take training. Most people have an innate desire to improve (see [4]), and these groups feed individual pride as team members learn and grow. But again, these groups do not form a reporting structure, and any team member may belong to several Birds of a Feather as well as to their own Scrum Team. See also Domain Expertise in Roles.

Development Team boundaries, and identity, as well as Scrum Team boundaries and identity, are explicit. The notion of team identity is key to Team Pride and to the efficient operation of the organization, since team identity brings the social context that helps optimize decision-making. Any notion of organizational identity 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 or in any other way diminish a spirit of teamwork, as in The Spirit of the Game. A jointly developed Norms of Conduct is a strong harbinger of team identity.

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 the possibility of local decision-making.

The original Conway’s Law came out of software (see [5], pp. 28–31). 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 seems to focus on the connection between developers’ expertise and the artifacts they develop rather than on any connection to the market or to 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], pp. 1–9). Per Conway’s Law, the organization structure reflected 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 software design approaches of the waterfall era tried to bring market concerns (use cases) in line with the architecture, the organizational structure cut across that taxonomy. The same can be said about assembly-line organization in factories.

Because Development Teams are feature teams, they should 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 work on any part of the product. We can say that Scrum balances the organizational benefits of encapsulation with the benefits of aligning the team with the market deliverable. The Product Owner, with support from the Development Team, manages how to handle feature interactions that emerge over time.

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 resolving dependencies between any two given Product Backlog Items (PBIs) so it is, in general, impossible to overcome this problem by assigning PBIs to teams. In any case, prematurely assigning work to teams may make it impossible for people to work effectively on the hard parts (especially those related to the interaction between the parts) and limits self-organization at the Scrum Team level. The two features may be highly interdependent, but the Scrum structure doesn’t give first-class stature to those interactions. In this case, it probably would be better if a single team developed both features. How to allocate work to teams builds on ongoing planning and shared decision-making, starting with Sprint Planning. 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 as well as through Sprint Planning.

Management is usually a component of the organizational mix, although there are some Scrum developments that run without any managers (e.g., see the recent video about the agile transformation at Bosch Software Innovations. [7]) 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 an organization with pre-existing managers sets out to introduce Scrum, it is too easy for the Scrum effort to dismiss 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 Pattern Languages of Program Design 4, Brian Foote et al., eds. 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.)

[7] Bosch Software Innovations. “Lessons learned: Agile organization at Bosch Software Innovations.” YouTube.com, 15 June 2018, https://www.youtube.com/watch?v=CwodQs7D8BY.


Picture credits: Images Provided by PresenterMedia.com.