The 4 C’s of Managing Distributed Agile Teams

Scrum works well for collocated teams, but working with distributed teams brings its own different challenges. There should be some controls in order to prevent instability, ambiguity, and tension from turning into chaos. As the ScrumMaster is the servant leader of the team, here are four important initiatives the ScrumMaster can take to guide their teams—the four 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.

User Comments

Rich Stewart's picture

Thanks for the great points, Ajeet. As you point out, with different time zones, it's often difficult to get sufficient time to collaborate and therefore, the time that is available must be utilized efficiently. This may preclude your first C "Checkpoint" at the end of the day, due to time differences. In fact, for some globally distributed teams, such as the ones I serve as Scrum Master, there may be up to 12 hours of time variation across the team. So, for some, like myself, it's early morning, and for others it's early evening when we connect as a whole team. Therefore, just holding one daily touchpoint, i.e. the Scrum meeting, is the best we can do. 

One way that we overcome this small overlap within the Scrum process, is to extend sprint planning over three days. I kick off the planning discussion on day 8 of the sprint, continue the discussion on day 9, and then we commit on day 10, so that our Asian and European team members start day 1 of the new sprint with an agreed upon set of work hours before we connect near the end of their day. We conduct these planning discussions within the 30 minute Scrum meeting on day 8 and 9. On day 10, we extend to 45 minutes for sprint wrap-up ceremonies. This is clearly not optimal in terms of the amount of time for these activities, however over time we've developed high-performing distributed teams. A significant factor is continuity of key team members of multiple years so we don't backslide from our good practices.

June 28, 2018 - 1:16pm
Ajeet Singh's picture

Thanks Rich for the feedback and sharing your experiences. 

Checkpointing comes as a good tool while working with geographies such as Europe, Australia and similar, where offshore teams get good number of overlapping hours. I agree in your case a daily scrum call may serve the purpose as long as you are not sticking to three questions format only.

Ideally the sprint planning for next sprint starts once the current sprint is over, so I presume that you start the 'backlog refinement' from day 8 and then on day 10 you tentatively agree on the set of backlog items that offshore has to start from day 1 of the next sprint, and followed by a formal sprint planning in shared hours - the best you could do in the limited time.

Good to know that your team is a high performing one and been effectively utilizing the shared time window.

Thanks again for your valuable inputs and time.  


July 1, 2018 - 12:05am
Helen Paulraj's picture

Thank you for these great points. I am going to try it out.

January 9, 2020 - 5:42pm

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.