Conway's Law and the Death of Agile

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. —  Melvin E. Conway

This is Conway's Law, first introduced to the world in 1967. And, like many "natural laws," it's almost tautological. A system will have components, and those components will need to exchange data, or "communicate." The components will need to be built, and in an existing organization, the existing teams will build them. The teams will then build components that they understand, and what data will they exchange? That will mirror the communication between the teams. So, in the end, the organization builds a system that copies its own communication structure.

In retrospect, one might wonder how it could be any other way?

It is, however, a real problem.

The Death of Agile

People often proclaim the dramatic death of systems and principles. I've seen reports of the death of waterfall, C, C++, and Java. I can assure you that all of these things are more durable than zombie vampires, and I'm quite sure that they'll all survive me.

But that's not the kind of death that agile suffers. I am not forecasting the death of agile as a principle or a practice in general. The Twelve Principles of Agile Software Development are common sense applied to the development of software. However, within enterprise environments, agile initiatives die the death of 1000 cuts every day.

The Barrier of Conway's Law

As often as not, these 1000 cuts are from the razor wire fencing off organizational boundaries, which is why we're also discussing Conway's Law.

Let's consider the Agile Principles more closely. The first one states "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." Sounds good. The sixth principle is "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." Generally true. Putting those together, one could surmise that the best way to get a development team to deliver results for the customer is for the team to have periodic, face-to-face conversations with the customer. Perfect.

But most organizations won't let this happen, and they have reasons. Developers won't build good things. Designers won't design the right things. Developers don't have good communication skills. Customers won't understand what they need to ask for, and on and on. These are imaginary problems raised by people protecting their turf.


Unfortunately, with the trappings of a Scaled Agile framework, many organizations believe they're agile, when they're actually implementing inflexibility one sprint at a time.

Real agility comes from opening lines of communication, so that quick prototypes can emerge and rapid iterations can evolve prototypes into robust solutions. Robust solutions then free up resources to allow the process to restart.

It is the responsibility of leadership to clear the fences that restrict communication and to enable true organizational agility.