If you’re the project manager for a geographically distributed team, you have likely encountered time zone challenges in running your meetings: 7 a.m. New York time is 8 p.m. in Singapore. Meetings at these times can exhaust everyone.
Here’s a common scenario faced by managers of distributed teams:
“We’ll have our next standup tomorrow, same time, same location, okay?” Jen, the agile project manager was ready to finish the meeting.
“Uh, Jen…I have a question,” Yi Ling said.
“Sure, go ahead.”
“Do you realize the time here? You know we’re in Singapore, right?”
Jen thought for a second, and said, “Yes, I know. Three of us are in New York, Pierre is in Paris, and two of you are in Singapore. Is this about the time of the standup?”
Yi Ling answered, “It’s the time of all the meetings. You call them for 9 a.m. New York time. For us, it’s 10 p.m. here. We’ve been at work forever. We’re exhausted. We’re 13 hours ahead of you. It’s not so bad for Pierre, because he’s six hours ahead of you and it’s still the afternoon. We can’t keep doing this. We need to share the pain.”
Jen said, “You’re right. I’m so sorry. Let me think about alternatives and let’s discuss what we can do on our chat channel.”
Here are three alternatives for Jen to consider…
Follow the Sun
One alternative that works quite well with agile is to use the “follow the sun” approach to development. The team—or the product owner—creates small enough stories that the people farthest east work on the story. They hand their work off to the person/people in the next westerly time zone. They work and hand off their work to the next farthest west person.
In this case, the Singaporeans would start work on the feature, hand it off to Pierre in Paris, who would hand off to the New York people.
This approach has three assumptions, namely that:
- Everyone understands the work to do next. Or, the person handing off can explain the work that the next person needs to do.
- People can hand off to the next logical person in sequence.
- No one has questions about the work.
I have not encountered many teams who meet those criteria. Instead, I most often see teams where the testers are the farthest east, and the product owners are the farthest west. In that case, forget iterations. Use kanban.
When you use kanban, you ask the product owner to go first. In our team above, Pierre is the product owner. Pierre would work on a story and make sure it’s small enough for the team to work on it. The story would be “in definition” or some state like that.
The next state would then depend on who can take the story next in east-to-west sequence. If the developers in New York are next, they could do development (the story would be “in development/unit test”). The developers would hand off to Yi Ling and the other tester in Singapore by placing the story in “system test.” The testers finish their testing and place the story in “acceptance test.”
Pierre takes stories out of “acceptance test” and moves the story to “done,” as long as he doesn’t find problems. If he does find problems, the story returns to “in development.” If this team had no one in Paris, they could still use “Follow the Sun.” In this case, the testers would start first. The kanban board might have these columns:
- In Analysis
- ATDD (Automated Test Driven Development)
- Development/Unit Test
- Exploratory Test
- Acceptance Test
These are example columns; your team might need different states.
If the team maintains a small number of stories in progress, they can do this and maintain a sustainable pace. If they use an online tool to perform retrospectives on their work on a regular basis, they reap the benefits of improving the entire team.
But what if the team members are new to agile, or new to working with each other, or the product owner doesn’t understand small stories yet? You have other options…
Share the Meeting Pain
I have coached teams where the product owner and the team did not understand how to create small stories. They could not manage their work in progress. These teams decided to share the meeting pain.
For one two-week iteration, they met at 9 a.m. for the most-westerly team. For the next iteration, they met at 9 a.m. for the most easterly team. The meetings worked, but the personal toll was quite high. Someone always meets “past hours.” Their company did not reimburse them for their overtime, either in time off or money.
One team did this for a total of four iterations. They rebelled and decided to create smaller teams who were collocated. So, here’s a third alternative…
Create Feature Teams in Each Location
One group with testers in Bangalore and developers and product management in San Francisco decided to split their teams. They had tried meeting at 8 a.m. Bangalore/6:30 p.m. San Francisco time. They tried 7 a.m. Bangalore/5:30 p.m. San Francisco. They even tried several more times over the course of six months. They had the same result: People were tired from staying at work or waking early. The personal toll was quite high.
Their management asked them to add more testers in Bangalore and more developers in San Francisco. Instead, the team asked to split. Their argument was that five testers in Bangalore and six developers in San Francisco was too many for one team and wouldn’t help.
They hired developers in Bangalore. In San Francisco, they supposedly couldn’t find more testers, so hired people in S?o Paulo, Brazil, which was only six hours later than San Francisco.
They ended with two teams of four developers and three testers. The product owner tried to work for both teams at first. He was not able to prepare stories or review them in time for two teams. The Bangalore team hired a product owner.
When you break a larger team into smaller teams, it changes the dynamic among the people. Smaller teams can force changes to the story size. The team, including the product owner, realizes that for this three- or four-person team to complete anything, the stories must be smaller.
Now, the synchronization had to occur primarily with the two product owners. They solved this by meeting in person every eight weeks and working via documents the rest of the time. The teams could plan their work together and retrospect the way they wanted, because they had fewer than eight hours of time zone differences between the team members.
Diagnose Your Distributed Team Challenges
You don’t have to use iterations to be agile—you can use kanban. Kanban also helps you see the work in progress and helps see where the team is stuck.
Consider the “Follow the Sun” approach. Don’t be afraid to start with the testers if they are farthest east. Who knows what value you might discover if the testers start?
My guideline is if teams are six hours apart or less, sharing the pain for meetings works. If you have teams of seven or more, consider breaking the teams into smaller teams. Even better, change the nature of who is where for your teams.
Remember, agile is a team’s ability to deliver value often. What do you need to do to help your distributed team deliver value?