When I look at the prospect of a distributed development effort, it scares me. So much depends on having the right people, good communicators, in the right places. So much depends on merging of cultures successfully. But more and more distributed development is taking place.
So how do you increase your chances for success? I'd like to focus on four key areas.
- Process and Management
- Communication and meetings
- Reviews and Approvals
- Tools and Data Repository
Why only these areas? Because I feel the rest of it is not a whole lot different than for a single site. Ideally, the goal should be to make these four areas behave as if the distributed development were being done in a single site.
Process and Management
Management deals with process. For certain, having managers which are not territorial and can communicate easily is a key. But having effective, well-defined processes is even more so. Good management happens when good processes are defined and followed. The difference between a poor and a great manager is far less when there are good processes and good tools to support them.
Processes may be tailored to time zone differences, but they should generally be "universal" - that is, they should apply across all sites involved in the development. Universal processes make management easier.
Ideally, your process will work equally well for a single site as for distributed development. A good tool will help you to support and enforce your process. If your process is defined by repository data, you should be able to update your process at all sites at the same time through a normal data update transaction, depending on the type of repository solution you have in mind.
Communication and Meetings
Communication across distance is essential - even if its just to put a voice to a name. If you're doing distributed development these days, for sure you will want some video-conferencing capability, even if it's just from your desktop. Putting a face to a name is better than just a voice. It's important to hear someone's tone. But watching someone's reaction is also a huge part of communcation. If you don't believe me, ask your spouse. For this reason, I'm really surprised video phones never caught on - maybe after the VOIP revolution.
Good telecommunications tools are a big help, but your repository and process tools can also help immensely with communication. If all of your data and your processes are defined through your tools, your communications and meetings can focus on non-compliances and variations. Reports and status information is available before the formal communication begins. Watch your tool selection carefully - it should be the hub of your communications. Track meetings, or store the video and/or messenger clips directly in your tool. Being absent from a meeting is a lot worse across distance, so do all you can to let your participants timeshift their participation.
Reviews and Approvals
Reviews and approvals are a special form of communication. Especially where there is a significant time zone shift, your tools must provide help here. To-do lists, electronic approval, document repositories and change-package based code reviews help to ensure that a review can be done as necessary - even without holding a meeting. Written reviews are always recommended - they are more objective, leave an audit trail, and provide a checklist for post review actions. Even better, they work well within a distributed development constraint. When a change-package based delta can be generated from your CM tool, a single change identifier can be used to identify the code review task. Code reviews can be done on-line by anyone at any time.
Good tools should not eliminate oral communication. Some things will always have to be discussed, even if its just to clear up the mis-interpretations read into the tone of a less objective review. Significant issues, or issues that go back