Distributed Scrum and patterns for success

This article is part of my online newsletter called the Scrum Addendum. If you enjoyed this article you should signup for the complete series.


Distributed Scrum (i.e. Scrum that takes place in multiple locations) has been talked about for several years. Although it sounds exciting, there are few (if any) successful case studies. I believe that there is a reason for this lack of empirical data: distributed Scrum is significantly harder and less financially rewarding than the practitioners would like us to believe.

I once worked for a company that prided itself of doing distributed Agile. Their vision was to have one team split across two different countries so work could continue around the clock. The development team was in Chicago, and the testing team was in India. At the end of each day, the work completed in Chicago was tested in India overnight … or at least that was the sales pitch.

We ran several projects in this fashion, and to our dismay we found these projects didn’t deliver the cost benefit that had originally been forecasted. Some projects were marginally cheaper, but most were more expensive.

Looking at the successful projects, we found that they followed several patterns:

  • Co-located team at project onset. The entire team was flown to India to work on the product for about 3-4 months. Only once the personal relationships had been established, the team members then returned to their country of origin.
  • Ongoing transfer of team members (aka the Ambassador pattern). Having the team located together at the beginning is not the only factor of success, We found that there needed to be consistent and ongoing transfer of team members between the two locations. For example, an architect (from Chicago) might work in India for a period, and a test lead would work with the developers in Chicago.
  • Common codebase was integrated with CI. Nothing kills a conversation like “Well it works in my version.” Having a common codebase (that’s integrated continuously) avoids many misunderstandings, but establishing a common codebase for a distributed team can be a very difficult thing to do. I would suggest that if a client cannot do this then they are not ready for distributed Agile. [1]
  • Multiple methods of communication. All the successful teams used multiple channels of communication: IM, Skype, conference calls, video conferencing etc.

I think the jury is still out on distributed Agile. Although there are many reasons why you might want to do it, my personal experience is that saving money is not sufficient.

References

[1] Offshore Agile by Martin Fowler

Comments are closed.