Many managers of distributed agile software teams struggle with time zones. Team members may also struggle with maintaining a traditional eight-hour workday when separated by multiple time zones. Perhaps it’s not the time zones that are the challenge; the real challenge lies in re-thinking the workday of the team.

First, we should consider why we have some of our distributed team members in the first place. Some of the team members could have deep subject matter expertise that cannot be easily taught or found in others near you. Perhaps your company went through a reorganization or acquisition, and now you have people available for knowledge work projects that have some good expertise in areas needed. However, these same available team members might be able to contribute in a number of ways to the project. This allows some flexibility in how the team organizes the work.

Regardless, you find yourself in a situation where certain tasks can be done by one or more team members on the team—and the timing of these tasks can impact whether your project is successful or not. Also, as an agile software team, some of these tasks may benefit from collaboration. Yet multiple time zones can make this challenging. What is a manager to do?

Distributed Teams Do Not Have Eight-Hour Days Together

First, let go of the notion that distributed teams work a continuous eight hours. Based on the time zone, personal work preferences and personal commitments, each team member may start and end their day differently (see the example of Team Blue in Figure 1 below).

As shown in this figure, each team member has marked down if they work the full hour or a partial hour for each hour on the chart. This allows us to calculate the probability that team members’ schedules will overlap.

Figure 1: One distributed team’s schedule on Monday, Wednesday and Friday

Some team members start early in their local work day, and some start later. Some of these starts and stops of personal work might involve dropping off and picking up family members, or they may feel more productive in the early morning or later in the day.

For instance, Stefan may be a developer who chooses to work late into his evening because that is when he feels he can contribute optimally. Mike likes to come in early and take an early lunch at 11:30 am EDT and then leave early for the day to sometimes get in a round of golf or pick up his kids to take them to a golf lesson.

However, where Team Blue has an overlap of work hours are the times where the team can engage in collaborative activities such as agile planning, stand-up meetings, reviews and retrospectives. Columns marked “A” show the best time for this collaboration, and columns marked “B” show alternate times where most of the team is available. The team members may decide these are the times for them to protect in their personal calendars so that they can collaborate with the rest of the team.

What about those times when there is less overlap in team member schedules? Individual team members might have more freedom to shift their work time to other activities. This means they may not work a contiguous eight-hour day. Note how in Figure 2, Stefan has decided to shift his early hours in order to take a walk at the local park and clear his head before entering into collaborative time with the team. However, this shift does not impact the primary collaboration times of the team when comparing the A and B columns in Figure 1 and Figure 2.

Figure 2: Alternate team schedule for Monday, Wednesday and Friday

I have found that teams that can allow for these adjustments, but maintain a minimum of four or five hours of collaboration overlap, can function well as a distributed agile team.

Responsible Distributed Teams Choose Their Collaboration Time Together

Each team member may need a different balance of focus time and collaboration time. Times (in Figure 1 and 2) where Team Blue does not have extensive overlap may be better suited for deep focus work of writing, designing, development or testing. By guiding the team through a chartering session early in the start of the project, these preferences can be discussed and working agreements can be set around individual focus hours and collaboration hours. The result may be charts like Figure 1 or Figure 2.

Some team members may choose to adjust their schedule, but they should be careful when this may impact the team’s working agreements. For instance, Carly may decide to take a lunch-time kickboxing class on Tuesday and Thursday, as shown in Figure 3. She hopes to improve her health and focus at work. However, this reduces some of the collaboration time of Team Blue. Note that Carly’s new schedule eliminates one of the “B” collaboration time slots (compare Figure 3 to Figure 1 or 2).

Figure 3: A possible shift in the distributed team’s Tuesday/Thursday schedule

What should Carly and the team do? What would you do as the manager or leader? For an agile team, one effective approach could be to discuss this impact of the change in a retrospective. The team may choose to check in at each retrospective for any potential changes to the collaboration chart. This could inspire planning contingencies for vacations and different holidays across the countries where team members reside.

Possible questions to consider with changes to the collaboration chart:

  • Does anyone on the team anticipate an impact with the reduction in collaboration time?
  • Should someone else adjust their time?
  • Should Carly consider a different time for her class (if she can)?

Let’s assume in this example that this is the only time for Carly to take the class. She’s very interested in the class and that interest will keep her motivated to focus on her health each week. Some of the other members of Team Blue realize that this focus on her health will improve Carly’s sustainable pace; she may even inspire others to improve their sustainable pace. The team may decide that the best approach is to run this schedule as an experiment for the next couple of months to see how it impacts Carly and the team overall. They agree to check in on this experiment each month as part of their regular retrospectives.

What is the real challenge with distributed teams? As the examples above show, Team Blue was not challenged by the time zone differences. The members realized it was not a challenge when:

  • They visualized the overlap and realized they maintained a minimum of four to five collaboration hours per day.
  • They trusted each other with the power of choice in their schedule, assuming they would choose responsibly. That meant they would raise topics with the team if they saw their choice impacting the rest of the team.

So the true challenge became how to visualize their times to collaborate and trust each other to make effective use of their time—and realizing how they may impact the rest of their distributed team.

A previous version was published on ProjectManagement.com November 8, 2018 by Mark Kilby.