December 12, 2007
Working Across Time Zones: A Good or Bad Thing?
Prevailing sentiment concludes that spreading a development team across multiple time zones is one good reason to outsource your software project. The theory is that you can work around the clock, passing work from one team to another and be productive nearly 24 hours a day. Is this really practical? In our opinion, spanning a team across different time zones is not really an advantage for software development, though it does not necessarily need to be a disadvantage either. In certain cases, such as with a QA team evaluating a build in one time zone and having development respond to issues later in the same “day”, distributed development across time zones may make a lot of sense. However, we find that time zone differences are either productivity neutral or can have a potentially negative impact.
There are probably a large number of relevant issues to examine when looking at time zone differences and many of these issues can have a negative impact. Consider conducting geographically diverse team meetings. You’ll need to find an acceptable time for all to participate. Do you like staying at work late or getting up at the same time as your newspaper delivery person so you can conduct important and necessary meetings? How about needing a critical answer to a question when the person who can answer that question is quite happily doing something other than work, like sleeping? In the worst case, development can slow down if team members in one time zone are waiting for input from contributors in a different time zone.
Good ways to circumvent these problems are to to plan ahead, create sizable chunks of work that can be done independently, allow onsite decision making and ensure all members understand the vision, goals, and objectives of the project so they can work creatively and effectively on their own. Find ways to review completed work and discuss issues regularly, so decisions made separately can be reviewed by the entire team and revised if needed. Plan your meetings so they are short and summarize status rather than become lengthy problem solving sessions. In other words, you empower your distributed team to produce rather than grind to a halt.