Distributed Agile Teams in Action
I just got back from the Agile Open Northwest conference in Portland, Oregon. It was an Open Space event, so there were no pre-planned sessions or speakers, but it turned out to be one of the best events I've ever been to. Many of the pioneers of the Agile movement were in attendance, along with over a hundred interested and energetic practitioners.
Back to the point.
I facilitated a session on Distributed Agile Development, where I wanted to hear what people were doing in situations with:
- Distributed Customers (customers not co-located with developers)
- Distributed Development Teams (more than one development team, each in a different location)
- Dispersed Teams (no one on the team is in the same location)
The resulting discussion was very enlightening. Not only were people doing all three of the above, but they were making it work. We uncovered some general principles that attendees pointed to as critical in making a distributed effort successful.
- Build Trust Early
There was wide consensus that personal connections were the most important piece to building trust. An initial investment in travel to get everyone on the team together to meet in person, learn a little about each other, and to start to bond seemed to be the critical step.
- Maintain Regular Communications
Once the team had formed some initial connection, the next insight was maintaining that connection. While this wasn't always done in person, teams that reported success often had daily teleconferences, video conferences, or relied heavily on instant messaging.
One team that had some members onsite, and just one or two working remotely had a strategy of rotating a remote member every few weeks to have them work onsite to refresh their personal connections.
- Communicate At the Lowest Common Denominator
One surprising insight was the idea that if part of the team is co-located, it was actually preferable for them to behave as if they were remote. Co-located teams called in individually rather than gather together in a conference room.
The counter-intuitive principle was to keep everyone on the same footing by using the lowest common form of communication. By not having some people enjoy face-to-face contact, while others were "just listening in" as second-class participants, teams were able to build more trust and feel more engaged.
There was much more said, but I found two themes most interesting. First, companies are continuing to move towards more distributed development through outsourcing, work-at-home initiatives, and using external resources. More importantly, the use of Agile methods is helping projects that do choose a distributed model to be more successful, both in terms of business outcome and team satisfaction.