I’ve been working with distributed teams for a long time – about twenty years now. Some of those teams have been based in Europe, some in India, and some across the United States. I follow a simple rule about distributed teams: if any worker is remote, treat the entire team as if it’s remote. That really helps with communication and collaboration. There are still some differences between remote team models, though, so let me provide some tips on how to manage your distributed team.
A Distributed Teams Primer
When we talk about distributed teams, there are several different scenarios that come to mind. Many agilists will tell you that a co-located team is preferred to any kind of remote team structure. Having everyone in a single location helps with communication and collaboration. It helps with creating a sense of “team”. When the team doesn’t sit together, the team doesn’t “gel”. But distributed teams are the way many businesses work today, though, so we have to deal with them.
As I said previously, if any member of a team is not sitting with the rest of the team, you have a distributed team. Whether those people are working from home across the Pacific Northwest or they’re all on different floors of the same building, you’re going to have some of the same challenges all distributed teams do.
There are three main scenarios for distributed team members:
- All in the same time zone: this could be anything from “everyone at the same site but physically separated” to “everyone is spread across the east coast”
- No overlap: this is a common occurrence when team members are distributed around the world, usually in an off-shore model
- Several hours of overlap: this is a geographically distributed team but with at least some work hour overlap
Tips For All Distributed Teams
The key to working with any distributed team is communication. Even if only one person is remote, the team needs to operate as if everyone is remote. Technology can help with this situation. Using a tool like Slack, IRC, or FlowDock for primary communications makes sure that everyone is involved. It’s critical to not have local meetings that the remote team members can’t attend. Even a “water cooler conversation” should be communicated to the entire team. When everyone is proactive about engaging each other, the team has an opportunity to “gel”.
Another tip is to open each meeting with a “getting to know you” question. Ask people to share something about themselves with the other team members. “” is a good example of this kind of activity. It doesn’t take too long (I’d timebox to 10 minutes at most) and it helps the team members know a little more about each other. Encourage the team to have further conversations online via Slack, IRC, FlowDock, or whatever you’re using for collaboration.
Using video is critical for any remote meeting. Zoom and Skype are the leaders for this. You will get resistance to having cameras turned on. Do what you can to overcome that resistance. Being able to see each other makes meetings far more productive.
Finally, try to get the entire team to establish a team identity. Establish a team name. Come up with a logo for them. Find something that helps the team feel like they’re more than just a bunch of people working on the same project. Help them feel like part of a team. I once worked with a remote team called the Velocity Raptors. I definitely felt that they identified as Raptors, not just as employees who worked together. The Scrum Master held a trivia contest each sprint and the winner got a small plastic dinosaur figure and some candy. Nothing major but I know it helped people feel connected when they saw that plastic dinosaur every day. Find something that you can use for your team.
Distributed Teams In Same Time Zone
Teams with members in the same time zone are the easiest for meeting coordination. Because everyone generally works the same hours, you can schedule meetings at almost any time and be guaranteed that people can attend.
If most of your team is co-located, I would still recommend that they take calls at their desks rather than going to a conference room. It ensures that everyone on the call is on equal footing. Nothing makes someone feel like an outsider more than being a caller into a meeting in a conference room. You can’t hear all the conversations that are happening and the people in the room often forget the people on the phone. It’s best to just have everyone act like they’re remote.
Finally, avoid email as much as possible. When decisions need to be made or the team needs to talk through something, have a video call. Email is one of the worst communication media there is, with much potential for misunderstanding and misinterpretation. It is far better to have a call with someone – and video is best! – than to send an email. Email is very passive and agile teams need to be proactive.
Distributed Teams With No Overlap
With a team that has no overlap, you should explore the option of establishing an independent team. If enough team members are in the same or similar time zones, consider breaking the team into subteams or just two smaller teams. Most companies have this model have some offshore team members that they’ve integrated with an existing team.
If your team needs to operate this way then you need to quickly establish how the team is going to work. Will you use a wiki or SharePoint to collaborate and coordinate? How will the team communicate changes? Will someone from the time zone with the most team members stay up late/get up early to touch base with the other team members and report. Maybe that role rotates between team members so that it’s not just one person who has to do that. Or perhaps you can have that person operate a shifted schedule; one where they don’t need to be in the office at regular times. Regardless of the solution, lay out the issue to the team and then provide some suggestions. Let the team experiment and try things. Retrospect regularly to see what improvements can be made.
Distributed Teams With Overlapping Time Zones
This is a hard situation because only some of the day is available. You’ll need to blend the two above models. First, find some common times for the regular team meetings – daily Scrum, backlog refinement, etc. Then find a solution to accommodate the off-cycle times through a shared repository. Again, SharePoint, a Wiki, or some other mechanism should be selected for the team. And I strongly recommend using Slack or some other tool to make sure that everyone has the opportunity to know what’s going on with the team.
A good resource for this kind of collaboration is Scott Berkun’s book . Scott was a Microsoft manager who left to work at WordPress in their fully-distributed workforce model. He dealt with many of these kinds of issues on a daily basis and has some great insights.
One Last Tip
For some scaling models (like SAFe) Program Increment planning requires (well, strongly recommends) that the Agile Release Train (ART) gets together in person every 8-12 weeks for planning. Even if you’re not using SAFe, I strongly recommend that you find a way to get your teams together in person periodically. It can be expensive, but the productivity gains from it can more than compensate for the cost. If you’re looking for some justification to provide to management, just look at Scott’s book – he has some good arguments for how to make this work.
@ Velocity
Because Velocity Partners is a nearshore model, our teams fall into the “same time zone” or “overlapping time zone” models. Our Argentinian and Uruguayan teams line up well with east coast clients and our Medellin- and Caracas-based teams line up best with midwest and west coast clients. As coaches, we encourage our teams to establish their own identity for the client. Rather than just “Client A’s team” they’re the “Raptors”. These kinds of things really help establish a closer connection between our team members and the client-side team members.
Closing Thoughts
Distributed teams are a less ideal structure than having co-located teams. We lose a lot of the benefits that having the team in the same space provides. But we can still be productive and feel like a team even if we’re remote. Just a few changes to ensure communication and collaboration are not just possible but actually occurring can make the difference between a good team and a great one.
Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)