process.
It is fundamental to recognize that GDD potentially introduces three critical barriers to communication - distance, time, and culture - which your team must overcome to the best of its ability. Even if your team is spread amongst different buildings within the same city, you have introduced communication challenges preventing you from doing something as simple as walking down the hall to talk face-to-face with someone. In quality management, there is an even greater importance for face-to-face communication opportunities with development team peers, possibly relating to the old adage that it's better to deliver bad news face-to-face. When teams are in different time zones you also introduce a time lag between asking questions and getting answers, potentially further dividing the team into different "sides."
Different cultures can also increase barriers to communication, even something as simple as the word "yes" means significantly different things in different countries. For example, when someone replies yes to your question about whether security has been handled by the system, does that mean that it in fact has been handled, that they've considered the issue, or that they have simply heard your question but in fact have taken no action yet? All three situations are valid given the appropriate cultural context, and without a solid understanding of that context you are constantly at risk of making serious mistakes.
To overcome these challenges, you will need to invest in communication strategies which you normally wouldn't implement for co-located teams. The obvious ones are telecommunication strategies such as teleconferencing, videoconferencing, web-based conferencing, and online chat software. What isn't always obvious is that GDD teams need to bond just like non-GDD teams, implying the need to fly at least some, if not all, unfamiliar members of the team together to a single location at the beginning of the project. We all know that there is a qualitative difference in saying that you have worked with the people that you know because you've met them physically as opposed to people you've only met electronically. Our experience is that for any reasonably major GDD effort, it is worth the price to build these initial bonds. Throughout the project, you will also need to fly people between sites to keep the quality of communication as effective as possible. These "ambassadors" may spend a couple of weeks at a foreign site before flying home to their primary location.
In the short term this can be expensive, which is why many projects choose not to do this. However, a recent survey by Dr. Dobb's Journal found that offshoring projects only have a 43% success rate compared with 63% for traditional and 72% for Agile. [i] Considering the risk premium associated with offshoring, we advise that organizations fight against their instinctual "penny wise and pound foolish" strategies. Relationships established with this strategy are not soon lost. As you establish partnerships and relationships with GDD teams and providers, the cost of doing business with them decreases as your working relationship improves. Finally, collaborative technologies such as Wikis, workflow management systems, and email are even more important for GDD teams as compared to non-GDD teams. We like to think of tools such as this as a minimal requirement for any team, but they're clearly not sufficient to address all of your communication needs.
Towards an Agile Strategy
When organizations first adopt iterative techniques within a GDD environment, they typically adopt them for the development team but still leave quality management and testing for later phases of the lifecycle. As Barry Boehm pointed out years ago, the average cost of addressing a defect rises exponentially the longer
