#2782

Agile 2008 – Conway’s Law and Distributed Teams

During the distributed agile workshop at Agile 2008 there was some discussion of Conway’s Law (named after Melvin Conway). Conway’s law basically says

Any piece of software reflects the organizational structure that produced it.

So distributing your team not only effects its communication dynamics adds dysfunction, it also may impact the actual product that gets developed!

On the one hand you could plan for Conway’s law and distribute the work on your team based around architectural components. Do you really want the architecture of your application to reflect that fact that you decided to hire two great developers who work remotely in Kalamazoo? Users care about features and how they fit together to satisfy user stories. They want your architecture enable the features they care about in the current version of the product and subsequent versions.

Often teams think they can avoid Conway’s law by aligning by discipline. You frequently hear of off shore test or developer teams. While this seems to get us off the hook with Conway it presents more problems. Agile teams blur the lines between the traditional roles on a development team for good reason. Subdividing teams by function leads to throwing code over the wall between disciplines and them-and-us attitudes. The whole team is no longer on the hook for delivering a user feature.

This will also tend to lead to specialization as different geographical locations are aligned to architectural components and over time specialize in that component. Over time users stories will get harder to complete within an iteration as different parts of the team have to align on a critical path to complete a given cross-component user story.

In some ways this produces the same result as distribution by component or function results in the same thing. The team is misaligned around something that ultimately doesn’t matter to the user, architectural components or functional discipline. Agile teams align their efforts around user stories because that’s what users care about.

Alternatively you could fight Conway’s law at every turn. For small distributed teams this means behaving like a co-located team and removing as many of the communications barriers as possible so that the team aligns around user stories. Team members pick tasks off the iteration backlog and iterations are based on stories from the product backlog.

For larger scale projects a feature crew or feature team approach addresses Conway’s law head on in a similar fashion. Bas Vodde’s book also covers in great detail how a component based approach leads to waterfall and makes it harder to deliver complete functionality in a single iteration.