This is an article I submitted back in the summer of 2007 for publication in DDJ magazine on the challenges teams meet when doing Globally Distributed Development. They took the nibbles that were interesting to them and turned it into a sidebar article in the August 2007 issue. This is the full version of the article I submitted. I originally wrote this in the mindset of being the master team. I’ve been working remotely with a team for the last year, it would be interesting to revisit this topic from my new point of view.

Introduction

Distributed development projects are more and more common practice in the software development world. Such projects are collaborative efforts by teams spread in different locations working together to successfully deliver. Large companies spread across the world commonly have distributed development projects.

Why do these companies do distributed development? There are many reasons such as expertise, cost and availability of resources. If you development team is lacking critical skills, it can be useful to work with a remote team that has the expertise you require and learn by osmosis.

Another reason for distributed development is the cost savings that it can bring. Companies can get more developers for the same money by moving work to offshore development centers in countries such India and China. The dirty little secret of offshore development is part of those savings are initially lower due to communication challenges, ramping up the remote team and getting them to embrace your processes.

Along with cost savings, the inability to find people with the required skill sets in your market may drive you to work with a team in a location where it is easier to recruit the talent with the skills you need.

The theory of distributed development is good but does it really work? I would argue that it all depends on how much effort you put into it and how committed you are to being successful. Working with remote teams has many challenges, which I will discuss with you in this article.

Onshore versus offshore teams

There are different kinds of remote development teams that you may work with, onshore, near shore and offshore teams. It is not uncommon to work on distributed teams with a combination of types of teams on the project.

Onshore teams are located in the same country as you. The communication challenges are a lot less frequent as everyone typically speaks the same language. Time zone differences are easier to manage between the teams.

Near shore teams are located in close proximity of your home country. Teams from Canada and the United States working together are an example of this.

Offshore teams are typically located in emerging nations such as India and China. They are used because of lower costs, expertise or both. When a mainstream product is on the way to being retired, these teams are also used to perform the maintenance duty while the primary development team designs and works on the next generation of the product.

The 24h development day

There are 24 hours in a day and haven’t all project managers dreamt at some point of having developers working on their project around the clock? For some reason, individual developers just aren’t willing to do this. With distributed development, this dream can become a reality.

When working with distributed development teams, depending on how development is spread around the world, coding can go on almost around the clock. But how desirable is this?

Because of the time difference between the countries, effective communication between 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 in order for both sides 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 offshore, you may not get a response or even a fix until the next day, which may have a very negative impact on a release.

One of the side benefits of having an offshore team is that because they are located in a different time zone, they may not be dragged in the meetings that impact the productivity of your local team on a daily basis.

Communication

Communication is one of the biggest challenges faced by distributed development teams. This problem has many different faces such as linguistic difficulties, collaboration between the teams and issues related to different cultures. Some of these issues are easier to address than others.

Linguistic challenges appear in several forms. One of these is a situation where some or all members of the remote team simply do not speak the same language as you. Another one is where you cannot understand what they are saying either due to heavy accents or just plain inability to speak the language.

When encountering these situations, you must create a common low level vocabulary where you do understand each other and work your way up from there. You must also validate the teams understand each other. You can achieve this by asking leading questions about what you are talking about in order to confirm their understanding. Every once in a while, you should repeat back what they are saying to you in your own words order to validate that your comprehension is correct.

Team Collaboration

Team collaboration is critical and teams working in different locations require common source code repositories, requirements repositories and defect tracking tools. You also need to find ways to communicate effectively between teams.

Collaboration tools such as web conferencing tools or NetMeeting can be very useful in allowing both teams to share screens, or work with a shared whiteboard in meetings. Instant messaging tools also help the teams collaborate and communicate better.

I will come back on this later, but processes need to be well defined and documented. All team members should be following them in order to ensure the entire team does the same things in the same way. If you have no documented processes, you cannot expect the remote development teams to be in step with your way of doing things.

You need to ensure information flows amongst the teams and that all teams evolve to become equals. Enabling people is what team collaboration is all about. Don’€™t let your team do all the heavy lifting. That is detrimental to letting the other teams help you be successful.

Beware of the people with strong personalities on your team that do not like to collaborate or that may to make the other teams look bad as much as they can. These people have typically worked on the product for a long time and may feel that you are looking for their replacements.

My favorite example building teams that are equals revolves around code reviews. In these situations, the main team, especially at the start, may feel they need to review everything the other team does. This is good of course. But moving forward, you must involve people from the remote teams in the code reviews of the main team. This brings two important benefits. First, knowledge of the code base spreads during the code reviews. Second, you get another pair of eyes (and in this case, possibly a fresh and objective look) that is looking at the code.

Culture Differences

You need to understand the culture differences between your team and the remote team and find compromises when required in order to keep the project running properly.

You also need to be able to distinguish culture differences and bad habits. The bad habits (such as not sharing information with other team members, not doing code reviews, bad coding practices, etc…) need to be discouraged and weeded out as you go.

One of the biggest challenges I’ve seen in regards to culture differences is the inability 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 having one of the teams simply saying €”œ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 address this situation. You can provide them with a bulletproof set of requirements with supporting documentation or you need to have them document the requirements and review them.

Here’€™s a real life example I’ve been through before. I had spent hours with the team designing a solution to a problem and when we were done, every one understood and agreed this was the right solution. When the code was finally delivered, I realized that the problem was not solved. I discussed this with the team and was told that the original solution did not work so they went in a different direction instead.

When I asked them to explain what went wrong with the original solution, I realized by listening to their explanation that they did not even understand the solution at all. So now, a few bad things had happened:

• They did not understand the original solution
• They did not communicate this to me so that I could help them
• They went off their own way (which could have been bad if other teams depended on them for API’s for example)
• They delivered something that did not work

To resolve the situation, I sat with the developers and wrote the code with them, making sure they understood step by step what we were doing and why.  In the end, the original solution worked out just fine, they just never understood the solution and had not said anything about it.

When you are in this situation it is frustrating because you could have done the work using local developers and the communication would probably have been better. But the lesson here is also that you need to trust people and let them make mistakes, the important thing is that they learn from them and do not repeat them.

I’m not advocating that you give important pieces of code to just anyone. What I’€™m saying is that you need to build a new culture for them of trust and cooperation. A culture where people can ask questions to the team leaders and get support from them in resolving their problems.

Team Processes

In order to be successful in your distributed development project, you need to have well defined processes in place. You need to ensure that everyone on the team works the same way.

Here is a sample checklist of things you need to document before you start working with remote teams:

• What do they need in order to access the shared repositories? If there are any user names required to access them, what are the steps to request them.
• Where are the source code and requirements repositories?
• Where do you get the latest version of the code?
• What is your source code change management process? (i.e.: What are the naming conventions of activity names, stream names? Who is responsible for code merges between different version streams?)
• What is your software development process?
• What is your defect management process?
• What are your change requests and requirements processes?
• What are the coding standards used by the team?
• What are the steps to perform in order for developers to compile the source code?
• What are the standards for automated unit test creation (i.e. JUnit test cases)?
• What is the official build process?
• What do you need to do to get the application up and running for the first time?

As you can see, the checklist is all about enabling people to be able to go off and do what they need to do on a day-to-day basis while requiring as little help as possible. The first step is documenting your processes and the next step is disseminating the information. One way to do this is to have a wiki or some other internal web page where team members can go and review the processes and have them at their fingertips.

Defining your processes is great but they mean nothing if no one is following them. You want your leaders to continually reinforce these processes and take the initiative in communicating with the remote teams when they are not being followed. Set the quality bar where you need it to be and ensure the teams are reaching that bar.

You will be as successful with your distributed development team as you are working with your own team. If you have no processes and your team lives in chaos, well guess what? You distributed development efforts will be exactly as chaotic if not worst because you have just added a bunch of people to your team.

I was in a situation once where I was part of the remote team and the main team had little to no processes implemented. As our team was certified CMM level 5, we had the ability to define processes. So each time we encountered a situation without a process, we created one. When the main team ran into the same issues as us and learned we had processes, they adopted ours as their way of work.

When you start working with a new team, you need to schedule working sessions where some of their developers come to your location. During this time, they will be able to get some face time with your team members and learn about your processes. In order to be successful, these sessions need to be planned and organized. Determine how much time is required for the essentials, and prepare a standard training agenda. If less than a week is sufficient to go through the essentials, have them come down for a week and give them some tasks to allow them to interact with the team.

The challenge with training sessions is that you may not be able to spare resources to give training. In these cases, one solution is to pair them with some of your best people for a week and let them learn your processes by seeing them in action. Make the training part of your process.

If you really do not have time for the new employee training, I strongly recommend you do not do it at all. There are costs attached to doing this. It can turn into a large investment of time and money, so make sure it is productive. Also, look at this as a chance for your team to make a good impression and start building a working relationship with remote team members.

In terms of processes, performing formal requirements, design and code reviews are critical. You can look at these as checkpoints for validating the work to be done as well as to confirm any initial estimates. Involve multiple teams in the reviews and work to avoid the “Big Brother” syndrome where one team tells others what to do without considering their feedback.

Reviews need to be organized as well with everyone having had sufficient time to review any artifacts before the review occurs. Have a moderator that keeps track of any issues that come out during the review and follows up with the people assigned to them until they are resolved.

You need to involve multiple people in reviews in order to have multiple points of views. For requirements and reviews, involve people from the Product Management, documentation, quality assurance and development teams. For code reviews, involve multiple developers as well as a quality assurance tester.

Conclusion

Distributed development is a lot about enabling people and making them an extension of your team. The issues you face day to day with your local team are the same that you will face when working with remote teams. As much as a child is a reflection of his or her parents, distributed development is a reflection of your current development practices.

You will see the good, the bad and the ugly of what you do. To be successful, you need to identify what does not work and find ways to make it work. You need published processes for all to follow.

You need to build trust among the teams and enable people to be successful. To do this, you must foster the notion that you are a single team working together and not multiple teams that happen to be working on the same project.

Finally, you need leaders on each team that care and that want to make it work. These leaders will help foster a supportive environment where people will feel part of a team.