Ade Miller of Microsoft on Distributed Agile: things the platforms and patterns group has learned running distributed teams.

The slides should be on his blog, but a few points jumped out at me:

• Colocation not only lowers the overhead of communication, but also removes all that thinking you otherwise have to do about how to communicate;
• There are many types of distributed team - from completely distributed (a level playing field, no-one colocates with anyone else) through distributed-by-function (builds walls between disciplines, loses bandwidth, trust and availability), to ad-hoc distribution (e.g. everyone colocated except one guy "who will hate you") and teams distributed across time zones (often doing "follow the sun" development where stories are handed off as working days start and end);
• Were they not distributed, many of the practices of distributed teams (handing over work, communicating by email only) would be considered dysfunctional!
• Trust is easy to lose in such teams, generating a "them and us" atmosphere; dissipate this by relocating teams periodically, humanising remote team members using photography, or actively building a shared sense of humour across teams;
• Many agile practices assume everyone is together - e.g. pairing, story cards as placeholders for conversations, standups. "You need to step back from the practices and look at what they're trying to achieve";
• Conway's Law: your software will start to resemble your organisation, if you let it;
• Bandwidth is important for distributed projects, poor availability of bandwidth will preclude options like videoconferencing;
• Travel at the start of projects builds trust, but also do it before large releases, at the very end of the project (for retrospective and ship party), and maybe on regular rotations;
• Got one remote developer? Use a "buddy system" - assign someone specifically to represent them and look after their interests within the team;
• Tools can make it harder for you to modify your practices; they tend to be set in stone. They're more important when you're distributed, but aren't the be all and end all;
• Continuous Integration is more important with distributed teams, where it's tougher to keep things in sync. Use widgets or system-tray resident tools to replace Big Visible Charts and promote the state of builds to developers;
• DO adapt. DON'T follow stock practices. You're breaking the rules already by not colocating, so you may need to break others to get it working;