Challenges faced while working in different time zones

Question

I am sure there are many developers out here who have team spread across different time zones. What are some of the challenges people face and whats the best way to tackle them?

Answer 1

In all honesty, any company that has split development of a project across time zones is out of touch with the realities of engineering. The MBAs, in an attempt to save themselves a buck or two, foist upon their engineers the unenviable position of altering the schedules of their lives - leading to high stress, longer work hours, lower morale, and higher turnover. Quality suffers, ship dates suffer, feature lists suffer. The only increase you'll see in your project is the bug count.

You can have engineering projects split up like this if you don't have any need for low-latency communication between project units. In other words - if they are working on almost entirely independent segments of the system.

Answer 2

We have a team that is distributed or has to work across 3 or 4 different timezones. In the course of this we have faced several challenges primarily relating to communication.

Meetings are tough to arrange at a convenient time for all team members to attend, so there can sometimes be a need to have subsets of the team meeting, or to forego the team meeting approach for an individual update approach where one primary team member is responsible for a particular overseas team.

Another issue is work handover and communication. For example, we have a resource in India and if they have a problem that causes them to stop work, it can take 2 or 3 days out of their schedule if we don't respond quickly enough, all due to the time difference. Therefore, it is imperitive that we not only schedule diverse work to fill these delays but that we also respond to their queries in a timely manner. We often assign testing tasks to resources in this particular timezone as that is often an asynchronous task without an end.

In addition, you need to have a good change management system and code repository. The more asynchronous you can make the communication channels, the better, and this goes for information exchange as well (such as source and issue tracking).

There is no reason why you can't make distributed teams work, especially in the current age where we can work from almost anywhere as long as we have a link to the Internet. However, it's important to know where your bottlenecks are in a project and to ensure that work is distributed accordingly.

Answer 3

I currently work in a different time zone than the rest of my team. The biggest challenge is early in the morning and late in the afternoon when some of us haven't started work for the day or some have already left for the day.

It's just part of the work effort and we all respect each others valuable time. If it's something critical (and that's a relative term) then we just call the team member or page/text the whole team. If that happens then we all respond as needed. No big deal. Because of the respect factor, we know to only use this if necessary.

During the normal working day we just use the standard stuff like email, phone, and IM.

Answer 4

If you dont have a great process which has tuned exclusively for this kind of a scenario, then different time zone is going to kill your project deadline. Atleast one side should be very flexible to adjust their time for the meetings. But ofcourse that will eventually create frustrations among the team members.

Check out this SO thread which talks about Outsourcing and its practical issues, I think you will get some points from there too http://stackoverflow.com/questions/111948/outsourcing

Or Outsourcing Tag - http://stackoverflow.com/questions/tagged/outsourcing

Answer 5

We have these kinds of issues with support - we are using 3 commercial SDKs and the support teams are in distant time zones (8-10 hours difference). Moreover, not all work days overlap.

This fact had a big impact on my reverse engineering abilities :)

Answer 6

Plan, plan and plan some more. A few other things to note:

1) Be aware of local holidays if the team is in other locales, e.g. different countries may have different holidays. For example, some sects celebrate some Chrisian holidays 2 weeks later than most Christians,e.g. some orthodox sects I'm thinking.

2) Plan on meetings at a specific time that may be outside the normal work hours. This was particularly true when there was a 13 hour time difference between the rest of the team and myself.

3) Be aware of "Core hours" with the time change, e.g. if I'm on Pacific time and want to update something in New Jersey on Eastern time and I do it at 5pm Pacific time, that is 8 pm Eastern time and there may not be anyone there to notice the change or test it before the following morning which may mean some support person gets up at 4:30am Pacific time as in the East some have started to show up for work and go, "Huh? Why isn't this working like it did yesterday?"

There is also the other obvious things of being aware if there are various alphabets involved, e.g. Latin, Cyrillic, Arabic, etc. and this may affect how a computer interprets some text entered.