My first thought is to have each team be independently agile, and avoid trying to be a single team across timezones and continents. So far, I've not seen "one team, multiple locations" work well. In fact, I've seen it fail when the two teams were only one hallway away from each other.
I think that you can have Scrum of Scrums and try to plan work in such a way as to minimize dependency, but you are going to be victim to conway's law or you are going to exploit it. Multiple products that integrate might work, but sharing one big project is not something I would bet on.
In a related topic, Jeff Langr and I recently spent time as remote pair programmers on a team that was centralized. We were able to use technologies to pair with the collocated team members, so we could do TDD together, attend meetings, and be regular members of the team. Technologies for doing that are always improving. It is best when you're not very much separated by cultures and time zones.
The distributed teams question is always an interesting one. We did one card, The Only Agile Tools You'll Ever Need, which ruffled a few feathers. Basically we suggested that moving in the direction of more distributed is moving in the opposite direction from agile values--primarily the value of "high levels of face-to-face communication."
Tim's right, there are many technical solutions that help. But recognize that you are making a concession to a sweet spot that can really work well, and the technical substitutes pale in comparison to just being there. The better answer is "shift your teams so they don't have to be distributed." One team in Dallas, one team in Krakow, one team in Bangalore, etc., instead of three teams each distributed across three geographies.
Agile aside, there are studies that show it takes years to obtain true positive return on investment with a distribute teamd. While the bean counters looking only at hire rates may quibble, it takes a long while and a lot of wasted effort to work through the inevitable issues of distributed teams (which do include quality).
As a remote guy for a year, I realized there were so many things I missed out on, to the point where I felt I wasn't as real a part of the team. It's also a lot harder to obtain consensus and enact lasting, positive changes in such a team.
You can make it work, and Tim provides a few suggestions. (Cameras are essential, and not just face-to-face cameras--you need to be able to see the teams as well in their work areas and in meeting spaces.) But is that really what's best for your company and product?
I have done at least one distribted Agile (Scrum) project at my company that worked quite well (see http://www.xebia.com/distributed-agile). One of the critical factors that made Agile work for us was that the whole team was collocated for the first four weeks (2 sprints) of the project, and we kept on bringing the whole team together at regular intervals afterwards (1 sprint every 4 to 6 months).
Sonny Gill wrote:One of the critical factors that made Agile work for us was that the whole team was collocated for the first four weeks (2 sprints) of the project, and we kept on bringing the whole team together at regular intervals afterwards (1 sprint every 4 to 6 months).
Great point, thanks for adding it Sonny! Same thing--agile or not, it does boil down to building a good team that understands each other and can work together well. That's best done with co-location; the more, the better.