Greetings from Agile2008 in Toronto! To say that I have been overwhelmed by the conference would be an understatement. With 1600+ agile folks here, I am constantly running into old friends, people that I met at previous conferences, and my agile heros. The sheer volume of knowledge and expertise that is being shared is beyond my ability to describe. Wow!

Tuesday, I facilitated a session titled:
What Makes Distributed Agile Teams Succeed (or Fail)?

The session drew about 15 people, almost all who have significant experience on distributed agile teams. As was the case at Agile Coach Camp, the level of experience in the room led to some rich discussions. In 90 minutes, we generated and ranked 25 success/failure factors for distributed agile teams. We used the Group Wisdom Without Groupthink process, which was fitting, as the keynote speaker at the conference was James Surowiecki, author of The Wisdom of Crowds.

Here is the ranked list of success factors for a distributed agile team, as determined by the group.

Tier One – The definition of “done”
This was brought up as the number one thing that derailed projects, or kept them on track. Having a well-defined, well-understood, and well-enforced definition of what it means to be ‘done’ with a story, can keep a team from getting mired in unexpected work near the end of the development cycle, and prevent the accumulation of technical debt.

Tier Two
Demos early and often
Onsite training
Executable requirements
Pride, ownership, and initiative from team members

Tier Three
Avoid “West vs. The Rest”
Daily standups – Doing whatever is needed to make them work for the team
Remote pair programming
Design for Conway’s Law
Everyone is present at iteration planning

Tier Four
Cultural training, including on your own culture
Determination to be remotely visible
Team task selection, just in time instead of ‘assigned’ at beginning of sprint
Video conferencing
Mixed experience levels on all teams
Awareness of cultural norms
(Hmmm, perhaps this and cultural training could have been combined. Perhaps they could have even been grouped with ‘West vs. Rest’)

Tier Five
Avoid time-zone blocks
(e.g. the Pune team can’t move forward because they need something from the Chicago team)
Some co-location, especially at the beginning of a project
Have the right team (hire people who will fit into the distributed environment)
Time-boxed stand-ups
Attention to iteration length
Daily, time-boxed design discussions
Don’t pretend the distance isn’t there
Give the ‘remote’ end of the conference call priotity in all discussions
(The idea is to pause all ‘local’ conversation whenever the folks on the conference call speak. It sounds simple, but it can have a powerful effect on how included they feel)
The “Buddy Concept”, each person has a remote ‘buddy’

You may find it interesting to compare these results with those for groups who have considered the question: “What makes agile teams succeed (or fail)?”
Dr. Dobb’s Architecture and Design World
Agile Coach Camp
The BayAPLN
The 2008 Chicago Scrum Gathering
P-Camp, a gather of Agile Product Managers
Silicon Valley Code Camp 2007
Agile Open California 2007

Cheers,

Chris