Global markets, global talent, and a constant pressure to reduce costs through outsourcing are all major forces that contribute to distributed teams, but distribution can inhibit communication within the team. Here are seven strategies for staying agile in the face of distributed-team challenges.
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