Initiating a Distributed Agile Project
One of the first things that any disciplined agile team will do—and this is particularly true of distributed teams—is some initial up-front modeling, including both requirements envisioning and architectural envisioning. In the case of the project team, they worked with their product manager to identify a collection of core user stories which defined their initial scope, and based on that they defined the initial core architectural concepts to set their technical direction. Defining the architecture up-front enables distributed teams to organize themselves effectively, something discussed below.
Disciplined agile teams also do some up-front, high-level planning to identify their major dependencies and milestone dates—you don't need a monolithic, 1000+ task Gantt chart but you do need to think things through. Effective teams do this planning with the developers actively involved (they are part of the team after all), they strive to consider all associated costs, and in particular they don't overlook the low probability/high impact risks which often prove to be project killers.
Another critical strategy is to get the whole team together physically at the beginning of the project. Your goals are to build rapport amongst the team, to get to know the people that you're working with and thereby facilitate communication later on, and to better understand the situation on the ground. Although flying people around increases your initial expenses, it is an investment that pays for itself very quickly in overall risk reduction. My experience is that the least expensive way to pay for travel is to actually do it, the most expensive way is to not do it and instead increase your communication risks through documentation and bureaucracy. Sadly, this strategy is commonly sacrificed on the altar of fiscal short-sightedness, again increasing project risk.
Organizing a Distributed Agile Team
A best practice for distributed teams, described in detail in "Lean Development Governance" (https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang= en_US&source=swg-ldg), is to organize your team structure around the architecture so as to reduce the communication required between various subteams. When you analyze the communication which occurs on software development teams the majority of it is between people who are working together to build a subsystem, so organizing the team around your architecture reduces overall communication risk. This is why initial architecture modeling is so important—by identifying the subsystems, and then investing a bit of time to define the interface to each subsystem, you put yourself in a position to let the subteams focus on their own work. The architecture owners on each subteam will still need to coordinate interface changes with each other, something I discussed in detail in my July 2008 column (www.ddj.com/architect/207600615). This architecture practice is called "API First" in the Eclipse Way, an agile methodology for distributed teams.
A very serious mistake would be to organize your team around job function, for example having a team of business analysts, a team of designers, a team of testers, and so on and so on and then try to shuffle work back and forth between these groups of specialists. This strategy increases the overall bureaucracy, and therefore overall cost, because you need to write more documentation, hold more documentation reviews, invest more effort in traceability, and so on to support this sort of team structure. It also increases the chance of finger pointing when things don't go so smoothly—working software is an order of magnitude more concrete and measurable than documentation that, therefore you can easily determine the value of what a subteam has or hasn't produced.
The one time to break this rule would be on an offshoring project with independent testing, described in "Scaling Test-Driven Development" (www.ddj.com/architect/205207998), where you have a small number of highly skilled testers who do complex forms of testing in parallel with the development team. By having the independent testing done in parallel by a small team at the customer site the customer effectively monitors the overall progress of the team and the quality of their work while decreasing the need for up-front detailed specification, onerous milestone reviews throughout the project, and time-intensive comprehensive testing at the end of the project (you'll still need to do some testing at the end of the project, but nowhere near as much).
