Melvin Conway introduced an idea in 1968:
…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
Think about your product and it’s strengths and weaknesses. Can these strengths and weaknesses be mapped to the strengths and weaknesses of the communication paths in your organization? Component-based teams and human relationships are at the core of this idea.
- Component A talks with component B and component C. Component B is developed by people in the same room and component C is developed by people on a different continent.
- Component C talks with component D and component E. Component C and D teams don’t play well in the same sandbox. Lots of friction, distrust, and finger pointing happens between these two component teams. Component C and component E teams play softball together every week.
- Can you identify the strong and robust interfaces in your system? Who built them? Where are the two teams located and how well do they know each other? Same question for the brittle and weak interfaces.
- Are your teams making product design decisions based on which teams they would rather work with?
There are two key issues. The first is how you organize teams. The second is the behaviour behind teams’ willingness to collaborate. Each of these if not handled well can kill your productivity and your product quality. As a manager, are you dealing with it? Are you bringing the issue to the surface and putting it in front of those who can make the necessary changes happen? This is a real impediment. Not dealing with it weakens your product and the value delivered to your customers. The advantage of Agile Scrum teams is that you put the people needed to build something end to end in a single team, or a collection of highly collaborative teams in a Scrum of Scrums.
There is significant research to support Conway’s Law. Check out this paper from the Harvard Business School. It takes similar closed-source and open-source projects where the organizations are radically different and applies DSM analysis to compare the impacts to product architecture modularity. Another study from Microsoft Research looks at failure-proneness of software and its correlation to the organizational structure. You can get the paper here.
Applying DSM is a good way to start to understand how your product’s architecture is influenced by your organizational structure. Above all, don’t ignore the importance of Conway’s Law on your organization’s and your product’s quality and performance.