#2782

Agile 2008 – Distributed Agile

This is a dump of all the suggestions that came up during the “What Makes Distributed Agile Projects Succeed (or Fail)?” workshop by Chris Sims on Tuesday afternoon. I’ve highlighted the ones what the group agreed were the top three.

Friday 8th August – I added some additional notes they’re marked [Ade: …]

• Planning overhead is higher for distributed teams so shorter iterations are harder
• Get the whole team together for some iterations – on site visits for remote people
• Be aware of cultural norms of remote locations
  • Avoid “West vs. the rest” mentality
  • Visits help create personal bonds

• 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 with remote people
  • Use acceptance tests to drive story clarity
  • Have developers review tasks ahead of time to prevent blocking
  • Involve everyone iteration planning

• Use the parking lot to make sure standup is efficient
  • Time boxed daily design meeting right after standup

• Standup might be slightly longer and use a conference call
• Focus on communication
  • Remote people get priority in conversations – a protocol to help them be involved
  • Video conferencing better than voice as it’s harder for people to check out

• Remote people must be determined to be visible
  • Remote people have “buddies” to keep them up to speed on the team
  • Local representative for offshore team

• Don’t fight Conway’s Law – the architecture will reflect the team’s distribution so don’t fight it. Your architecture should be designed to enable distribution
  • [Ade: This implies the component approach to scaling rather than breaking the project up by features Bas Vodde’s says there are risks to doing this. If your architecture accounts for features and your teams are aligned by features then this will fall out but you shouldn’t plan your architecture around your composition.]
• Splitting work horizontally is risky as the customer cares about vertical slices not horizontal components or features
• Well defined definition of “done”
  • Demo early and often – multiple demos per iteration
  • Code checked in to tree

• Use remote pairing
  • Use VNC and Skype for remote pairing
  • When pairing isn’t possible then use code reviews

• Minimize time zones – it’s better to be separated by distance (latitude) rather than time (longitude)
  • Time zones cause teams to be blocked [Ade: this effectively adds wait periods into your value stream, which is really why it has such a big impact]

Some other thoughts…

Some other things I had on my list that we didn’t get to during the workshop. These are based on reading and experiences on previous projects. We didn’t have time to cover all the ideas the group had so there are probably more.

• Distribute work across the team by feature not by discipline – avoid remote test/dev/management teams rather than remote feature/project teams [Ade: on further reflection you should be fighting Conways Law all the way, Bas Vodde had some interesting comments on this]
• Avoid asymmetric distribution – it’s far better for everyone to have barriers to communication than just one person
• Use continuous integration to anchor your team
  • Utilize defense in depth
  • Run additional builds to account for people in different time zones

• [Ade] Source code control systems also suffer from network latencies caused by remote teams. May sure your teams have good bandwidth or use proxies.
• Team churn has a far higher impact on distributed team
  • Keep teams together across projects
  • Especially hard with contract teams where people get reassigned at end of contract

What really struck me at the end of this session was that distributed teams are more dysfunctional than co-located teams – obviously. The act of distributing a team simply adds to any existing problems it might have. The team is dysfunctional because the business chose to make it that way for some other business reason. So…

• Distribute teams to increase talent not cut costs. Really good developers can be more than ten times as productive as mediocre ones. Even really aggressive outsourcing is unlikely to reduce costs by ten times.
• 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?