How to Deal with the Time Zones Problem in a Distributed Agile Team

Author

Daxx Team

Posted

Jul 14, 2014

Offshore Team

Distributed Agile teams combine two dominating and increasingly popular trends in IT: Agile development and outsourcing programmers. More and more companies implement Agile methodology as a progressive and effective way to build software, and just as many businesses hire offshore developers to cut down the development costs. No wonder that a distributed Agile team is the reality of today’s IT.

Collaborating and maintaining agility in a geographically distributed Scrum team is a challenge in itself, since working together and arranging regular meetings becomes more difficult, and face-to-face communication - nearly impossible. But when the team consists of remote developers from various time zones, the challenge becomes a real problem. How do you get your distributed Agile team together when it’s time to leave the office for one member, and another one is only halfway through their breakfast? And in a broader sense, how do you maintain agility in a team that is distributed across time zones?

Create a Time Zones Visual

To begin with, it’s very helpful to visualize where each team member is located and what their working hours are. When you do that, it will be easier to identify what meeting time works for everyone - or if anyone will have to adjust their hours.

Make Sure the Management Realizes Time Zones Situation

When a project is at its earliest stage and the work hasn’t started yet, it may be the last possible moment to reconsider the team composition. If the time difference between locations is far too big, and you realize that too many people will have to work crazy hours, explain the situation to your management and may be create a team that is closer in terms of time zones.

Want to learn more about setting up an extended development team with us?

Let Everyone Participate in Picking Time

Share the time zones scheme with all Scrum team members and let them participate in deciding on planning and standup times. This is especially important if there are too many time zones and someone will have to change their working hours to participate in a meeting.

Be Fair About Schedule Adjustments

When the time difference is too big, there may be no perfect meeting time for everyone, which means someone will have to start earlier or finish later than their regular working hours. Be fair with that: ask people beforehand if they can reschedule their day, and distribute this unpleasant responsibility between the team members fairly. Don’t make just one person always start early or stay late.

Meet Only with Those Who Need to Participate

Not all meetings require the whole team to be there. An iteration planning meeting or a standup needs the presence of your whole Scrum team, but some people don’t have to participate in a problem-solving meeting if they are not solving that problem. That is especially frustrating if those team members had to adjust their schedules to attend the meeting.

For a distributed Agile team, the time zones are even bigger a challenge than they are for remote developers who don’t stick to the Agile methodology. But with a little effort and planning, you can combine outsourcing programmers with Agile development and enjoy the benefits of both.

Daxx Team

Daxx Team is a team of passionate creative writers, content marketers, designers who vigorously research internet as well as cooperate with developers and Managing Director at Daxx to provide you with the top-notch material about tech, salary trends, development team hiring and management tips as well as up-to-date information about Ukrainian IT outsourcing market.

“Find people whom you trust and who can think of solutions to help you out with the things you don’t know.” Check out the interview with Marcel Hazeleger, TenderApp Co-Owner, who shares experience of growing a tech product....

Drew Dorgan, globalHMA/Workhorse Development Owner, describes how cooperation with Daxx brings positive productivity changes in her companies and showcases why cooperation with freelance developers was not very beneficial....