Distributed Scrum
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
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
Kane:
I’ve been using distributed scrum for almost 2 years. It takes some rigor, but I feel it works just as well (or, on occasion, poorly!) as co-located scrum.
The keys to our team structure are: 1) rigorous enforcement of daily standup — usually somewhat uncomfortably early in the a.m. for the Seattle-ites, somewhat uncomfortably late for our European/East Coast team time zones; 2) shared code base – no one develops extensively locally and expects to check in code; 3) continuous build environment – when it breaks, you fix it right away! 4) clear handoffs of tasks to the teams who will be awake in the next hours.
Another trick we use is opening up a group chat so we’re all solving problems together — not individual emails/calls flying around where half of us are in the know and half are out.
It’s not perfect — what is?! But I think distributed agile teams are the way of the world going forward, so we need to figure out how to make it work. I think it’s worked for us.
Thanks!
Barbara