Notes taken from Agile 2008 sessions on distributed Agile: “What Makes Distributed Agile Projects Succeed (or Fail)?” workshop by Chris Sims and Panel discussion on troubleshooting distributed agile team projects

Things panel found most surprising about distributed Agile (DA)

  • There are people at the other side!
  • DA can work well once the proper process and tools are in place
  • We can learn from teams in other places
  • Agile helps to ease cultural, time burdens through increased communication

What makes DA harder than co-located teams

  • Planning overhead is higher for distributed teams. May need to stretch out length of iterations, to adjust for the additional overhead needed for distributed communication
  • Standup and meetings in general take more time
  • Don’t act like your project is co-located – pay the tax for distribution
    • Executable requirements may help a lot – Fitness tests
    • Mini-specs for user stories – need to communicate more in writing with remote people
    • Use acceptance tests to drive story clarity
    • Have developers review tasks ahead of time to prevent blocking
    • Involve everyone iteration planning

What is most important to succeeding with DA

  • Unanimous: Need to get people together to build relationships, get more collaboration. Plan for at least 2-3 times / year. This also helps to understand cultural differences. Build in the cost of these trips into rates.
  • Leverage technology to bring people closer together – video top choice for people on panel. Use video to see each other, point to documents being discussed
  • Strong engineering practices – continuous integration, TDD, pairing, refactoring – on some teams, you can’t go home with anything that doesn’t build
  • Invest in coaching. You can improve scrm abilities by going down and training, spending time. Identify leadership within teams, and work with leaders to be a local proxy scrum master
  • Take time to understand cultural differences – inward (your own), outward (other cultures)
  • Need a well defined definition of done for team to follow.
  • The best way to build teams is through work. Succeeding (or failing) together at something draws everyone closer.

Other tips and observations

  • Time box discussions after standup if they tend to run too long.
  • Decide if people are suited to agile. Do they take pride in and ownership of their work? Do they show initiative? Are they technically strong?
  • A local proxy product owner is helpful
  • Take time to share about culture. Do things like share recipes, talk about movies, etc.
  • Get pictures of team members and look at them when collaborating.
  • Use remote pairing – avoid isolation
    • VNC and Skype are one option
    • When pairing isn’t possible then use code reviews to ensure *some* kind of review happens.
  • Ade Miller in his session notes observes that distributed teams are more dysfunctional than co-located teams. The act of distributing a team simply adds to any existing problems it might have.
    • Be prepared to do additional work to negate the impact of team distribution.
    • Articulate this work and cost to the business. It’s all about delivering maximum value to the customer not about hourly rates of individuals. Overall is the team delivering more value?