Get certified - Transform your world of work today

Managing Distributed Teams

07/31/2013 by Gauravdeep Kaberwal

Today businesses are shifting to emerging economies (Russia, China, India, the Philippines, etc.) due to reduced business operations cost and an easily available workforce. If I put it more precisely, tomorrow's business will be more virtual and distributed, with "distributed" as its key element. Thus the need for better managing such teams, using the right tools and processes, is becoming increasingly critical for any enterprise company.
Here are some reasons for the shift and need for having distributed Agile teams:

  • Globally distributed teams reduce costs.
  • They can reach the market more quickly with a "follow the sun" model.
  • Distributed teams expand access to new markets.
  • Acquisitions as a result of consolidation results in companies working together to integrate their businesses.
  • Expansion can aid innovation and thought leadership.
  • Telecommuting gives options for communicating with teams effectively.
  • Collaboration tools -- improved tools for distributed communications and server-based, multiuser tools for product development -- are removing barriers, and more teams view distributed collaboration as an alternative.

Handling distributed Agile teams
Distributed teams heighten the need for clear, timely communication between sites. You might be thinking of increases in complexity due to more time zones, language barriers, and cultural differences getting in the way.

Questions can include these:
  • Are distributed teams difficult to manage?
  • Are they failing to meet some expectations?
  • Are they having trouble working as a team?
  • Is team morale a problem?
Agile can't fix every problem, but it can bring them out into the open, where the team can evaluate and correct them. Agile puts challenges under a magnifying glass. As the images under the glass grow larger, they scream for attention, and your team's performance will improve after it addresses the challenges and corrects dysfunctions.

The key challenging areas that need to be addressed for distributed team management are as follows:
  • Communication is the core issue among the distributed teams.
  • Different time zones and conflicting working hours impact communication and collaboration.
  • Cultural and language differences impact communication and collaboration.
  • An effective tool chain is needed for requirements repositories, SCM, management, build and deployment setup, defect tracking, and project management tools.
  • Three XP practices that are particularly valuable: TDD, CI, and test automation
  • Scheduling differences at the team level for various activities becomes more challenging with increasing levels of distribution.
  • Time dynamics have positive and negative impacts on distributed teams.
  • Improper and inappropriate telephone and video setup impacts communication and creates problems.
    • Not providing access to calls, not set up for telephone calls in meetings, difficulty identifying an unseen speaker, need to encourage participants, limiting the conversation using round-robin technique, importance of mute, checking for any agreement or disagreement
How Agile helps address these challenges within all the Scrum ceremonies

Self-managing distributed cheat-sheet table
Preparing for Sprint Planning
  • Product owner needs to understand the capacity and look for opportunities to create cross-functional teams within similar time zones.
  • Team composition: Teams of more than 9 people should consider geographic closeness and proper distribution of skills as well as team size so as to build self-organizing teams.
  • Individual Scrum teams should aim to have the lowest distribution level possible, encouraging feature teams over component teams.
  • Disaggregate the higher-priority features: Distributed team members, PO, and ScrumMaster develop more than one feature to address a single solution that can fit within a sprint.
  • Single backlog for multiple teams: Different skill sets in the team are needed to deliver user stories that are available across each distributed location.
  • Separate backlog for multiple teams: Scrum teams work independently from one another and have their own individual sprint backlogs, but the sprint dates are the same, marking their interdependencies and risks in the sprint preplanning sessions or in a daily Scrum of Scrums.
  • Release planning: The number of sprints to map out and use with a "look-ahead planning technique" will depend on sprint length, dependencies, and the needs of the teams involved.
  • Sprint length: Teams that work on a set of related products should synchronize their sprint lengths and start dates to cater to their interdependencies.
  • Sprint velocity: Although it is difficult to estimate the velocity in projects with multiple teams, they should always estimate the stories they will work on, because teams have different scales.
  • Manage dependencies within the teams: Agile teams will not try to account for every possible dependency at the start of the project but will look ahead two or three sprints to ensure that teams are ready to deal with dependencies, using the INVEST model.
  • Risks: During the release plan, the PO will want to identify the risks associated with the project and teams, and, when possible, the mitigation plan for each of them.
  • Coordinate multiple product owners of different teams: Product owners meet regularly to discuss product backlogs, dependencies, and links between and boundaries between user stories of different teams.
  • Use Agile project management tools: It is mandatory to have enterprise tools to manage teams and their work related to the sprint and for overall governance of the product.
  • Invest in smarter development: Test automation and continuous integration help Agile teams complete user stories within a sprint, working together or for distributed teams.
  • Coordinating Agile and non-Agile teams: Making sure the non-Agile team is aware of the priorities of the Agile teams and keeping dependencies visible can help to prevent blockers between the teams.
  • Face-to-face collaboration: The SM should reduce the amount time spent each day on project setup tasks, which will extend the duration of the project startup tasks and enhance the trust and relationships needed in distributed development efforts.
Sprint Planning
  • Sprint planning meeting: Product owners need to coordinate the priorities between the product backlogs of different teams, considering their dependencies between the projects, features, and stories before giving the commitment.
  • First level of sprint planning: The PO and SM will use a screen-sharing tool to display the vision, sprint goal, user story, the estimates the team provided, and the acceptance conditions for the user story.
  • Dealing with incomplete stories: The PO takes the impact of dependencies into consideration when reprioritizing the product backlog due to which team did not complete items during the sprint.
  • Checking estimates from preplanning teams: In scaled distributed environments, where teams send representatives to help with preplanning, it is important that teams who are going to be doing the work revisit the estimates.
  • Reviewing changes based on stakeholder feedback: The team would review changes made since the preplanning meeting, and the PO would confirm the priorities of the product backlog.
  • Engaging stakeholders: At enterprise-level environments, to address the diversity of data by the Scrum team, the PO can help identify which customers are representative of different markets.
The second half of sprint planning

Deciding how to get the work done: Creating the sprint backlog -- the PO reviews the highest-priority items in the product backlog with the team and helps the team to take a guess at how much work they can do within the sprint.
  • Identifying tasks: The PO gives the team time to think about the tasks needed to complete the work items during the sprint planning meeting. Teams run planning meeting discussion among all the stakeholders to get maximum clarity on the tasks.
  • Gaining commitment: With a distributed team, team members who are sensing that other team members have unspoken issues need to take responsibility for drawing the SM's attention to the issues; because of this, the SM needs to rely on the whole team to take responsibility for ensuring good communication.
    • Note: No one should interpret silence as agreement. Team members should phrase questions in a way that they need a verbal response to improve the understanding within the team.
  • Release plan check or update: Enterprise Scrum teams often begin providing tasks for high-priority user stories before the sprint planning meeting. All team members discuss the tasks because it helps with communication for distributed and scaled teams and provides opportunities to find better ways of completing the user stories. Silence on a teleconference is not a commitment.
Distributed Daily Scrum Meetings
  • Using the 3 questions effectively: The PO and SM should highlight the importance of the three questions in front of the team members so they understand their purpose.
  • Answering the 3 questions: Team members should communicate information that brings value to others on the team. They should also try to identify team members who can help them resolve their issues.
  • Coordinating the team on a daily basis: Priorities can change daily. The daily Scrum meeting provides a daily synchronization point for the team and allows members to revise their plans regularly.
  • Committing to the team: Team members are making a verbal commitment to their team when they state what they are going to do today, creating an opportunity for the rest of the team to confirm they met their commitments yesterday.
  • Verifying progress: Tasks not opening and closing regularly are an early sign the team may be going off track. Team members not showing regular progress may be facing outside distractions the SM should reduce or remove.
  • Resolving blockers: The SM should create a list of blockers and assign them to team members or managers. The SM should also ensure the team is burning through the blocker list.
  • Daily Scrum logistics: Conducting the daily Scrums when team members are in the same time zone and speak the same language is much simpler than for a team with members spread in multiple countries and time zones, having many different languages and cultures.
  • Daily Scrum logistics - ways of communicating during the daily Scrum: Having face-to-face daily Scrum meetings gives the team the highest level of collaboration possible.
    • Teleconference meeting: Distributed teams with overlapping work hours should use a teleconference call to the same phone number every day to hold their daily Scrum meetings.
    • Videoconference meeting: The main advantage of this approach is that team members get to see one another, so there is less nonverbal communication loss.
  • Approach to handling time zone issues: Distributed teams can use four different methods to deal with distributed daily Scrums where the team has members with no overlap in their work hours, as follows: Daily Scrums through documentation, liaison approach, alternating meeting times, and share the pain.
  • Precautions to be taken while conducting distributed Scrum meeting - Increased distraction: Background noise can be distracting on a teleconference, so teams should chose a quiet room to conduct the meeting.
  • Keeping the team engaged: Possibly the best way to stay engaged and to make sure that others on the team stay engaged is: awareness. Build awareness of what the team is working on.
    • Advertising. Advertise for collaboration.
    • Attack blockers. The team and SM should strive to fix all blockers within one hour of the daily Scrum.
  • Facilitating the meeting: In a distributed environment, as individuals come into the call, they will identify who they are. The SM calls each person and asks for their response. They may respond in the order they arrived at the teleconference or the SM may choose to call on each person.
  • Taking daily Scrum notes: This helps the distributed team members overcome language problems, plan, and learn. Chat Tools and Wiki help distributed teams do daily Scrums.
  • Scrum of Scrum: These can solve distributed team roadblocks, future dependencies, commitments to other team members, issues with integration, and other points that impact one another.
Collaboration within a Sprint
  • Scrum Teams should follow continuous integration, test automation, and test-driven development practice to foster distributed collaboration during the sprint and help teams complete user stories within a sprint.
  • Documentation helps to overcome distance: Because of language barriers, distributed teams often need more written documentation than co-located teams.
  • Using the right tools: In a distributed environment, right tools and effective practices can help team members communicate more effectively.
  • Valuing the whole team: The SM should focus on an "us" versus a "them" attitude in the distributed team, due to more delays in communications and fewer opportunities to work together.
  • Transparency: Distributed Agile teams should use project management tools to identify tasks that are open, in progress, and completed so everyone is aware of the current status.
  • Handling new requests in the middle of a sprint: In distributed Scrum, it becomes mandatory that the team commits to sending requests through the product owner(s), who will decide the priority of the request in the product backlog.
  • Backlog grooming -- shortening the sprint: Shorter sprint lengths make the distributed team more responsive to stakeholders. They also allow the team to adapt to change more rapidly.
  • Dealing with defects: Distributed teams may want to consider creating a user story with a certain number of story points in the sprint to deal with the problems, or they can set a priority for the maintenance tasks as per the customer log, or create a subteam to focus only on handling these issues during the Sprint, or -- depending on the skill set of the technical support team -- make the necessary code changes.
  • Disruptions at the team member level -- handling stories the team cannot complete during the sprint: Before working toward the solution, the team first needs to identify the work they need to do to complete the story through meetings between team members or with the product owner.
  • Handling blockers during the sprint: In the large-scale enterprise transitioning to agile, the SM needs to hear from distributed Scrum team members who are facing blockers and dealing directly with inhibitors will help increase the velocity of the team over time, as well as the velocity of other teams as they transition to Scrum.
  • Responding to questions during the sprint: For enterprise product development, the PO should look for ways to match representative stakeholders with the teams' working hours and to be available during that time as well. For applications the team is developing for a specific client, the product owner may not have the flexibility to choose stakeholder representatives available during the full working day of the client.
  • Sharing time zone challenges: One approach to help manage such cases is to make sure that distributed teams in different time zones are fully self-sufficient and the team spreads the work to minimize dependencies.
  • Continuous integration: This is the key to delivering stable, high-quality code consistently and quickly, which results in reducing time to market for any distributed Agile team.
  • Report any build failures to the team: Allows the distributed team to know the current state of the code in the integration branch of the source control system, generating a notification email for build success or failure.
  • Reduce the risk of integrating code: Continuous integration ensures that a build runs regularly and allows the distributed team to identify integration issues earlier when they are less costly to fix. This practice helps the team identify design problems and avoid introducing defects in scenarios we did not cover. These smaller testable deliverables allow the team members testing the feature to start their work in parallel with the development.
  • Establish greater confidence in the product: When developers are doing the unit testing of their code, they should also create automated unit tests as continuous integration certifies every build, developers can make changes with more confidence, and the entire team can remain in sync with the latest build.
  • Reduce the time to find integration issues: Developers receive the build status by email, so they can see and fix problems. The next time the build runs, the build status changes from fail to pass automatically.
  • Improve the efficiency of the team: Distributed teams' efficiency can be improved by automating once and then reusing as much as possible. This removes human error, provides consistency, and frees up people to do higher-value work.
  • Builds can run at different frequencies: Setting up the hourly build helps the distributed team know about a failure closer to the time of the code integration, and team members can take action on it earlier.
  • Test automation: To streamline the testing and help the distributed team get as much done as possible within a two-week sprint, teams should automate time-consuming manual processes where possible.
  • Dedicated automation teams: The developers in distributed teams should tell what is ready to be automated to allow testers to closely couple with the product.
  • Test-driven development: Developers write unit tests, the small tests that fail first. Testers work with developers to ensure that any later tests do not repeat the work the developers have already done.
    • Provide documentation and working examples of code: Developers are writing their unit tests and providing documentation and working samples for the code they are testing. This allows other team members to gain a quick understanding of the code when they need to work with it.
    • Help reduce the time to fix defects: The developer may be able to create a unit test specific to the case that is causing the problem and fixing the area where the problem is occurring. The developer can save the time needed to create a full build, start the application, get to the right place, and test the fix manually.
    • Help improve code quality and provide a safety net for changes: An early defect detection process helps developers improve the code knowing the existing set of tests will detect any problems. Developers can think of code in small units that they write, test independently, and integrate later.
    • Help team members work together and collaborate: When teams are evolving from a traditional development model to Agile, it is a huge attitude shift to adopt TDD.
    • Help teams move away from big up-front designs: Break down a feature into smaller testable chunks and create small teams to start working on some code right away. This code can be small prototypes that act as tracer bullets through slices of functionality.
End-of-Sprint Reviews
  • Communicate effectively: Team members who are most able to communicate effectively with the team, PO, SM, and stakeholders should present, so that they can represent the team in front of the customer.
  • Fluent speaker: Another approach is to record the demonstration before the meeting to allow the developers to create the recording at their own pace in the language of the meeting, or to have a fluent speaker speak over the recorded demonstration.
  • Scheduling for teams with overlapping work hours: Make sure all team members of the distributed team, regardless of the time zone, can complete their work and prepare for the demo within overlapping work hours.
  • Scheduling for teams with no overlapping work hours alternate meeting time: The distributed team holds one sprint review meeting during the normal workday for part of the Scrum team and holds the other sprint review meeting during the normal work hours of the other part of the Scrum team.
  • Things to be followed by distributed teams in sprint review meetings -- keeping track of the stakeholder comments: During the sprint meeting, the distributed team needs to capture these comments so the product owner and the development team can decide which ones they will act on.
  • Demos may provide a false sense of completion: Add a DRAFT watermark on any screenshots or to use data that is clearly not real, to avoid a false sense of completion to the stakeholders.
  • Remote demonstrations -- network delays and poor performance: Distributed teams should test their tools ahead of time to be sure the distributed meeting will run smoothly, without network poor performance. The team can also consider making the recordings available for download before the demonstration meeting and discussing them through a teleconference.
  • Services may vary by location: Set up a single machine with a standard configuration that everyone uses during the demonstration meeting. Before the start of the meeting, distributed team members can access the machine (remotely or locally) to bookmark links, set up scripts, and do a quick dry run of their presentation.
  • Effective and overlapping retrospective meeting timings: To be effective and timely, distributed teams should call joint retrospectives as soon as possible after having their own team meeting. Depending on the number of teams involved in a joint retrospective, teams may want to limit the number of participants from each Scrum team to keep the meeting productive.
  • Hold joint retrospectives: The distributed teams working together will conduct their individual sprint retrospectives at the end of each sprint and then will conduct a joint retrospective. The benefit of this approach is that it promotes communication between the various teams involved in a project.
  • Conduct milestone-based larger retrospectives: Distributed team members should reflect and comment on release quality and capability. The team defines and records the various milestones within the project to improve on or continue in future releases.
  • Build trust: The SM needs to develop a sense of trust and honesty within the team, which in turn will lead to a wider degree of openness.
  • Reduce effects of distance: The facilitator of a distributed retrospective needs to understand the cultural differences in the team. The SM needs to understand how different cultures interact when they want to change something or have issues they want to talk about that can help the facilitator encourage participation from all team members.
  • Set expectations: The facilitator, for distributed teams, should talk to the team ahead of the first retrospective and explain the expectations for the retrospective.
  • Understand the team members' personalities: Teams have a different combination of personalities, and the facilitator of the retrospective needs to understand the personalities of team members to lead the meeting effectively.
  • Respect cultural differences: The SM needs to make sure cultural difference should not be taken lightly during the retrospective meeting in distributed teams.
  • Ask for comments before the retrospective meeting -- what went well and what can we improve? Ask the team for comments about issues or problems they noticed since the previous Sprint retrospective and summarize them for team discussion. The result is still an action plan and a list of behaviors the team needs to change or continue in the period until the next retrospective.
  • Provide questions to focus the discussion: In a distributed setup, team members respond to a set of questions developed or selected by the team. The purpose is to focus on a few issues and address them effectively instead of trying to address a lot of issues and address them poorly.
  • Discuss reported issues: During the retrospective, the team reviews the reported issues and, if others feel strongly enough, the team addresses them, creates action plans, and logs them as actions they will revisit in later sprint retrospectives to evaluate their success.
  • Release retrospectives: The team talks about the project, then defines and records the milestones in the project, like initial training, team formation, stand-up meetings, start of development, middle of release, deployment, etc.
Distributed teams need to go for mandatory training to run into full-fledged Agile teams, so that they can better understand the potential impact of making the change. Although the project teams learn from adjusting to distributed Agile teams, it becomes more important for them to understand and adhere to Scrum, rather than immediately thinking that Scrum needs to be changed.

I believe that collaboration becomes highly important in distributed teams as they are collectively responsible for delivering on their commitments. One important key to success in managing distributed teams is to have a high commitment level from all team members, and the best way to get that is to give them ownership over how they will work.

Another key to embracing a self-managed distributed team is valuing the entire team and not having an "us versus them" atmosphere between different Scrum teams on the project. The best ways to build relationships within teams is to find ways to share the pain of being a distributed team; to get to know each other as people; and to foster frequent, quality communications between team members.

Another way to introspect distributed team management is to use sprint retrospectives to see what the teams are doing and whether their methods of communicating are working for them. When they need to adjust, they should do so as quickly as possible.

I must say the teams with members distributed across sites can enhance code ownership and improve the autonomy essential to team self-organization. Automated communication of product and sprint backlogs throughout the organization, combined with upward reporting of teams' status to management, can tightly align and knit the distributed teams together.