My experiences with distributed Agile software development
Posted by Marco Mulder in the late evening: August 13th, 2008
I have been a Scrum Master on one of our distributed Agile projects for about a year. I would like to tell you about how we do such projects and share some of my experiences. If you are having a bad time with offshore software development, try not to get too jealous because we are having a great time at it 
The key elements of our approach are:
1 - We hire the best people using a rigorous technical assessment procedure.
Almost three years ago I chose to work for Xebia because of the enthusiastic, incredibly smart and skilled people that work there. This is still the biggest reason for my fondness of this company. Having worked closely with my Indian colleges has extended this experience in interesting ways. I am as much inspired and impressed by them as by my Dutch colleagues. Besides that, they take initiatives to organize very cool events like an Agile conference that I attended and a visit of Tom and Mary Poppendieck.
2 - Teams are distributed, on site and offshore team members jointly take the teams' responsibility and work closely together as One Team.
We have chosen to structure our project teams so that each team contains Dutch and Indian team members. This works even better than I had expected when we started to work in this way. Doing daily stand-up meetings (with web cams), joined planning and retrospective meetings and having lots of intermediate interactions work great for team bonding across geographical boundaries. When I visit India or when Indian colleagues visit us, we feel like we already know each other pretty well, even if we meet in 'real-life' for the first time! I have asked several of my Indian colleagues to compare their One Team experience to earlier offshore experiences at other companies. Al of them liked the fact that there is no 'us' and 'them' feeling in this approach. We're in this together and if we encounter some problems during a project, we all know the ins and outs of it and will not start to blame 'the other side'.
3 - We share our software development and collaboration tools using one wiki, one code repository, one continuous build system, one mailing list etc.
I have learned that software development in a highly distributed way like we do can be done using mostly mainstream tools like Jira, Bamboo Confluence and Subversion. Also the tools that we use specific for communication are pretty basic: Skype, VNC, web cams, microphones, speakers, headsets. The only critical thing you need is a good internet connection on both sides. The biggest technical problem that we faced was that frequent power failures in India caused hiccups in our network connections. This got solved by the better use of UPSes. Some other problems were actually a lot of fun to address, like the way we manage to share obscure hardware.
4 - We work in short iterations.
On most of our projects we work in two week iterations. Before I started to work in two week iterations, I was afraid that this might be too short. I especially felt that the overhead of planning and retrospective meetings might become too big. Now that I'm used to two week iterations, I would not like to go back to longer iterations. The workload is evened out much better over time. In my past experiences, projects that had longer iterations usually had relaxed beginnings and stressed endings of iterations. It proved to be hard to get a team focused if work did not need to be finished within one or two weeks. It turns out that the disadvantage of the overhead of planing and retrospective meetings in two-week iterations is manageable, but it is important to take care that these meetings are done effectively and timely.
5 - On site and offshore team members are collocated during the initial 2-3 iterations of a project and there are frequent exchanges of team members between the two locations.
Even though I was surprised by the level of team binding that can occur if you only see each other on the other end of Skype session, some communication is more effective if you're at the same location. Especially in the beginning of a project if you start off with a group of people that still needs to become a team, being at the same place helps a lot in helping the formation of One Team. It is also a lot of fun to get to know each other better while drinking beers (or cola) in a pub together. What makes you tick, how do you live, what did the place where you grew up look like? Besides having had a great time at the project I feel that I have also learned plenty of new things on a more personal level.
Archives
Training
- Workshop Agile Management
Custom made, in-company
Xebia Sites
Categories
- Java (279)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Quality Assurance (14)
- Middleware (19)
- Frameworks (13)
Excellent blog. You captured the essence of it all very nicely.
I personally believe the above 5 points are absolutely necessary for any distributed development effort to be successful.
Good post… it takes six month before a new joiner can contribute in an Agile team if he was not exposed to the right kind ‘Agile’ before…
The problem is even deeper when you are working in different timezones having 12 hours of time-difference. Finding the overlapping between two teams becomes even more difficult. In that scenario, it requires a bit of adjustment from both sides. Sometimes one team comes a little early and sometimes other team. Instead of the whole team of one side staying late, people rotate at the time distributed standup and stuff like that. Once in a week both teams stay together. The most important task is to have as much as communication as possible which may include initially collacating team as mentioned in the blog. Xebia India executed one such distributed project successfully.
Hi Shrikant. That is a very interesting case. I think that a description of experiences on this project deserves it’s own blog!
[...] Mulder in the early morning: August 18, 2008 Recently I wrote a blog about the way that we do distributed Agile projects. Martin van Vliet and I have also published an article on InfoQ about one of them. So if you want [...]
A comprehensive post is very useful for those who needs information about distributed development system, thanks.. for sharing this.
Nice read. I would disagree with the comment that it takes 6 months for a new to Agile developer to contribute to the team, we have seen developers contribute in the first few weeks – but I do believe some developers can work in Agile and some can’t based on personality.