I wanted to see this talk by Guido Schoomheim since Black Pepper has been worked on distributed Agile development projects now for a year or so, between sites in the UK and I was interested to hear Xebia experiences. Xebia have a team distributed between their offices in The Netherlands and in India.
Guido started his talk by discussing some interesting statistics regarding the costs of traditional outsourcing. He compared the costs of doing the development locally using a "hyperproductive" agile projects verses standard outsourced waterfall development. In the standard model, when one outsources to a very distant company with a different culture and especially in a different timezone, one has to define exactly what one wants in very detailed specifications which lead directly to a waterfall approach.
His figures suggested that to get the return on investment that one needs for a successful outsourcing project over for example a two year period then the cost of the outsourced team must be about 10% of the alternate local agile team's costs, or even less. However, typically one finds that outsourced teams are about 30% of the cost of local teams. Therefore, he suggested, taking a project that could be done locally with an agile team and cost $2 million, if outsourced to a traditional waterfall team, then that same project would cost around $6 million. Very interesting figures indeed and something that I feel is right and empirically sounds right from my experience of customers who have outsources, however I want to do more research before accepting these figures.
Having laid out some of the well known problems of this traditional approach to distributed teams, especially across continents, he described how his project had addressed them.
The basic principal was that, if we have already decided that Scrum and Agile development is the way forward, then just because we want to distribute teams we shouldn't give that up and return to a waterfall model. He described how in his experience they could run fully distributed Scrum projects between The Netherlands and India. They performed exactly the same process as they would if the team was co-located. They held daily stand up meetings (at a time when everyone is in their respective offices), they had their standard project and sprint backlogs (all shared via the Internet) and they had their standard two week iterations. Video conferencing was key to this he felt so that the team could see each other and read each other's body language. The video didn't need to be high quality as long as it was good enough. A web cam and standard VOIP was good enough.
Since agile is all about the people, they made sure that at the beginning of the project that the team was co-located for the first two or three iterations so that everyone on the team could build the right interpersonal relationships.
To me this all sounded great and not a lot different from how we go about distributed agile projects, which I found greatly reassuring. I was a little surprised though that he didn't talk about how they ensure that the team is working well together other than with their standup meetings. They don't do remote pairing, primarily I guess because of the latency between The Netherlands and India. Personally, I think that this is one of the main reasons why our own distributed projects work.
Pairing is key in my mind to fostering shared ownership and responsibility for the code throughout the team, making sure that everyone knows at least something about all of the code and that there is no important piece of code that only one person knows about. If you have a team spread across two or more sites then it's very tempting to split responsibility. Team 1 works on part A and team 2 works on part B, and unfortunately no-one on team 2 ever really gets to know and more importantly feel jointly responsible for part A of the code.
In my experience, remote pairing can work very well, though I'd like improve the tools I have. At present we use remote desktops and VOIP for a pair to work across locations. It works very well, but requires a good network connection. I had hoped that Guido would be able to suggest an improvement.
Anyway, that aside, it sounded like the approach was working successfully for them.
The key message was that just because the team is distributed, one must not forget the advantages of agile. One can run agile projects with a distributed team and it can succeed. That's certainly what we've found too.