I once worked for a company that prided itself of doing distributed agile. The vision was to have one team split across two different country so that work could continue around the clock. They had the development team in Chicago and a testing team in India. Work completed in Chicago at the end of the day, 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 that these projects didn’t deliver the cost benefit that had originally been forecasted. Some projects were marginally cheap, but most were more expensive. We also found that there were several patterns that the successful projects followed:
- Forming the team in a single location. The entire team was flown out to India to work on the product for about 3-4 months. Only once the personal relationships had been establish was the team then divided and the team members returned to their country of origin.
- Transfer skills (aka the Ambassador pattern [1]). The team forming pattern was not sufficient in itself. 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 integrated with CI. Nothing kills a conversation like “Well it works in my version.” Simply having a common codebase (that’s integrated continuously) avoids many misunderstandings.
Establishing a common codebase for a distributed team can be a *very* difficult thing to do, and I would suggest that if a client cannot do it then they are not ready to do distributed agile. - 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] http://www.keithbraithwaite.demon.co.uk/professional/papers/2005/europlo/patterns_distributed_xp.pdf
[2] http://martinfowler.com/articles/agileOffshore.html
Filed under: Planning, Project Management, Scrum , distributed, distributed agile, distributed scrum, distributed software development, Planning, Project Management, Scrum
[...] Kane Mar describes patterns in distributed teams and Scrum from his experience in this article. [...]
Follow the sun approaches have always been an interesting concept, however it is a concept that needs to be implemented correctly. As you have mentioned, factors such as communication, common code bases etc need to be considered.
I think if it was planned carefully, distributed Scrum could work. The only real issue is real communication between the teams. As it is a follow the sun approach, questions have to be asked, then wait for another day for the response.
Regards,
David
jacksguides.com