Skip to content
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?