How to Survive Multi-Continent Daily Scrums

August 20, 2008 by Peter Stevens

As Scrum, XP and Agile mature, Teams and ScrumMasters are increasingly confronted with the problem of handling multiple distributed teams, telecommuters or nomadic team members who aren't able to just co-locate. For instance, a recent project for the Dutch Railways[1] involved 3 teams with a total of 15 developers and testers from Holland and India. This constellation presents many special challenges in addressing impediments, assuring communication and collaboration despite language and time zone differences, and picking tools and technology.... Given these challenges, how does a distributed team perform the Daily Scrum?

Each project is different and has its own special needs and requirements. Is there a common language? If not, then how can communication over the language barrier be assured? Are there multiple teams at multiple locations or one team with scattered members? Project management is about the art of the possible, so how the Team(s) should organize itself/themselves will depend on their actual situation.

At the Daily Scrum, the Team members answer the Three Questions so that they can recognize when bilateral discussion is needed, ask for or offer help, agree on the next steps, etc. The task board and burn down chart help the Team and ScrumMaster ensure that they are track, identify the top priority pending tasks and monitor progress. If the team is using tangible tools (cards) to manage the project, then usually team members will update tasks and the burn down chart just before or during the Daily Scrum.

The ScrumMaster

A key responsibility of the Scrum Master is eliminating impediments. How does a ScrumMaster in Amsterdam fix an impediment in Bangalore? I'm not aware of a good answer to this question (but if you are, please make use of the comment button at the end of the page). As soon as the remote team has achieved a critical mass -- typically three people -- the team will probably want to have a local (deputy?) ScrumMaster, who is responsible for handling local impediments.

When to Hold the Daily Scrum

Language barriers and time zones can make it difficult to hold the Daily Scrum. Noon in London is 17:30 (5:30pm) in Bangalore, so you probably have a window of about 4 hours (although many companies specialized in outsourcing operate on US or European Time). I used to report to a VP in California, we had a "comfortable" window of 3 hours to hold meetings, from 4pm to 7pm my time, 7am to 10am his time. Outside that window, other obligations, e.g. family, sleep (you've heard of sleep?), labor laws (don't apply to me!), etc. make it difficult to hold regular meetings, although late night Skype was not uncommon for me.

If the project covers three continents, e.g. Europe, Asia and the Americas, then it might make sense to hold more than one "daily" scrum, say at the beginning of each shift. Each team member would be expected to participate in two of the three Scrums, assuring an information flow across shifts.

Dealing with Language Barriers

What do you do when there is no common language among the team members? I once coached a project with two teams, one spoke German, the other French. They held a common Sprint Demo meeting. Because language skills were high, they agreed that everyone should just speak their mother tongue. In companies where that doesn't work, it is common to agree on a lingua franca (which today is more likely to be English than French).

Even if there is no shared language among all the team members, there are still alternatives, for instance setting up local teams and holding a daily Scrum of Scrums, or performing the Daily Scrum in writing.

A Scrum of Scrums works when at least one person in each team is strong enough in the business language to represent the team. If not, that is an impediment to be dealt with. BTW - Small teams are not a bad thing. I know of one successful organization, Guidewire, which found the optimal Scrum team size to be 3 to 6 members. When the team hit 6 people, it split into two teams of 3. So the point to form a Scrum team is when the remote group reaches 3 people.

Holding the Daily Scrum in writing can be used when the team members can read and write English (or whatever your business language is), but don't really speak it well, a situation common among developers. I have actually used email on very small projects (1 or 2 part-time people plus me as ScrumMaster/Product Owner). Even though the team was small enough that communication "just worked", answering the questions helped the team members focus on what they had to do.

Email is not a scalable solution, so if there are more than three people involved, instant messaging e.g. Skype, is the way to go. The team members should produce their answers in advance -- typing can be slow, even for native speakers and some team members may need help with the language. Each each team member answers the questions in turn, and the rest read (or have translated) at their own speed.

Technology for the Daily Scrum

I have written before about electronic tools vs tangible tools[2] for agile project management. Scrum thought leaders generally argue for tangible tools, even in distributed environments, but the poll results speak a different story[3]. Enough said.

For the meeting itself, higher bandwidth communication is generally considered better. So physical presence is the best, followed (theoretically) by professional video conferencing, Webcam video conferencing, telephone conference calls, and instant messaging. Last and most definitely least comes email. Obviously the Internet connection has to be up to the task, but that is becoming less and less of an issue.

My own experience with professional video conferencing is mixed. Good video and sound quality, but the room was in heavy demand and too far away to use on a daily basis. Conversations tended to break into groups, one per room, with the TV set producing a lot of unintelligible noise from the other site.

Skype for teleconferencing is inexpensive and once it is running, easy to set up the call, but sound quality is variable and it can be time consuming to get Skype working (problems with Headsets & Microphones, getting the input and output on the right channel, etc.). Most of these problems can be solved, particularly if the hardware environment is stable (not notebooks).

The Dutch Rail project used Skype heavily, with big screens, good microphones and a wall displays in the team room. For project management they used a dedicated electronic tool, which worked better than whiteboards for collaboration and for communicating with the product owners.

Summary

One of the pillars of Agile is effective communication. Distance and language barriers make communication harder. So on the one hand, it's always worth asking the question whether it is really worth the effort to run a distributed project -- see the whole, not the hourly rate! On the other hand, if you are confronted with the challenge, there are ways to address it. Each Team or project will need to look at these issues and alternatives to figure out what works best for them.

Further Reading

For more ideas, this site has published has published useful tips for both local and distributed Daily Scrums[4][5]. What works for you? More importantly, what doesn't work?

[1] Case study: Distributed Scrum Project for Dutch Railways, Marco Mulder and Martin van Vliet
[2] Managing Scrum: Paper, Office or Dedicated Tools? and The Right Tool for the Job
[3] Scrum Management Tool Poll Results: Moving Away From Cards?
[4] 7 Tips for Improving the Daily Scrum
[5] Distributed Agile Development - 2: Managing daily Scrums

Permalink