By Serban Tir
It is understood that the software market takes full advantage of globalization. The companies that have R&D offices in just one geographical location are becoming fewer and further between.
It is a common for medium- to large-sized businesses to have many offices worldwide and to develop projects by distributed teams. I’ve seen many cases in which a single project is developed in three, four, or even more locations across the globe.
This globalization and cross-location model come as a logical consequence of the rapidly depleting talent pool in the software industry. Ultimately, the physical location is not as important when compared with other factors such as people skills, dedication and motivation, native talent, quality of education, and infrastructure.
For the past 15 years, I have worked at various companies in Romania that have acted as the main hub of remote software development activities for U.S. and Western European entities.
The term remote development is different from what people typically refer to as software outsourcing. One key difference is that the positions I have held are not normally outsourced, such as VP of engineering, a position I have held for a U.S.-based start-up, even though I was located in Romania. As part of this company, my responsibilities covered the entire software development lifecycle, including dialog with business departments and online incidents mitigation. On the other hand, traditional software outsourcing typically only includes writing code based on very well specified, limited tasks.
Below are the most common problems that need to be considered for a cross-location business model, as well as possible solutions. If these potential problems are correctly evaluated and handled, remote development may become as efficient as local development and offer other advantages, such as more available talent; accessibility of a wider area of expertise due to a larger resources pool within the remote company; and around-the-clock development capabilities.
Teams spread between different locations tend to have communication issues, especially in the case of young teams. Team members tend to minimize the role of communication and especially lack in voice communication. These issues have an even bigger impact when different time zones are involved.
For these situations, an “agile-ish” methodology would help a lot. By agile-ish I mean an agile-based methodology, such as Scrum or Kanban, but with some changes in order to accommodate the specifics of remote development. Location does not need to be an obstacle for daily standing meetings. They can be conducted via phone or voice conferencing systems. Even in the least compatible time zones, solutions are found by negotiating 10 to 15 minutes at a mutually agreed time.
Short daily or weekly reports may help as well. It is important for both teams to create reports so the work is not one-sided. One-way reporting, usually from the subsidiary to the headquarters or from team members to team-lead, may reduce working as a single team mentality and lower motivation.
These days, we hear the idea of over communication as a possible solution to these types of issues. This emphasizes the idea that is preferable to spend more time than normal communicating instead of underestimating its importance.
The amplitude of this issue strongly depends on cultural specifics. The origin is that we can better understand and anticipate people that have similar values, habits, and beliefs to us. This has nothing to do with tolerance; it even happens to very tolerant people because it comes from the subconscious.
The solution lies in the team members’ experiences and exposure to different cultures. Traveling to the pair location for few days would help a lot. This also solves the issue of putting a face to a name. While the travel cost may be expensive, in the long term it is worth the investment.
It is also important for every team to have at least one member with previous exposure/understanding of the pair culture. This experience usually spreads quickly to the other team members. In addition, every team member should be aware of the cultural differences at all times and keep them in mind during interactions.
Lack of Trust
We all tend to believe that we can do things better than anyone else. It takes time to gain the trust of someone else and often requires constant predictable behavior from the other person for an extended period to realize it. This waiting period can be hastened by several factors, including team members traveling to pair colleagues and spending time together. Generally speaking, any direct interaction is typically helpful.
Technology Perception and Gaps
Engineers physically located in different places can have varying perceptions regarding technology and access to learn or use new technology. This issue tends to be a minor one for experienced team members. Not everybody on a team always has the same level of experience or the exposure to new technologies.
To solve this problem, technical presentations and trainings within the team and company would be useful. Once again, traveling to and working from the pair team member site for a short period ensures that everyone is on the same page regarding technology. These solutions help broaden team members’ technical understanding and provide them with experience outside of their main skill sets and core technology.
Communication and Trust
Making sure communication is frequent, establishing trust, understanding cultural differences, and closing any technology gaps can make the remote development team as efficient as the in-house team. By realizing that having a remote team can be an advantage, companies benefit from a large talent pool to complete their projects quickly and efficiently. SW
Serban Tir is the CTO of Gemini Solutions.