Wednesday, November 26, 2008

Productivity of distributed teams

Jeff Sutherland and Guido Schoonheim recently gave a presentation on the experiences on forming a team for Xebia distributed between Holland and India. Their shocking conclusion: a fully distributed scrum team has more value than a colocated one.

They claim the benefits of distribution are cost reduction, availability of talent, and scaling up/down with knowledge retention.

They claim their approach accomplished the following results on a relatively complicated system with 100k+ lines of java code.
  • 95% of defects found within the iteration a feature was developed
  • only 50 defects found in acceptance phase
  • less than 1 defect for kloc
  • 15 function points delivered per developer per month. Note that Mike Cohn has published results of a small co-located team that achieve 16 FP/dev/month
How did they accomplish this state of hyper-productivity, as they call it? Here are some of the highlights.

  1. Bring the Indian team to Holland for 2 iterations starting the 2nd iteration. Establish personal relationships, shared agile value system, common mindset, mutual respect. My team at Envysion successfully used a similar approach; we had the Chinese team members on-site with the client for 2 months at the beginning. See my previous post for more info.
  2. A few people from each site travel to the other location every 2 months or so to maintain the bond.
  3. Staff with equally skilled people in all roles in both locations
  4. Use video conferencing for daily stand-up meetings, retrospectives and planning meetings. The sprint demo was done only by the Holland team because stakeholders wanted it presented in Dutch language.
  5. They started with a single team, then when they expanded to multiple teams, they seeded those teams with people from the first team to maintain the culture.
  6. They maintained discipline to follow XP practices, including pair programming
  7. Had a clear and disciplines Definition of Done for each sprint, which included 90% unit test coverage and fully automated functional and regression tests

1 comment:

Anonymous said...

Sure, depending on your definition of productive. A distributed team (or large teams for that matter) require a more structured development environment. Im talking about things like more explicit requirements, testing frameworks etc. If you are comfortable investing in that level of infrastructure you are already willing to give up being truly productive.

If you are seeking top productivity in a project, you have to be willing to abandon this in favor of tiny teams of the best people you can get and give them constant access to the customer (which is usually impossible from a distributed sense). And if you think your project is too big to do this, its just like the 500 line function - its probably not granular enough.


just my .02