#2782

Choosing an agile process – Part 4: Offshore development

This isn’t something covered in huge detail in many of the standard agile texts so I thought it was worth it’s own topic.

Patterns & practices teams are usually distributed in some way. This is something that we’ve been doing for a while and have come up with a few things that work and a bunch that, in my opinion, clearly do not. As part of some work I’ve been doing to clarify the best practices we use I started researching some best practices for running distributed and offshore teams.

I compiled this list after reading a lot and thinking about some of the things we were doing. Think of these more as suggestions rather than proven practices used today at p&p:

• Co-locate as much as possible: Whenever possible, co-locate your entire team in one location. If this is not possible then plan for team members to spend periods traveling and working at the main or offshore site, especially at the start of a project – the first few iterations – when key architectural/design decisions will be made.
• Align the team locations: The more offshore locations your team has the higher the communication barriers become. When using offshore team members group them into sub-teams aligned by feature (see below).
• Time zones add further tax: One of the hardest aspects of distributed collaboration is working across time zones. Try to minimize the distance between the team locations as much as possible and try to establish ‘core working hours’ that all members can adhere to.
• Co-locate by feature not discipline: Distributed sub-teams should work together on features rather than be distributed by discipline; e.g. have an offshore team working on a feature not an offshore PM or Test team. Offshoring by discipline increases the boundaries between activities, it’s the old developers build it and throw it at the testers only worse. 
• Pay the tax associated with distribution: Co-location of your team allows them to communicate rapidly with minimal formal processes. If you have distributed team members be prepared to pay the tax associated with this. For example, your specifications will need to be much more complete to offset communication that would have occurred in a team room – you’ll be writing much more complete story cards for example. More pre-work will also be required for meetings, like getting user stories in shape prior to iteration planning so that the team can review and ask clarifying questions via email rather than during the meeting.
• Improve communication where possible:
  • Get good communication going from the outset of the project.
  • Make sure everyone has access to conference phones and reliable Internet connectivity.
  • Consider having an open instant messenger, IRC or conference phone during the core working hours.
  • Provide hands free headsets so that team members can pair remotely.
  • Have a camera on hand for taking whiteboard pictures.
  • Involve the whole team in meetings not just a single local representative.
• Provide appropriate tools:
  • Make sure that your SCCS and other team tools will function effectively across each remote site. For example consider adding a TFS proxy server at remote locations.
• Focus on team consistency: It takes time to build up good working relationships, especially on distributed teams. Try and minimize churn on teams so that this is not lost.

Just to be completely clear I am not anti offshore development but my experience is that there are definitely good and bad ways to do it and there are taxes associated with doing it that aren’t always taken into account.

Further reading:

Here are the sources I used when compiling this post:

Scaling agile – Agile 2007 Experience reports session
Offshore outsourcing and agile development – Forrester Reports
Using an Agile Software Process with Offshore Development – Martin Fowler
Internationally Agile – Matt Simons
Scrum and XP from the trenches – Henrik Kniberg

Technorati Tags: Agile,Methodology,Process,offshore