Creating Time for Collaboration with Distributed Teams and Agile Approaches

Many of us have horrible experiences with distributed teams where we can find no possibility of collaboration, but it doesn’t have to be that way. Even if a team is distributed, those team members need collaborative opportunities and space. What’s important is the team’s time for collaboration, not time zones. Here are some ways you can visualize when your team works and create more quality collaboration time.

Many of us have horrible experiences with distributed teams where we can find no possibility of collaboration, but it doesn’t have to be that way. Even if a team is distributed, those team members need collaborative opportunities and space.

What’s important is the team’s time for collaboration, not time zones.

Amy, a product owner, works with what she calls a team. When she explains where the people are, she says, “Denver, Atlanta, Paris, and Chennai.” She’s based in Denver, which is why she starts there. However, when people come to work, the Chennai people arrive first, then Paris, then Atlanta, then Denver.

When we work in distributed teams, we often think of ourselves as “home base.” In some sense, the team revolves around us. This might especially be true of the product owner.

However, agile approaches are based on the team working together. When we think the world revolves around us, we lose the value of working as a team.

We suggest you first see when people prefer to work.

Visualize Work Hours for Each Person on Your Team

Amy first created a spreadsheet of when everyone on her team preferred to work. 

Spreadsheet showing employee work hours

The team does not have enough collaboration time. Note that by default, they have only an hour and a half of overlap for the entire team to collaborate. Since these hours of overlap occur at the beginning of the US team members’ day, the collaboration can be disrupted if one of them is delayed by traffic. For the Parisians, if one of them needs to leave early for the day, the collaboration time for that day collapses again.

That’s not enough collaboration time for an agile approach.

You might ask, what if the team members work from home? In that case, they don’t have commute time challenges. They might be able to depend on those possible collaboration times more often. However, they might have to manage personal challenges: the car needs an oil change, there’s a sick family member, or the dog needs to go to the vet.

This team—and we use the word loosely—does not have sufficient hours of overlap to collaborate. They still have some possibilities to increase collaboration time.

The next step is to map your team’s value stream so you can see where the time goes.

Create a Value Stream Map

A value stream map shows the work that progresses and the work that is waiting. More importantly, the value stream map indicates who is progressing the work and who may be waiting for the work to move along in the value stream.

Here’s a generic value stream map especially useful for teams with insufficient hours of overlap. Notice that people tend not to work together, so they hand off the work item.

Value stream map showing work handoffs

In a distributed team with few hours to collaborate, the wait time often exceeds the work time. 

Based on the spreadsheet above, here’s the best-case value stream map for the last story:

Value stream map showing work handoffs

Notice that some of the developers pair on the work. The testers don’t have enough hours of overlap to collaborate with the developers or Amy. This team is doing the best job they know how right now to collaborate and manage their cycle time.

What they’re doing frustrates all of them. However, once you see who waits and for how long, you can start to consider how to reduce the wait time with more collaboration time.

Establish More Collaboration Time with Care 

People can create more collaboration time by choice. They can: 

  • Use an ambassador
  • Create handoffs
  • Timeshift—start and stop when they work at different times from “normal”

When people choose for themselves, the entire team creates a feeling of mutual trust. And, often, the other team members reciprocate as they can. Together they create an atmosphere of better teamwork.

Contrast that with the manager telling people to create more collaboration time, especially with timeshifting. Imagine a manager asking Tim, a tester, to timeshift and meet with the developers at 3 a.m. every day for a standup. 

Tim agrees because he thinks he doesn’t have a real choice. If this is a short-term request, Tim might be able to live with it. However, neither the manager nor the team meets Tim’s needs as a full-fledged member of the team.

Over time, Tim loses trust with his manager, and he loses trust with his team when no one raises the issue of Tim’s timeshifting challenge.

Instead of telling people to timeshift, consider ambassadors to help manage information.

Ambassadors Help Manage Information

Some teams, especially large teams, find that ambassadors help create shared understanding.

Another team has all the developers in the Eastern time zone of the United States. Their testers are all in Singapore. They have no hours of overlap, so there is no time for collaboration as a team.

The team realized they had trouble. They hired a test manager to be on site with the developers and a test manager to work in Singapore with the testers. These people served as ambassadors. Neither of them “managed” the testers, per se. However, they both collaborated so the testers knew what to do and when.

In addition, the ambassadors visited the other site on a quarterly basis. The Singapore testers knew the US test manager, and the US developers knew the Singapore test manager. The ambassadors understood the people and capabilities at both sites.

Only these two people had to manage the lack of collaboration time. The ambassadors coordinated closely with each other and their local teams. Therefore, the ambassadors held the shared context, not the entire team.

While this situation is not ideal, the two people made it work for a couple of years. Over time, the organization decided to spin off one product to Singapore and hire full product teams there. They then hired testers in the US to create full feature teams with more hours of overlap.

Handoffs Formalize the Lack of Collaboration Time

If you don’t have the possibility of an ambassador, consider specific handoffs. Handoffs work best if the team members can carve out fifteen minutes of overlap to discuss the items they hand off to each other.

However, if you don’t have even fifteen minutes, consider how you can articulate examples, acceptance criteria, and anything else that specifies how the next person in the chain knows what to do and when. Some examples may even be captured via video, with Q&A through a chat tool.

If you think this sounds a lot more like a waterfall approach, you might be right. Agile approaches require collaboration. If you don’t have collaboration time, we don’t see how you can effectively use an agile approach.

You have other options for your project lifecycle. You could use iterative or incremental lifecycles. But if you have people with no hours of overlap on your team, you might need handoffs. 

Instead of ambassadors or handoffs, voluntary timeshifting can help a team collaborate more.

Voluntary Timeshifting “Creates” More Collaboration Time

We’ve seen teams like Amy’s benefit from voluntary timeshifting. Some of Amy’s team members timeshift already. Krishna and Lakshmi start work much later in their local time, at 12:30 p.m., so they stop work at 8:30 p.m. local time. Not everyone can do that. People still have obligations outside of work.

Amy and the rest of the team felt it unfair to ask Krishna and Lakshmi to timeshift further. So Amy first volunteered to come in an hour and a half earlier and adjust her lunch time to better overlap with the team’s work time.

Claudette and Pierre then shifted their daily start and lunch time to better overlap with the Chennai team members. Cindy and John followed to adjust their times as well.

Spreadsheet showing employee work hours

As you can see in the updated overlap chart, these changes allowed the entire team three hours of overlap instead of only one. This allowed for experiments in pairing and mobbing, which helped Krishna and Lakshmi better understand the code they would be testing. They also suggested some new automated testing approaches that the developers could help implement.

In general, their cycle time decreased from 21.5 hours to about 8 to 14 hours. If the team missed their collaboration window, they still had problems finishing as fast as they wanted. But, because the team collaborated more often, Amy was able to slice the stories smaller. That helped the team finish earlier.

Verify Your Assumptions about When Your Team Can Work

As teams and organizations transform to using agile approaches, we have seen that legacy thinking of putting the work where people “cost” less leads to much longer cycle times. The overall work doesn’t cost less; too often, the increased cycle time leads to work costing more.

So hiring “cheap labor in far-off lands” is a false assumption. If your management needs to find less expensive people, consider going north-south, not east-west.

Too many managers also believe they can ask team members to work on far-flung teams and that the team members will somehow “make the time” to collaborate. It’s possible that people can do this for short periods of time. But it’s not wise to ask people to interrupt their lives regularly for the good of a “team.”

If you’re not sure about the effects of your team’s collaboration time for the work, consider creating a chart showing hours of overlap. And measure your cycle time for a few recent features. That data might suggest alternatives for you.

If you can’t create sufficient hours of overlap, you will have a terrible experience with your distributed team—agile approach or not. If you can find some collaboration time, you might discover smart people distributed in space and time who can help your team succeed.

About the author

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.