Multi-site development

Question

Most of the development teams I have worked with have been geographically dispersed often across several continents. What techniques and tools have you found effective when working with a team which does not sit together in the same office?

Answer 1

I think this question requires a book length answer, but I'll post a few thoughts. I'm currently working in a development organization spread across 4 continents and I have dealt with that scenario for several years. First, it's very challenging and adds a lot of communication overhead. I'm not a big fan of this way of working, but it has become the norm in large companies. I find that it's important to have a more formal development (almost sigh waterfall) process. Everything needs to be written down and reviewed because you can't rely on hallway conversations and meetings. A wiki is a useful place to put specifications and technical discussions in writing and get comments. Make sure that each dispersed group has reviewed everything. There are cultural issues to overcome as well. In some cultures, people will do what they're told and not push back even if they strongly disagree. So, part of the process needs to push people to comment and encourage feedback. This feedback should include formal, written post-mortems on every project. All the groups should use the same source control depot and use some continuous integration tool like cruise control. Get people in the groups to check in early and often. It's even more important than normal with distributed groups. The likelyhood of integration issues increases dramatically, so frequent integration is very important. If possible, everybody should meet each other in person at least once. It can be expensive and disruptive to arrange travel, but it fundamentally changes the relationship that people have when they've met in person. In general, after meeting in person, people are more cooperative and helpful to each other.

Answer 2

Have the following things in place:

• High-level project plan
• Requirements documentation
• Agreed-upon standards and best practices for building the application
• Ground rules for communication and escalation

On a regular basis, have daily conversations with team members. Conduct code reviews and function demos liberally, using remote desktop sharing software. Obviously, you will need to have a good source code control software. If possible, have a get-together once every few weeks or months.

Answer 3

Here are my few ideas:

• Make sure that each project role is represented on each site. Proportion can be different, but team members should have access to representative of each role locally.
• Communication is the key, so it is very important to have some kind of team coordinator on each site. He will be responsible for communication facilitation and should escalate of any major issue arises.
• Common knowledge management utility like Wiki is essential.
• Visit of team members from one site to another greatly help to reinforce the teams and maintain integrity.
• Despite "distributedness" of the team they should be brought together on project start to develop common vision.

Answer 4

My company has developers in a few different locations. What has helped a lot are the following:

• Web based hosting for our Subversion repository (source control), wiki and Bugzilla. It is so much easier to get access to this hosted on the Internet rather than having to go through corporate VPN servers. The wiki has been great for collecting project information.

• Skype. Unlimited free conference calls saves a lot. It is not as good as being in the room next to someone but you don't have to worry about cost every time you pick up the phone.