Seven Strategies for Handling Distributed Agile

Global markets, global talent, and a constant pressure to reduce costs through outsourcing are all major forces that contribute to distributed teams. In VersionOne’s 2008 State of Agile Development survey, 57 percent of respondents stated that their teams were distributed.  While distributing a team could have practical business reasons, distribution can inhibit communication within the team.

Ken Schwaber writes in his book, The Enterprise and Scrum, “High-bandwidth communication is one of the core practices of Scrum … The best communication is face to face, with communications occurring through facial expression, body language, intonation, and words. When a white board is thrown in and the teams work out design as a group, the communication bandwidth absolutely sizzles.”

My article discusses aspects of distributed agile—challenges as well as mitigation strategies—based on experiences and lessons learned from fifty-odd distributed agile projects. I focus particularly on the top seven strategies that are widely adopted and used on projects.

Strategy #1: Managing the Communication Bandwidth
The time zone differences between onsite (particularly western) client locations and many of the major offshore development sites like India are so huge that, at times, the business hours are completely mismatched. A mitigation option is to identify the possible overlapping hours. This could vary based on the geographies in which the teams are located. In case of Project A, the teams are distributed across Chennai, India, and New York. Because the overlapping business hours are practically zero, an adjustment has to be made that addresses this.

Identifying the probable windows (see figure 1) is the first step. It appears the Chennai team, with a little extension of the business hours, can catch up with the early business hours of the New York team. The Chennai team’s work schedule was revamped and modified from 9 a.m. to 6 p.m. to 11 a.m. to 8 p.m.

Figure 1: Project A

In the case of Project B (shown in figure 2), which comprises a six-member project team, three members are located in Bangalore, India, and three members, along with the product owner, are based in London. The time zone difference between these two cities is about five and a half hours, which means that the teams had three and a half hours of overlapping business hours. This time was effectively put to use and all cross-team activities were scheduled during this time.

Figure 2: Project B

Strategy #2: Ensuring Visibility into Project Status
ScrumMasters, product owners, and business sponsors often experience problems related to the correctness of the project status. While this is also an issue with collocated teams, the distributed team dimension heightens the problem further.

This can be bridged to a great extent through the use of agile project management tools. Most tools have extensive dashboarding facilities, in which the biggest advantage is the option for customizing views and reports based on individual project needs. A sample dashboard from JIRA-Greenhopper is shown in figures 3 and 4.

Figure 3: Sample dashboard #1

Figure 4: Sample dashboard #2

Strategy #3: Monitoring Software Quality and Project Health
At times, the project’s health is unknown until the actual release, since there is no way to gauge the code quality and the code stability. The coverage rates, status of unit test cases, code violations, build stability, etc. can remain completely unknown unless the teams take time to measure and report them over email or via a phone call. But, in real time, this may be practically impossible due to the delivery pressures that the team members are faced with. Build stability is particularly critical, since an entire day might be lost for Team A in Country A if Team B in Country B went home without realizing that he checked in a piece of code that had broken the build.

Continuous integration (CI) tools help bridge this gap by providing build automation as well as continuous tracking of project quality. Figure 5 lists the various parameters that can be automated and tracked using a CI server.

Figure 5: CI Dashboard

Strategy #4: Creating Avenues for Collaboration
“Collaboration and communication,” an important aspect of the Agile Manifesto, can be severely impacted due to the distributed nature of teams. Though frequent travel and resource shuffling across locations is preferred, practically, it may not be possible to use these options due to the huge cost factor attached to them.

Using emails and chat tools can provide a quick and cost-effective solution for bridging the collaboration gap, but there could be problems with using only these tools. When using email, only the primary owners of a task or story are kept in the loop and owners of dependent tasks may not be aware. In the case of agile projects, the entire team has to be in sync due to collective code ownership. Using group IDs can resolve this issue to an extent; however, the pitfall of managing threaded discussions over time is still a problem. On the other hand, “chats” can help trigger quick and spontaneous discussions and group chats can be used for productive team discussions. Chats are slightly better than email, since it’s possible to share emotions via gestures. But, chat shares the same pitfalls as email, including managing chat content over time. Collaboration tools like wikis, Confluence, Alfresco, and SharePoint are better alternatives used in many agile projects. Figure 6 shows a sample screen from Confluence, a collaboration tool.

Figure 6: Confluence, a collaboration tool

Strategy #5: Virtual Taskboarding
A taskboard is representative of all the work being done for the sprint. It has to be updated every day (the ScrumMaster is generally responsible for keeping it alive) as it acts as a ready-reckoner for the daily scrums. A quick look at the taskboard gives anyone an indication of how well the sprint is progressing. However, the taskboard is not useful in the case of distributed teams, since the remote team cannot see this dashboard. Most of our distributed agile projects handle this situation by use of virtual online taskboards (shown in figure 7), which are generally available along with agile project management tools.

Figure 7: Virtual taskboard

Strategy #6: Setting Up Meetings
In the case of distributed teams, there is a constant need to set up audio conferencing bridges, configure live meetings, and manage the time slots for important activities like sprint demo, retrospectives, and planning meetings. Unplanned, last-minute hurry up can cause a lot of panic, and there are even instances when sprint demo sessions and planning sessions have been cancelled due to the unavailability of a conference room.

Since most of these meetings need to happen during extended business hours, it is a best practice to plan these meetings upfront, thereby giving team members sufficient time to plan their leave and unavailability. In some agile projects, the sprint demo and planning dates are published at least one month ahead. When faced with issues like network problems, poor connectivity, and poor turnout, Scrum Masters can make alternate arrangements as soon as possible. This is an important point to keep in mind, since carrying forward with a meeting with too many interruptions and disconnections can break the team’s morale and waste time. Calling off a meeting due to a missing team member shows the team that every one of them is important for the project’s success. In order to utilize the entire team’s time efficiently, it is a best practice to set up the agenda in as much detail as possible.

Strategy #7: Product Owner’s Bandwidth
The product owner’s bandwidth is critical because frequent interactions between distributed teams and the product owner are handicapped due to the limited time available during the overlapping hours. Not only are product owners often the product managers, they are generally juggling multiple teams. The distributed dimension worsens the problem. On the other end, the remote team is blocked and loses precious sprint time while waiting for clarification. To overcome this problem, the idea of a proxy product owner has been used in some projects, where a business analyst or a functional specialist plays the role, which bridges the gap between the team and the product owner.

Two points to keep in mind:

1. The proxy product owner should be empowered to make decisions unless those decisions are critical and need the product owner’s nod. Otherwise, the proxy product owner would be considered overhead, since he has to refer to the actual product owner for every decision, which impedes the team’s velocity.
2. The proxy product owner is only a “proxy” and never a substitute for the actual product owner. The team should at no point be completely disconnected from the product owner, since this can result in reduced accountability at the product owner’s end.

While these are some of the major challenges faced in most distributed agile projects, there could be factors specific to a particular project dictated by the project’s characteristics. The seven strategies listed in this article can help mitigate the major and most common challenges; however, distributed agile teams should also be cognizant of certain factors that could be specific to their project and work out ways to handle them. For example, consider the case of a distributed team that has not set up a local development environment due to security restrictions. Clearly, in order for the team to succeed, it must adopt the seven strategies detailed above and also have a dedicated, good-quality line for accessing their development environment located in a remote geography.

Though it is true that collocation is best for adopting agile, distributed teams should not be demotivated due to this fact and refrain from adopting agile. Teams should identify the scenarios that could hamper their agility in a distributed manner and work out strategies to handle them in the best possible manner.