A while back I wrote a white paper on Distributed Agile Development at Microsoft patterns & practices based on the experiences of the distributed teams at Microsoft patterns & practices.
There were a couple of things that didn’t make it into the paper which should have and in the year or so since I wrote it I’ve also discovered more stuff that may make it into an updated version at some point.
I’m presenting some of that work at Agile 2009 next week in Chicago and as part of thinking about the presentation I wrote a series of blog posts on some of these things. Hopefully I’ll learn more at the conference and expand this list in September when I get back.
Here they are—in no particular order:
Rotate remote team members throughout the project
Another additional strategy to improving communication and trust is to rotate remote team members through the main team room. Teams at p&p often arrange to have remote developers travel to Redmond 1-2 weeks out of every 5-6. This means that one member of the remote team is pretty much always with the core team and can act as a representative for their remote teammates.
Continuous integration is really important
On some levels CI is about Big Visible Charts and publishing project status. CI can provide a cheap, automated mechanism for updating the team on key pieces of status. You can also use it to “remind” the whole team of development ground rules. For example, a reduction in code coverage or an increase in the number of static analysis errors can be configured to break the build.
Trust boundaries are significant
There are some interesting parallels to be drawn between very large scale software projects and very distributed ones. Essentially one of the things that breaks down as projects get larger is trust. People on different teams don’t know each other and therefore have very little trust. The same goes for distributed teams. Much of the focus around communication, travel and working side by side when and where possible is largely about building trust.
Taxonomy of distributed teams
Distributed teams come in all shapes and sizes. Understanding how your team is distributed and the sorts of limitations that places on them is key to being successful.
Tooling is a third order effect
Understanding the People, Process, Tools triangle. Distributed teams tend to rely on tools more than teams working in the same room because tooling can help improve communication and broadcast data—like big visible charts—outside the team room. It’s important that your tools are aligned with the process you’re following. If they’re not then the team will end up fighting against the tool not working with it.