Skip to main content

Local Proximity of Team Members

Context​

Microservices are being adopted. Each microservice is managed by exactly one team. The microservice teams themselves might be geo-distributed.

Problem​

  • Communication and coordination within a microservice team does not work well
    • Different time zones might make findings slots for video conferences difficult
    • The geo-distribution leads to remote-only communication

Solution​

Co-locate the members of a microservice team to one location.

Being co-located allows in person work, or at least remote work in the same time zone. The shorter communication pathways will improve the efficiency of the microservice team.

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

L43:

  • Table 2: personnel factors: distributed or geographically distant teams
  • Case study: geographically distributed team
    • effectiveness made possible thru tools
    • esp. geographically diverse programming supported by GitHub

LN39:

  • Cutting services based on geography
    • legal, commercial, cultural reasons
    • interpretation: teams per microservice => implies geographic proximity

LN43:

  • Context: reason to split up their monolith
  • among others: team structure
    • if teams located in different geographical areas => communication is very slow
    • => makes sense that they take ownership of different parts of the code
    • eases up development as teams in different geographical areas do not have conflicts about modifying parts of software
  • Context: when better use monolith
    • among others: when communication is easy and teams are close to each other geographically

Interview F:

  • Context: Coordination with suppliers
  • their own teams in the same company were distributed
    • solved by video calls
    • tried to solve it by cutting teams in a way that they are within one location
    • => so that a team was not distributed across locations