From the course: Agile Software Development: Remote Teams

Conway's Law: Building a strong communication foundation

From the course: Agile Software Development: Remote Teams

Start my 1-month free trial

Conway's Law: Building a strong communication foundation

“

- Communication is the glue that holds an organization together. It's your foundation and it's easy to take for granted, but don't overlook it, because implementing the right communication infrastructure is the starting point for your success, especially for distributed teams. Several years ago, I was at a conference, and I learned about a rather obscure systems theory called Conway's law. It was one of these flashbulb moments that completely changed the way I worked for the better. A few years later, I started a podcast where I interviewed industry experts about software modernization. Guess what comes up in almost every episode? That's right, Conway's law. So what is Conway's law? In the 1960s, Mel Conway published a paper titled How Do Committees Invent, where he explained how organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. First, you'll notice just how essential communication is to Conway's law. How you structure your communication will determine your output. It's a causal link. So if you want your work product to be flexible, modular, and easier to work with, you'll first need to be intentional about how your team communicates. Let's look at an example. Team A works in a traditional co-located office. They are organized in seemingly logical groups. The business team plans out what features need to be built using tools like Gantt charts and big requirements documents. Design, development, and testing are separate teams and don't interact very often. Upper management and executives feel like they're in control, but often the products they produce are late, overbudget, and incredibly difficult to change. Contrast this to Team B, which is fully distributive. All members work in different locations and keep a different set of hours. The management structure is more informal, and there's a diverse group of people who come in and out as the project requires. Teams self organize rather than looking at on org chart. Even the requirements aren't formally stated. Rather, the team relies on emergent design principles, because coordinating and planning tasks in such a distributed fashion quickly becomes a logistical nightmare. Now, let's look at the output of each of these teams. Research shows that Conway's law holds and that Team A's software will mirror their communication infrastructure. The code it produces will be tightly coupled and rigid. It will be very difficult to change, and it will very likely be a monolithic architecture. Team B's code will be much more modular and flexible, because that's the way their communication is set up. If something in the code base needs to change, it will be much easier. The system overall is much more nimble, adaptable, and flexible, why? Conway's law states it's because of the communication infrastructure that was used to build it.

Contents