通过

Conway’s Law and Agile Projects

  • 项目

Conway's Law states that "Any piece of software reflects the organizational structure that produced it. " Further, Conway's Law is identified as a key pattern in Organizational Patterns of Agile Software Development, stating "Make sure that the organization is compatible with the product architecture". Finally, the relationship between architecture and organization is the key component of the Architecture Business Cycle described in Software Architecture in Practice.

I first came across these ideas several years ago when I was working in another organization. The idea that architecture would influence organization was pretty intuitive to me. The corollary that organization would influence the architecture was not as intuitive. As a matter of fact, it seemed flat out wrong to me. The way that a company is organized shouldn't influence a technical matter as core as a product's architecture.

But then I thought about how we made decisions on the product that I was working on. The product was built on a 'platform' built by another team. The platform released about once a year. The product that I was working on was delivered as a standard package and was used for custom applications, often releasing more than once a year. How we met feature needs for both standard and custom deliveries depended on what we could get from the platform team and when we could get it. If the feature was important and we couldn't get it into the platform due to either priority or timing considerations, then we figured out how to build it within my team's code base. Our organization was driving the technical decisions!

Does Conway's Law still apply when using agile practices? I believe it does - especially for larger product teams like we see at Microsoft. But there is definitely an added degree of coordination in order to meet the agile goal of building a system incrementally where the focus is on end to end scenarios that provide customer value. It can be very difficult to accomplish a scenario within a single iteration if it involves significant development efforts in multiple teams. But enabling the scenario in as short a timeframe as possible is still the goal.

An alternative to Conway's Law would be to iteratively organize around the end to end scenarios. The danger here is that the architecture grows in an ad hoc manner as many different teams and individuals will be mucking in different areas of the system. For example, how would you grow the data access layer functional in a way that architectural integrity would be preserved? I also think that release planning would be difficult from a resource perspective.

So Conway's Law still applies as a best practice for me, even for agile projects. But I would be very interested to hear about its application on agile projects as well as alternatives for organizing large projects that want to be As Agile As Possible.

Comments