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.