When Mark Kilby and I wrote From Chaos to Successful Distributed Agile Teams, we discussed the fact that we no longer needed physical face-to-face interactions. Instead, we needed high-fidelity virtual interactions.
(High-fidelity virtual interactions didn't exist when the guys got together at Snowbird to write the Agile Manifesto for Software Development.)
The Allen Curve explains a lot about distance and communication frequency for “in-person” teams. (See How To Understand Your Team Type: Collocated, Satellite, Cluster, Nebula.) However, the curve doesn't explain how to create high-fidelity virtual communications. (For more information about communication options, see Distributed Teams Need Sufficient Communications Technology.)
I'm not shy. I'll take a stab at what we need for high-fidelity virtual communications.
Components of High-Fidelity Virtual Communications
When we are face-to-face, we can have high-fidelity communications with our:
- Eyes, to see each other and a common workspace, such as a whiteboard.
- Ears, to hear each other and hear the “music” of the words.
- Hands, to use equipment and test the product, such as with paper prototypes. And to physically connect with each other (in a respectful way).
- And our noses for odors.
We have trouble with high-fidelity communications under these circumstances:
- Vision: blind people can't see. And if we don't have a useful workspace, it might not matter if we can see. (Do you have pillars in your conference rooms?) The workspace prevents us from visualizing together.
- Audio. I'm deaf in one ear. There are way too many “open” workspaces where I can't hear the person next to me. That's for two reasons: the room is too noisy so my tinnitus acts up. Or I literally can hear people across the room, but not next to me.
So while we might have trouble with vision and audio, we almost always have high-speed information transfer. Yes, we might confuse each other, but we're in the same place, so we can fix that.
In summary, we can create a high fidelity face-to-face environment with:
- Always-on vision via our eyes.
- Coherent audio via our ears
- The team all together in real-time.
- Sufficient bandwidth so we can collaborate.
Distributed teams need the same options.
Create More Communications for Your Team
If you want a higher frequency of communications for your distributed team, you will need:
- Sufficient hours of overlap, so you can create working agreements about when to work together and when to have cameras on.
- A text backchannel so people can discuss when they have time. This answers part of the “how long does it take to ask a question” problem.
- High-speed and dependable bandwidth so you don't have communications that drop in and out.
That's what I tried to show in the image for this post.
On the left side of the image, if:
- The team has intermittent bandwidth
- Fewer than 3 hours of overlap
Then expect insufficient team communication frequency.
However, as on the right side of the image, if:
- The team has at least four hours of overlap
- Everyone has high-speed, dependable bandwidth
- A text backchannel
Your team probably has sufficient communications.
This list is critical for satellite and cluster teams, those “hybrid” teams.
What do you think? What did I miss?
There’s a difference between ‘having’ and ‘using’. If teams have the equipment, but they don’t use it, then the equipment is of no use (waste) and the team won’t benefit.
You talk about “Team’s Frequency of Real-Time Communication’, yet give no ‘measure’ for this, apart from the 4 hours of overlap. How can we judge if the people in the team communicate sufficiently?
Ronald, true, if a team has certain equipment and doesn’t use it. I would do a little retro and discover why.
True, I also did not offer a way to measure a team’s real-time communication. I have asked teams (regardless of location) to measure their cycle time. The more the team measures their cycle time over time, the more they can see their “typical” cycle time. And, using a value stream map helps the team see where they have delays. The team can then decide what to do about those delays.
I’ve also asked the team to discuss how they feel about their communications. Yes, that’s a qualitative measure.
If you serve the team, just asking these questions might help. If you’re part of the team, see if the team will do a retro to examine the data around these questions.