One of the enduring myths about agile software development is that it's only applicable for small, colocated teams. Dr. Dobb's 2008 Agile Adoption Survey (www.ddj.com/architect/207600615) disproved this myth, with respondents indicating that agile strategies are being applied successfully on development teams of more than 200 people that a large percentage of agile teams are distributed. In "Agile and Large Teams" (www.ddj.com/architect/208700162), I discussed strategies for organizing large agile teams, and this month I'm going to describe the experiences of a product development team within IBM that is both distributed and agile.
If someone on a team is working on a different floor, working from home, or working in a different building than other team members, then your team is distributed. Figure 1 summarizes some results from Dr. Dobb's 2008 Agile Adoption Survey, showing that the project success rate decreases as a team becomes more distributed. Although this is alarming, it is not surprising—the greater the distribution, the greater the risk. However, the important point is that many people are succeeding at distributed agile development.
Understanding the Risks
The lower success rate of distributed development teams is primarily due to increased communication challenges. Even with near-location, where team members are in the same geographical region and could easily get together physically if required, there are communication risks such as people having different priorities or understandings of the requirements. Many organizations will try to paper over these risks by requiring detailed specifications, but as media richness theory showed decades ago, documentation is the least effective way for communicating information between people and can increase project risk further.
Far-located projects, where planes would need to be involved to get people together, can suffer from cultural and time-zone differences. To counter these risks I make it a habit to ask open-ended questions to determine whether or not the other people understand the topic under conversation. Particularly, I never ask a "yes/no" style of question because the simple answer of "yes" can mean a range of things depending on the culture. It may mean:
- "Yes, I heard you."
- "Yes, I understand what you're saying."
- "Yes, I understand and agree with you."
When dealing with people at other locations, it's good practice to ask them to summarize the conversation in writing, even if it's a point form e-mail, to ensure common understanding of decisions.
Lack of trust in the abilities of others whom you don't directly work with or know well is also a problem, this is particularly true when multiple groups or companies are involved. This lack of trust will reveal itself with the insistence on the creation and then acceptance of detailed specifications to be provided to people at distant locations, a focus on the legal contracts between the organizations, and too little discussion of the overall process followed by "each side." Having consulted to several system integrators as well as to their customers, I can safely say that everyone involved with offshoring projects could benefit greatly from open and honest discussions of how they're actually working. Most system integrators would love to be able to provide better levels of service to their customers by adopting more agile ways of working, but mistakenly believe that their customers want to work in a more bureaucratic traditional manner. Similarly, their customers believe that the system integrators can't work in this way, mistakenly thinking that CMMI-compliant organizations can't be agile. My advice is to talk with your development partners and together explore more effective ways of working together.
To put my advice into context, I want to share with you some of the experiences of an IBM development team working on a next-generation metrics-based project and program management tooling which is built on the Jazz technology platform (www.jazz.net), providing support for reconciling various project processes such as agile, traditional and hybrids that are anywhere in between. The project team is currently 30 people strong with members in Bangalore, Boston, and Toronto. The project team has iterations of three weeks in length, with internal demos each week to ensure regular feedback from their distributed stakeholders and milestone reviews every six weeks to keep senior management in the loop.
