--- title: Team Distribution Models and Conways Law url: https://www.grahambrooks.com/post/2014-03-31-team-distribution-models/ date: 2014-03-31T00:00:00+00:00 author: Graham Brooks tags: - Agile - architecture --- # Team Distribution Models and Conways Law If Conway's law applies the how we set up and organise teams should either be aligned to the architecture of the applicaiton or system being developed or application/system architecture will shift to match the team structure. ## Conways law > organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations Conway, Melvin E. (April 1968), "How do Committees Invent?", Datamation 14 (5): 28–31, retrieved 2009-04-05 > Conway's law is an adage named after computer programmer Melvin > Conway, who introduced the idea in 1968; it was first dubbed Conway's > law by participants at the 1968 National Symposium on Modular > Programming.[1] It states that organizations which design > systems ... are constrained to produce designs which are copies of the > communication structures of these organizations How can team members be separated and how does this affect daily working life? ## Degrees of separation
Distance
Two people do not need to be far apart before the separation challenges our usual informal communication channels. Separate rooms or buildings within the same location can produce similar symptoms of disconnect to much greater distances.
Overlap
Time zones and different working arrangements mean that overlapping work time can be reduced. In extreme cases there may be no overlapping 'normal' work time. These factors affect the way the individuals interact. Individual motivation to communicate and coordinate are the key to compensating for the differences between co-located and non co-located working. Tools can improve the communication but they cannot compensate for the lack of motivation.
### Assumptions There is a basic assumption that everyone is motivated to deliver the project responsibilities. ### Risks * Team members become disengaged * Effort is wasted because key information has not been shared sufficiently. ## Co-location ![Same room co-location](https://www.grahambrooks.com/images/team-distribution/same-room-co-location.png) Colocation is the default arrangement for agile teams. All the project participants occupy the same space and typically the same table. This 'Same room' option delivers high levels of collaboration and very low ceremony. Communication is very easy and it is easy to self organise around solving problems. ![Same building co-location](https://www.grahambrooks.com/images/team-distribution/same-building-co-location.png) Sometimes it is difficult to occupy the same space. Often product owners and other stakeholders have other responsibilities which make it difficult to occupy the same space as the delivery team or their work might require higher levels of privacy. Often the entire team is in the same building. Meetings and discussions within the team are still very high bandwidth but meetings and discussions with the stakeholders out of the team room requires more work and coordination. ## Multi-location ![Multiple locations](https://www.grahambrooks.com/images/team-distribution/multi-location.png) In this model teams and perhaps team rooms are set up in multiple locations. Each team has a full compliment of skills (except for stakeholders like the product owner). ### Bridgehead ![same building co-location](https://www.grahambrooks.com/images/team-distribution/same-building-co-location.png) Logically the bridghead model is very similar to the same building model. In many cases it operates in the same way. Business and business requirements are communicated from the product owner and other stakeholders via an intermediary (typically a business analyst) to the delivery team. This is a popular off-shoring model. People from the offshore development center travel to the buisiness owner's office and work remotely from the delivery team. People may work on rotation, traveling to the product owner for some months and then 'rotating' back to work with the team while another team member joins the product owner in their location. In this model the internal design of the system is still (predominantly) done in a single location. In this case at the offshore development center. Often there is a very strong sense of ownership for the internal architecture and quality of the system. The offshore team has very little insight into how the sysem is being used. The product feedback cycle is much more difficult and providing a high fitness for purpose is difficult without constant attention to detail and high bandwidth communication and frequent rotation. ### Scattered ![fully distributed](https://www.grahambrooks.com/images/team-distribution/fully-distributed.png) This model is interesting from a number of perspectives and is the complete antitheses of the same-room co-located team. And yet open-source project teams are often cited as an example of where this model has been proven to be effective. Conway's law might indicate that in a fully scattered or distributed arrangement with all communication lines being electronic that the developing system would be made up of many systems perhaps even one per team member or developer. A counter view might be that because no two team members have a preferential status with respect to communication that the team is actually most reflects the co-located team but with less efficient group communications. ## Temporal distribution Working in a team separated into different time-zones adds an additional complication. One of the key elements to effective communication is availability. With other team members spread around the globe finding group collaboration times becomes more difficult and topics of conversation have to be stored up until it is convenient to share in conversation. Asynchronous/written communication is a common fallback but the depth of exchange is limited and requires more effort.