Distributed Teams in Software Development Projects

Distributed teams are more and more common in today's environment. Some reasons why they are here to stay are

• to save costs
• to get local resources with regional expertise 
• Merger & Acquistions

In any case a distributed team creates additional work and stress to the individuals involved. This translates into more risk for the organization. The following tips and hints are meant to reduce the risk for the organization and are based on our experience with this topic.

1. Learn about Cultural Differences 
This is important for example when your team is located in places where it is less likely that a team member challenges authority (e.g. China).  You want to know upfront what you can expect. So checkout Kiss, Bow or Shake hand or something similar to gather your first idea. Remember that you need to adjust these generalizations for your team. It is a good general preparation though.
During this step you should also make sure you are getting familiar with regional holidays, worktimes and habits to understand the potential impact to your project.

2. Expect a higher travel budget
There is no replacement for face-to-face meetings. To build relationships between individuals and teams they have to spend time together. It is very important to prevent a "us" and "them" attitude. There are multiple ways how this can be achieved.

• get everyone together in one location for a kickoff/sprint planning meeting. The purpose of this is to build relationships. This can be a big step towards knowing and trusting each other. Consider this seriously since it can decide the success of the project early on. These meetings can be from 1 week to several weeks.
• send Key People regularly between different team locations. The purpose of this is to give teams a chance to learn about topics that are usually not discussed in formal meetings. The personal relationships forged here can be very helpful when project challenges arise.
• get everyone together in one location a couple of weeks before important milestones (e.g. Go-Live, Sprint Review Meeting). This makes the communication at a critical time easier since the team is colocated. From a teambuilding point of view this seems not as helpful as the other two options.

3. Expect more communication needs
It is obviously more challenging to communicate across time-zones, cultures etc. You need to spend considerable time at the beginning of the project to learn what communication works the best for which team. When meetings are scheduled between two or more different locations make sure that the meeting times are rotated. This is to ensure that neither team always has to meet outside their usual working hours. Agree ahead of time what turn-around-times you expect for questions, escalations etc to prevent surprises.

4. Work actively to build relationships between teams
Find out if any team members from different locations share the same interests. This can be done with a little survey at the beginning of the project or just by talking to different individuals and taking notes. It might sound a little silly but can go a long way later in the project. If help is needed the team members do it for each other and not necessarily for the project. Nevertheless the project will benefit from these relationships.
Also at the beginning of meetings don't be too professional! It is good to talk about some non-work related topics (e.g. weather, vacation plans, sports etc.) and it allows everyone to relax a little. This kind of trivial relationship building is especially important for distributed teams in order to get a feeling how somebody is doing today.