When a business creates an outsourcing strategy and factors these difficulties, there are usually greater cost efficiency and a positive impact on overall productivity.
From a Western European or US standpoint, it has traditionally meant having a business partner somewhere in Eastern Europe or Southeast Asia, for example, Poland, Ukraine, India, and China.
However, Latin America has positioned itself as an attractive region for outsourcing in recent years, given the typical collaboration barriers (language, culture, and time zone) are much lower or nonexistent compared to other regions.
Despite all these benefits, team gaps in general, and time zone differences in particular, still pose a significant challenge and must be addressed with proper tools, methodologies, and practices.
This article will explore the most common pitfalls and best practices in dealing with time zone differences in outsourced software development projects.
Outsourced Team: Localized vs. Distributed
In a previous post, we explored the different outsourcing patterns related to geographical distance. Offshore means further away than nearshore, so differences in offshore time zones are generally more significant.
However, while an outsourcing business partner headquarters can be located offshore or nearshore, it is essential to consider whether both teams (client and outsourcing provider) will be localized or remotely distributed.
For example, a US-based company can outsource a project to a software development company based in Argentina or Uruguay. In general, this means the provider and the client will be just between 1 or 2 hours apart if the US side is based on the east coast, let's say, New York.
If the US company is based on the west coast (San Francisco, for example), the time zone difference is slightly wider but still manageable, between 4 or 5 hours. As a side note, online collaboration time can be effectively reduced to zero with offshore other-side-of-the-globe partners with more than 9 hours of time zone difference.
This explains the excellent outsourcing opportunity LATAM poses for US and Western European companies.
This scenario can get even more complex if any of the teams are, in turn, distributed across other time zones. Perhaps the team in the US has some specialists living in Europe and working from abroad.
Maybe the outsourcing team in Uruguay has a database or DevOps specialist in Brazil or Spain. This globalized and interconnected reality easily allows for these and other more complex scenarios.
Time zone differences can be reduced or increased for team members remotely working for their teams. A project management team must consider this a key factor for success since dealing with multiple time zone differences requires state-of-the-art communication tools and processes.
Teams facing this type of challenge will increase their probability of success if they resort more to asynchronous communication (email, but better Slack or other corporate chat tools) than to synchronous meetings or phone calls.
This, of course, stresses written communication skills on both sides, another aspect that has to be taken into account when assembling their teams.
It is essential to pay attention to both big and small time zone differences. At first sight, it may seem that having an 11-hours time zone difference is a challenge (it is), but dealing with two or even 1-hour differences should be straightforward.
In reality, just a 1-hour difference with a critical team member can render online collaboration impossible. Again, this should point out how crucial it is to master asynchronous communication tools for project coordination.
Dealing with typical time zone difference problems
Software projects are usually more about tight coordination and effective communication than technological problems.
After a given interaction, there is typically a need to clarify a particular topic. Maybe the scope of a user story is unclear; perhaps a bug is reported so that the team cannot reproduce it, to name a few common examples.
Typically, many emails go back and forth when this happens while actual progress has come to a stall. When you add time zone difference to the mix, the impact on efficiency can be dramatic.
However, there are some practical actions a software company can take to mitigate these problems:
Provide the team with an online shared working space
Having an online documents repository like Google Drive or Atlassian Confluence is also necessary.
By collaboratively and asynchronously editing documents and diagrams, a team can collaborate by leaving minor comments and notes in the same docs they are building, without the need for external communication channels like emails.
Establish and agree upon an online calendar tool
All the big tech companies, and many small startups, offer online calendar solutions. Microsoft Outlook, Google Calendar, and Zoho, to name a few, enable teams to coordinate online meetings in a timezone-aware fashion.
It is advisable to establish some best practices regarding meetings. For example, a team could agree on the default meeting duration to be 45 minutes instead of an hour. They could establish to avoid meeting at the beginning or end of the other team's workday (or the opposite).
Using the right tools makes it easier to find time slots where everyone is available. Web and mobile apps will notify everyone in advance of a meeting while linking to an online call solution like Google Meet or Zoom.
A proper Slack or other online chat tool profile configuration, stating time zone and availability, is crucial to make online planning more efficient.
Provide some online visualization for time zone differences
Having 2 hours time zone difference means when a team starts their workday at 9 AM, the other is just getting out of bed or having breakfast at 7 AM.
At the end of the day, when the first team is ending their workday at 6 PM (could be 5 PM depending on the country), their counterpart still has two more hours to go.
The time zone difference reduces their time overlap, so from a total of 9 hours (9 AM to 6 PM), these teams can collaborate in real-time for 7 hours.
The same exercise with a time zone difference of 5 hours results in the group having 4 hours for online collaboration.
There should be someplace (online world clock tool, Confluence page, Google Sheet, etc.) where the team can quickly visualize the different time slots to collaborate online or asynchronously.
Be as specific as possible about requirements
To minimize the need for clarification, try to be as thorough as possible when specifying requirements. This doesn't mean adopting a waterfall approach. Quite the opposite, the Agile approach helps teams specify User Stories efficiently while avoiding the pitfalls of excessive upfront analysis.
Product Owners should focus on having well-written user stories. A good user story can include screen mockups, user scenarios, FAQs, or anything that will help developers move forward as independently as possible.
Make mindful use of online meetings
Constant communication is key to an outsourcing strategy's success. However, regular communication does not mean endless meetings.
On the contrary, it is considered harmful to overload a team of developers with constant (ofter unnecessary) meetings.
Teams should agree on what topics and ceremonies require an online meeting and what other events can be handled asynchronously via chat or email.
Perhaps groups agree to report daily progress and impediments via Slack but conduct sprint demos online. It is better to clarify the purpose and number of meetings at the beginning of a project.
Leverage the Agile approach
The Agile approach, and its most popular implementation, Scrum, extensively uses collaboration tools and processes. Walls filled with post-its, and whiteboards used for retrospective meetings, can all be implemented with online tools nowadays. The very basics of Agile are about collaboration and communication.
The Agile Manifesto states while there is value in processes and tools, interactions among individuals are more valuable.
A key idea in the Agile approach is that teams should be self-organized and that communication type and frequency are highly dependent on the project stage.
Typically communication is expected to have a higher frequency at the beginning of the project. By using continuous integration tools, teams can deploy their code as frequently as they want.
This allows developers to communicate with each other with their actual working software instead of meetings or emails.
A quick note on Holidays
This may seem obvious, but companies with distributed teams should have a public list of local holidays for each country involved.
This will allow teams to plan vacations meetings and take days off into consideration when estimating their capacity (surprisingly, a frequently overlooked issue).
Whether nearshore or offshore, outsourcing software development typically implies dealing with time zone differences among companies or even individual members of the same team.
While every company is aware that time zone differences exist, many don't adopt explicit best practices to deal with them. Identifying and communicating work time overlap, holidays, and agreeing upon expected communication channels and tools is a critical success factor for distributed teams.
Lastly, teams adopting asynchronous communication will, in general, be more efficient than teams that are highly dependent on in-person, synchronous communication.
Among the async tools, while email is an established channel, usually, tech teams will experience a higher communication efficiency when using specialized software like Jira or Confluence and chat tools specifically designed for development projects like Slack.
Devlane is highly experienced in working with distributed teams for US and Western European companies. Drop us a line!