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, 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

About the author

Sowmya Karunakaran's picture Sowmya Karunakaran

Sowmya Karunakaran has been involved in agile software development since 2005. She has worked in different flavors of agile, XP, Scrum, DSDM, FDD, and XP/Scrum hybrid. Currently, Sowmya is a lead consultant at Agile Center of Excellence, HCL technologies, and is responsible for evangelizing agile practices across the organization and facilitating large-scale agile transition activities for some of her Fortune 500 clients. She has presented many papers at various conferences, including IEEE, ASCI, and Agile Tour. Sowmya enjoys writing articles and papers in her areas of interest. Recent works include co-authoring the book Model Driven Software Development and Integrated Quality Assurance, published by the IDEA group, and articles in Agile Record andTesting Experience. Sowmya’s interests involve model-driven architecture, agile methodologies, and human machine interface computing.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!