The 4 C’s of Managing Distributed Agile Teams

Agile teams are largely self-managed. This is facilitated by agile frameworks such as Scrum that use ceremonies for teams to collaborate and allow them to organize their own work in sprints.

Scrum works well for collocated teams, but working with distributed agile teams brings its own different challenges. Here are four of the main ones:

Poor utilization of overlapping hours: Creative differences, lack of focused discussions, and differing priorities may result in poor utilization of overlapping hours for teams in different time zones. For example, disagreement on an API design may consume most of the overlapping time in discussion, limiting the teams’ ability to involve the stakeholders the same day and seek help on pending issues.

Commonality of purpose may get diluted: Scrum teams typically work together to create their sprint goals, but distributed teams may have trouble setting and hitting goals. Virtual team communication may result in misunderstandings, team members in one location may help each other more than those in other locations, and important assumptions or agreements may be misunderstood. 

Self-organizing behavior is compromised: Cross-team dependencies and coordination issues may impact the self-organizing behavior of distributed teams. For example, an onshore developer may complete the development of a critical piece of code but not convey this fact to the offshore team before leaving for the day. In the absence of this information, the team may spend its time on lower-priority work. 

Lack of team expression and participation: Managing differences and facilitating free and fair discussion is one of the major challenges faced by distributed teams. This can be due to language barriers, mob mentality, or cultural inclinations.

What can teams do to address these issues?

In their Harvard Business Review article “The New New Product Development Game,” which directly influenced the Scrum framework, Hirotaka Takeuchi and Ikujiro Nonaka highlighted the need for subtle control of self-organized teams. Likewise, management should establish some controls for distributed teams in order to prevent instability, ambiguity, and tension from turning into chaos. As the ScrumMaster is the servant leader of the team, it makes sense for them to provide this subtle control.

Here are four important initiatives the ScrumMaster can take to guide their teams—or, as I like to call them, the four C’s of managing distributed agile teams.

1. Checkpoints for teams daily

It’s a good practice to establish a ten-minute checkpoint call among all distributed teams to touch base prior to anyone dispersing for the day. The purpose of the call is to allow teams to quickly introspect and synchronize on emerging priorities, make progress on any burning issues and immediate blockers, and identify any urgent need to engage any stakeholder. This call is different than the daily scrum, as it includes all teams and can be more informal.

The checkpoint provides an opportunity for distributed teams to develop a holistic understanding of the sprint’s progress before anyone leaves for the day, as well as enough information to know what they should be doing when they resume work the next day prior to the daily scrum.

It helps teams focus on the highest-priority tasks, and they can get clarity from the product owner on open items, defects, and blockers that need to be a priority. Members of the distributed teams also get the chance to sync up on any information radiators to reflect correct status and hours spent on activities. This helps maintain sprint statistics and burndown charts.

The ScrumMaster’s role is to facilitate the conversation, asking clarifying questions as the need arises and keeping the call as brief as possible. This checkpoint should be timeboxed so that teams come prepared for a quick discussion and organize themselves to make the best use of time.

2. Commonality of purpose

The ScrumMaster is responsible for removing distractions from the teams, placing everyone in a better position to deliver work and minimizing chaos so teams achieve their goals. Removing distractions has an even more important role in a distributed agile setup.

One way ScrumMasters can reduce distractions is by connecting with local leadership. When disturbances arise due to local issues, such as infrastructure, a team’s productivity and morale can be jeopardized if issues aren’t quickly addressed. It is the ScrumMaster’s role to build relationships and connect with local leadership and supervisors in alllocations to quickly resolve local issues that impact productivity and morale. ScrumMasters may also need to train local leaders on agile, the Agile Manifesto, and the agile delivery model so that they understand the context and don’t place conflicting rules and processes on local members of a team.

Scrum Masters also should help their teams set up ground rules so that teams across all locations operate as a cohesive unit. Examples of ground rules may include that everyone shows up for ceremonies, plans long leaves at least two sprints in advance, doesn’t drive individual agendas over the sprint goal, updates information radiators by the end of each day, and logs risks and impediments in real time.

Checklists may be necessary to maintain the consistency of work done by distributed teams, but use them with caution, as we do not want to impact creativity and make our agile process too prescriptive. However, checklists for steps in the continuous delivery pipeline to avoid deployment issues, or branching and deployment do’s and don’ts, are often helpful.

Real-time communication also plays a vital role in the success of distributed teams, so a communication delay on any critical piece of information might derail progress. For example, if an off-shore team discovers certain design recommendations but does not share them with everyone, it can result in rework.

There are several measures a ScrumMaster can take that can help make sure miscommunications is kept at a minimum. For instance, teams can leverage virtual communication tools like video conferencing or instant messaging for real-time updates of risks, impediments, and other critical information. It’s also a good idea to cover communication issues as part of retrospectives to figure out what works and what the barriers are to smooth communication. As with any retrospective, inspect, adapt, and take action immediately when problems are identified. 

3. Coaching for agility and behavior

There is always a possibility that teams working across locations develop professional differences because of their working styles, belief systems, or gaps in experience level. These differences aren’t often recognizable up front but will hamper the agility of the teams in the end.

This can lead to difficult situations, but there are a set of skills ScrumMasters can exercise to respond to this type of situation.

First, sense the underlying conflicts and try to intervene before there’s a problem. Watch team dynamics, hear the untold stories, and monitor collaboration among the teams across locations. Diffuse the conflicts by direct intervention and coach teams to ensure silos are eliminated.

Then, advocate for inclusiveness and acceptance. Reiterate what makes an agile team by revisiting agile and Scrum values to encourage respect for each other’s backgrounds, empathy for working styles, and acceptance regarding language proficiency and experience gaps.

Finally, give the team a reality check on self-organization. Use a retrospective to discuss the incidents that derailed the team’s progress due to ignorance of and noncompliance to the team’s protocols and agreements.

4. Cultivating free expression

ScrumMasters should inculcate the culture of constructive discussions so that teams across locations can engage in open debates and reach a consensus for resolutions.

There are two main practices the ScrumMaster can put in place to facilitate discussions. First, seek equal participation from all the teams and groups, not letting people easily walk away from the active contribution in discussions. Then, intervene as needed to deter one group from hijacking the discussion or keep the discussion from going around and around without yielding meaningful results. Ask questions as necessary, but for the most part, let the team self-organize.

By following these four C’s and incorporating them into the typical ScrumMaster duties, the ScrumMaster can facilitate team interactions—even across cities and time zones—and get the most out of their distributed agile teams.