Get certified - Transform your world of work today


Helping Distributed Scrum Teams Thrive

29 June 2017

Distributed teams are the new reality, mainly due to globalization and the flourishing of technology that enables this. Businesses are shifting to emerging economics to reduce operations costs and because of easy availability of a talented workforce. This has created new challenges in team coordination and management. So it’s critical for enterprises to arm themselves with the right tools and processes.

Agile and Scrum are the latest buzzwords. Distributed Scrum Teams located at different geographies collaborate and work effectively to achieve business goals. I have had multiple opportunities to work on distributed teams, with the goal to create product experts at multiple geographical locations. This was essential to cater to expanding businesses at new locations, and to manage costs. In this role I faced the following major challenges:
  • Cultural and language differences: The most important role for a ScrumMaster is to help team members know each other well and build trust and confidence in each other. I did this by facilitating regular videoconferencing between teams and by sharing team photos, which helped develop a collaborative environment.
  • Communication gaps: To ensure that there is no communication gap, minutes of meetings, with all important points noted, were regularly circulated to the teams.
  • Different time zones and conflicting working hours: Team members complained (rightly) if they had to work odd hours to coordinate across different time zones. This was handled by rotating responsibilities across members.
  • Selecting the right tools: Effective tools are required for repositories, supply chain management, project management, build and deployment setup, and defect tracking. Involving the team in selecting these tools and improvising the processes motivates them.
  • Continuous integration and deployment: CI should be promoted so that distributed teams have fewer dependencies in terms of code integration and merging.
  • Technical dependency: Generally there are domain and technology experts on the team. This can create a bottleneck if they are absent. To counter this, we promoted regular knowledge sharing and brainstorming sessions.
  • The product backlog is shared between teams, or they have different product backlogs: Even if the team is working on the same product, it matters that backlogs, whether shared or paired, are kept consistently up to date.
  • Sprint planning: Once the backlog is created by joint effort of the team and PO, it is important that it is provided with story sizes. To size stories, the same estimation techniques should be used across the distributed team.
  • Reports and graphs: It is also important that the hard work the team is putting in is reflected in proper graph and reports. The product owner and senior management expectation in terms of graphs should be understood and generated. As coaches, we can also help the distributed team with other forms of reports that illustrate the progress of both the team and their projects.
  • Conflicts: With a big team, conflictual situations increase. It is important that conflicts are properly handled to keep everyone motivated and focused on their work.
  • Appreciate and celebrate: All hard work should be appreciated and celebrated across the team. It should be reflected through information radiators or floated through mail or put on a team page.
  • Collaboration: To improve collaboration within a distributed team, play some collaborative games or promote a team party. This helps form good relationships among the members.
  • Promote the values: Ensure that Agile and Scrum values are well understood by the entire team.
  • Community of Practice: The different representatives working on same technology or tool can form a community within the organization, one that can share experience and knowledge. This helps build technical excellence.
All of this must align with the company culture. From a culture perspective, you must shift to a culture where it is OK to have a few failures as long as you are learning from them and not repeating your mistakes.

These have been my most important takeaways:
  • Hold limited but productive meetings and brainstorming sessions. Too many meetings waste team time; the idea is to build an environment where team members are motivated to contribute to meetings.
  • Culturally, teams in the U.S. generally prefer to work with story sizing and velocity-based sprint planning. In India, senior management prefers capacity-based planning. In my opinion, you should not stick only to one. See how much business value the team is able to deliver by trying both of these, or mixing the two.
  • Management may complain or fail to appreciate the need for collaborative games. Try to influence and convince them by showing results.
  • In cases of distributed teams in scaling situations, it is important to note that neither a bottom-up nor a top-down approach will work until people have the mindset to adapt.
Scrum indeed works well if complex projects need to be implemented across geolocations. I hope this information helps you. Please put any questions in the Comments section or write me at

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.3 (9 ratings)


Robin Hackshall, CSP,AdvCsm,CSM,CSPO, 6/30/2017 1:08:02 AM
This is also area that I have discussed recently on my blog -

There is an impact to delivery from the use of distributed delivery teams. This impact can only be minimised rather than eradicated.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up