Schedule routine face-to-face communication

Most problems with multi-site development are not technical; they’re interpersonal communication problems. Geographic distance, time-zone offsets, language differences, national culture differences, site-culture differences, and site-status differences make communication less reliable and more difficult.

Periodic in-person communication is important. As one senior leader of a global company said to me, “The half-life of trust is 6 weeks.” When you see mistakes begin to increase, it’s time to put people on airplanes, have them play games together, eat together, and develop human connections.

Aim to have a percentage of staff members traveling from site to site approximately every 6 weeks, with a goal of 100% of team members visiting other sites over a period of years.

Increase logistical support for distributed teams

If you want to be successful with distributed teams, you need to invest money, effort, and time to support that style of work.

  • Scheduled communications. Establish mandatory meetings that everyone must attend. Rotate the inconvenient times across sites so that no single site incurs all the time-zone fatigue. Provide effective tools for remote meetings and the network bandwidth to support the tools. Insist on good meeting practices: create agendas, define deliverables, stay on topic, end on time, and so on.

  • Ad hoc communications. Support cross-site communications that arise spontaneously. Provide each staff member with communication technology: high-quality microphone, web cam, and adequate network bandwidth. Provide tools for text-based, time-sensitive, streamed communication as well as online forums (Slack, Microsoft Teams, and so on).

  • Remote proxies. Designate people at remote sites as proxy PO or proxy engineering manager. When the team can’t get an answer from the remote PO or engineering manager, they can reach out to the proxy. The proxies have regular one-on-one discussions with their remote counterparts so they can stay in sync.

  • Staff transfers. Consider moving staff permanently or on a long-term basis. Because of the international composition of many software teams, it is not uncommon to find team members who want to return to their home countries. A little-known fact is that Microsoft populated its first Indian site with Indian nationals who had already worked at Microsoft’s Redmond campus. This helped with establishing company culture and deep knowledge at the Indian location.

  • Onboarding and training. Schedule new staff to visit the site remote to them as an onboarding activity. Provide mentors to coach new staff on effective multi-site work practices.

Leverage Autonomy, Mastery, and Purpose

Some companies distribute teams evenly across multiple sites, with each site having equal status. More commonly, companies that have multiple sites create status discrepancies among their sites: onshore vs. offshore, in-house vs. outsourced, parent company vs. acquired company, and main site vs. satellite sites. They allocate different kinds of work to secondary sites, including less important work, and they allow those sites less latitude.

The differences in status and lower Autonomy limits each site’s motivation. I have found that secondary teams tend to be self-aware and candid about their status and level of responsibility. Managers of secondary teams frequently report that their teams ask for more Autonomy and self-direction, ask for opportunities to grow (Mastery), and want to understand the bigger picture of the work they’re doing (Purpose).

To be successful with multi-site development, Agile or otherwise, find ways to provide each location with work it can perform autonomously and allow each site to grow professionally.

Actively communicate why each site’s work is important to the organization or the world at large.

Respect Conway’s Law

Conway’s Law, loosely speaking, says that the technical structure of a system reflects the structure of the human organization that built the system ( ConwayConway’s exact language is this: “Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.”, 1968). This structure includes the formal management structure and the informal interpersonal network structure. The interplay between these structures is significant on geographically distributed work.

Conway’s Law is a two-way street: the technical design also influences the human organization design. If the team is distributed across three sites, but the technical architecture doesn’t support work in three independent areas, the teams will struggle because they will have technical dependencies on one anothers’ work that span geographic boundaries.

If a team has been geographically distributed for years, the technical architecture probably already reflects the team’s structure. If your team is transitioning to becoming geographically distributed, compare the technical architecture and the human organization and look for mismatches.

Treat Agile teams as black boxes

As with co-located teams, the management discipline of treating teams as black boxes supports managers acting more as leaders who set direction than as managers who are overly concerned with details. Manage inputs to your teams and outputs from your teams. Avoid focusing on the details of how your teams perform their work.

Maintain high quality

The Agile discipline of keeping the software close to releasable at all times helps prevent teams at different geographies from diverging too much from one another.

Part of treating each team as a black box is assuring that the output that comes out of the box is high quality. The practice of keeping a code base at a releasable level of quality is a high-discipline practice that even co-located teams struggle with.

Teams’ natural tendency when they are distributed is to converge to a releasable state less often. This is a mistake. Geographically distributed teams are at risk of going in different directions without realizing it, which means, for the sake of risk management, that they should converge more often rather than less. To ensure they’re converging effectively, distributed teams should pay special attention to their Definition of Done.

The effort required to keep the software at a releasable level of quality highlights the costs of geographic distribution. If a distributed team finds that it’s spending an inordinate amount of time in its frequent convergences to a releasable level of quality, the solution is not to converge less often. That increases the risk that the team won’t be able to converge at all! The solution is to modify practices to streamline the work required to converge reliably and frequently. In some cases, highlighting the convergence effort might lead to a decision to reduce the number of development sites.

Be aware of cultural differences

Common differences across cultures include:

  • Willingness to communicate bad news, including even answering “no” to simple questions

  • Response to authority

  • The ethos of individual vs. team accomplishment

  • Work-hour expectations, and prioritization of work vs. personal life

Much has been written about this, so if you aren’t aware of these issues, go read about them.

Inspect and Adapt

Developing with geographically distributed teams is difficult. The challenges will vary based on how many sites you have, where the sites are located, your software’s architecture, how the work is allocated across sites, and the capabilities of the specific teams and individuals at each location.

For geographic distribution to work, teams must engage in regular retrospectives to candidly assess what’s working, what’s taking more time than it should, and whether issues related to working in a distributed team are causing problems or inefficiencies. Cultural differences can create challenges for retrospectives, and extra work might be required to encourage frank discussions.

The organization should also support system-level retrospectives that focus specifically on streamlining issues related to multi-site development. The teams must then use those insights to make changes that address the difficulties they’re identifying—and the teams must be empowered to make those changes. If they are not empowered, the organization risks low effectiveness from geographically distributed development.

Poor execution of distributed development can demotivate staff both at primary and secondary sites, leading to lower morale and higher turnover.

Many organizations—perhaps even most organizations—fail to achieve the objectives that led them to establish geographically distributed teams. You have to do a lot of things right to be successful with distributed teams, and this is not an area where you should take shortcuts.

Get hands-on with 1400+ tech skills courses.