This article is the stripped down version of an article I submitted for the August 2007 issue of Dr. Dobbs Journal.  I had submitted a full article but they had already selected the one they wanted to publish for their issue.  They liked what I submitted though and decided to publish part of it as a sidebar to the article on globalized distributed development.  This is the first article I ever got published anywhere.  One day, I will publish the full version on this website.
Haven’t all project managers dreamt of having developers working on their projects around the clock? For some reason, individual developers just aren’t willing to do this. But with distributed development, this dream can become a reality. With distributed development teams, depending on how development is spread around the world, coding can go on almost around the clock. But because of the time differences among the countries involved, effective communication among the teams is a big challenge. Communicating through e-mail works to a degree, but there is always a lag in the response time. You need to schedule conference calls either early in the morning or late at night for all teams to be available at the same time. The lag is also reflected when you find a last–minute defect that absolutely has to go out today. If your team is geographically dispersed, you might not get a fix or even a response until the next day, which might have a very negative impact on a release.

Communication is one of the biggest challenges faced by distributed development teams. This problem has many different faces such as linguistic difficulties, collaboration among the teams, and issues related to different cultures. Some of these issues are easier to address than others. Linguistic challenges appear in several forms. At one extreme is a situation where some or all members of a remote team simply do not speak the same language as you. You need to ensure that the common terms used in the project are understood by both sides.  Use this as your basic common vocabulary and work your way up from there. You must also validate that team members understand each other. A good technique is to repeat back what a team member has said to you in your own words to validate that your comprehension is correct.

Team collaboration is critical, and teams working in different locations require common source code repositories, requirements repositories, and defect-tracking tools. Collaboration tools such as web and other online data conferencing tools can help the various teams share screens, or work with a shared whiteboard in meetings. Instant messaging tools also help the teams collaborate and communicate better. You need to ensure that information flows among the teams and that all teams evolve to collaborate fully.  Be wary of team members who try to make another team look bad. My favorite example of building teams that are equals revolves around code reviews. In these situations, the main or more experienced team (especially at the start) may feel they need to review everything a newer team does. But moving forward, you must involve people from the remote teams in the code reviews of the main team. This brings two important benefits:

  • Knowledge of the code base spreads during the code reviews.
  • You get another group of eyes on (and in this case, possibly a fresh and objective view of) the code.

You need to understand cultural differences and find compromises when required to keep the project running properly. You also need to be able to distinguish cultural differences from bad habits. The bad habits (such as not sharing, not doing code reviews, bad coding practices) need to be discouraged and weeded out as you go. One of the biggest challenges in regards to cultural differences is the unwillingness of certain team members to say they do not understand what you are saying because it is not appropriate to do so in their culture. The primary symptom of this is when one of the teams simply says “yes” to everything you say without challenging anything or asking questions. Then, they go off and do what they think is required. You usually only know at the end of the cycle that they’ve gone their own way and implemented the wrong thing. There are two ways to prevent this situation:

  • Provide all teams with a clear set of requirements with supporting documentation.
  • Require all teams to help document the requirements and review them.

To be successful in your distributed development project, you need to have well-defined processes in place. These processes range from requirements gathering and coding standards to code reviews, defect tracking, and defect? processing. You need to ensure that all team members follow the same process. Leaders must reinforce these processes and take the initiative of confronting team members when the processes aren’t followed. Set the quality bar where you need it to be and ensure people are reaching that bar. Performing design reviews before coding starts is also critical. By performing checkpoints early in the process, you ensure that you get what you really need.

Distributed development teams can be really powerful but to be successful, you need to see the big picture.  Distributed development is really multiple teams working as one.

Steffan is a senior software developer, project manager, and G11N coordinator for the IBM® Rational® Portfolio Manager core development team located in Montreal.  The opinions expressed in this article are those of the author and not necessarily those of IBM Canada Ltd. or IBM Corporation.