Distributed development projects are a 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.
Distributed development has various challenges and benefits, that depend on how much effort you put into it. Working with remote teams has many communication challenges, which I will discuss with you in part 1 of this 2-part article.
But first, why do companies do distributed development? There are many reasons such as expertise, cost and availability of resources. If your development team is lacking critical skills, it can be useful to work with a remote team that has the expertise you require and then learn by osmosis.
Another reason to take part in 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 centres in countries such as India and China. The dirty little secret of offshore development is that 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.
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 a project in distributed teams with a combination of types of teams.
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 to 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.
Since there are 24 hours in a day, haven’t all project managers dreamt at some point of having developers working on their project around the clock? For obvious reasons, 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 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 level of basic vocabulary where you 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 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. You also need to find ways to communicate effectively between teams.
Collaboration tools such as Teams, Zoom or Miro 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.
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 want 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 related to building teams as 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.
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, everyone 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:
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.
It is frustrating to find yourself in this situation, because you could have done the work using local developers and the communication would probably have been better.
The lesson here is 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 of trust and cooperation. A culture where people can ask questions to team leaders and get support from them in resolving their problems.
Stay tuned for part 2 of this article, where we will discuss designing processes to keep your teams on the same page!
This is an edited version of the first ever article published by Steffan. Dr. Dobbs Journal published a shorter version of the original in their August 2007 issue.
