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?
Like this:
Like Loading...
Tags: Agile 2008, distributed