Many software development organizations today have recognized the need for globalization, and have already implemented it in their companies or with the help of service vendors. Often several development locations worldwide are networked with each other. For the associated development teams, this means that they must work together globally – usually across several time zones.

Distributed vs Dispersed Teams

A common scenario is that such global teams organize themselves based on relatively clearly defined areas of responsibility. For example, a team in location A can be entrusted with the overall integration of certain components, while other teams in locations B and C are responsible for the development and provision of these largely independent components. The different teams communicate with each other mostly through the respective managers, project managers or senior IT architects. In such a case, the teams tend to work together internally and are mostly siloed. Occasionally, especially in the case of integration points of the applications, the teams collaborate across location boundaries.

Distributed cross-functional teams with members in several different locations which collaborate closely are still the exception due to the challenges related to team integration, global collaboration, cultural differences and communication.

However, the trend is increasingly towards globally distributed teams (or Dispersed teams) with people in multiple locations across the world. Agile development processes provide for a balanced mix of skills (called cross-functionality) within the team. In addition, the Agile Manifesto maintains that individuals and communication/collaboration are more important than the underlying processes.

Figure 1 – Example of a global team distribution

This article provides tips on how to establish Distributed and/or Dispersed teams based on Agile development processes, with individuals who work across time, space and organisational boundaries.

Set Up the Team

Distributed teams do not suddenly emerge. They arise because an innovative management team has determined that the necessary know-how is not gathered in one place, can be obtained more economically at another location, or provide the freedom for the right people to work from home.

The first important attribute for a distributed team is having highly motivated team members. This is because they are going to have to work harder to communicate, to stay focused and be productive compared to co-located team. The work should never be assigned; the team will need to select and assign the work for themselves. This is a crucial first step which later will lead to a self-organising team. Everyone needs to commit to achieve this goal.

Another important thing to consider in a building a distributed team is to try to avoid doing so with members scattered across too many different time zones. For example, if one of the team members is in California, some spread around Europe and others in Mumbai, this will make it more difficult for them to have effective communication with each other. Time zones can increase wait times. Not only that, but cultural influences and language barriers may add extra overhead for the team. Asking some team members to work unsociable hours is unsustainable. Would you like to get up 5 am in the morning to attend a daily meeting? Or when a developer at one location must wait for another developer to start the day to resolve a blocking issue, the rest of the day can be lost. At some stage this is likely to erode morale.

Even if the team needs to be spread across time zones, the gap between time zones should not be too far (small time zone overlaps) so they can maximize “golden hours”. These golden hours for distributed teams are when the local and remote teams are both in their respective offices at the same time.

Start with Co-location and Continue with Regular Meetups

According to Bruce Tuckman, there are 4 necessary and investable phases in order for the team to grow, face up to challenges, tackle problems, find solutions, plan work, and deliver results – the phases are:

For an Agile distributed team, it is recommended that you set up the team to be co-located in the early stages of the project, at least for teams in the same country or near shore location. This is to let the teams form, storm and norm. Forming a team usually takes at least a couple of Agile Iterations (or Sprints in Scrum). It takes some time and experience to work together as a team.

Defining the team norm and overlap hours are also things that can and should be done during this initial co-location period. A few things that are important to be defined are:

• how the team will communicate with each other,
• when are they going to do the team meetings (or events in Scrum) to enable real-time interaction,
• development environment across the team,
• a clear standard on the definition of “done”. This is to help manage expectations and build rapport across the team. If “done” is not clearly defined, transparency will be lost and ambiguity introduced,
• clear guidelines for bug reporting and troubleshooting

Once everything is set and the team distributed, investment needs to be made to bring the team together on a regular basis to foster team cohesion. For team building, a workshop should be organized early in the project. Remember though, that no tool can replace being together in the same room.

Invest in Collaboration Tools

There are many tools available nowadays to make distributed teams more effective and productive.

• Use face-to-face collaboration tools to ensure the team really “presents”. Using video conference facilities for all important events (i.e. scrum events) is highly recommended. Minimize communicating using emails or meeting minutes, as they are very passive and non-interactive forms of communication. Recording meetings tends to encourage team members to skip the meeting as every meeting is important; all key meetings (or events in Scrum) need to be attended by all team members. At Mitrais we use Skype for Business or Zoom for the daily video conference, and it is supported by Slack and Microsoft Teams for group chats.
• Use online Agile project management tools to manage the work or tasks of the team. It is important that every team member is well informed on the progress of other team members. Using these tools also promotes transparency for other stakeholders outside the development team, which is also the key for Agile development. The simplest tool used at Mitrais is Trello. It is not only used by developers but also other departments like Marketing, Recruitment and even Sales. JIRA and Microsoft Azure DevOps (formally known as Microsoft Team Foundation Server) are commonly used by the development teams.
• Use online version control systems to allow developers to manage changes to source code over time. Version control tracks individual changes by each developer and helps prevent concurrent work from conflicting. GitHub, BitBucket and Microsoft Azure DevOps are the top tool choices at Mitrais.
• Setup continuous integration and continuous delivery tools. Automate as much as possible that can be.

There are many other tools available in the market that will make collaboration between teams more effective. The tools above are items that need to be implemented as a minimum, when the project is started.

Nail it Before you Scale It

Scaling is a popular strategy these days, but do not scale while the team is still adapting to new ways of working. Smaller teams can operate more nimbly compared to larger groups. Before considering scaling, integrate as much continuous improvement as possible within the existing size constraints, either through improved practices, new technology, or the placing of the right people and skillsets in the right place. Once scaling mode is on, so is responsibility. Nail it before you scale it. Understand the team weaknesses and strengths, and do not assume that adding people will solve a problem.

Conclusion

In the end, for global organisations, every team is distributed. All teams need to learn and adapt to how we can share work between locations, communicate effectively and embrace a “we” rather than an “us vs them” culture. For the successful operation of a Distributed Agile Team, every team member must feel and work like one team.