{"id":7021,"date":"2017-12-13T16:25:30","date_gmt":"2017-12-13T18:25:30","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=7021"},"modified":"2017-12-13T17:47:24","modified_gmt":"2017-12-13T19:47:24","slug":"how-to-work-with-distributed-teams","status":"publish","type":"post","link":"https:\/\/blog.plataformatec.com.br\/2017\/12\/how-to-work-with-distributed-teams\/","title":{"rendered":"How to work with distributed teams"},"content":{"rendered":"

For most people, especially old-school Agile devotees, distributed work is just impossible. According to some of them, interactions won’t be as productive, there will be knowledge silos, physical kanbans will not be possible, no one will pay attention to the flow, and everything is going to explode!<\/p>\n

Well, those are all good points. Really. However, all of those are remediable. Nowadays you cannot<\/strong> say that distributed teams don’t work. You need to make it work! That is the reality of the world.<\/p>\n

But enough of whys, let’s get to how. How can we remediate all those problems? Or even avoid them? How can we be agile without ever seeing each other?<\/p>\n

Communicate, talk, say, share!<\/h2>\n

The first thing that you need to think about when working with distributed teams is communication<\/strong>. And since it is already difficult to improve it in a colocated team, you may imagine that the difficulty adjusting it in a distributed team is even higher, right? Not necessarily, actually. Those are different environments, with different challenges. And this difference is the key.<\/p>\n

If you try to adapt what you do in a colocated team to use it in a distributed one, you’ll likely fail. Things like talking to someone at their desk is not the same as a private message on a channel, for example. In the first example, other people can hear you and enter the conversation if needed. A private message is like going to a sound-proof room with your colleague and talking about something. Therefore, keep an open mind and try new things. Below I list four things that you could change to improve your communication.<\/p>\n

No more poking<\/h3>\n

Zach Holman<\/a> calls that “remote first”. The idea is that you need to prioritize the use of asynchronous communication tools when in a distributed team. That means that those poking-and-talking meetings will be converted into written discussions, or video conferences, using your preferred communication tool.<\/p>\n

“Oh, but we already use Slack!”<\/em><\/p>\n

It is not about using it; it is prioritizing its use. And that is extremely difficult. Let’s say that you have five people on site and two offshore. Those onsite need to communicate every<\/strong> minimally important thing through the communication tool, with the preference for open channels and not private chats. Otherwise, you’ll develop an information silo, will decrease trust between people from different locations, etc.<\/p>\n

Online meetings? Really?<\/h3>\n

Ceremonies and meetings are usually a dreadful experience when online, and there’s not much we can do about that… After all, the internet connection fails, you need to repeat everything ten times, the audio quality is never perfect, and it is just annoying to not interact with people.<\/p>\n

However, there are some things that you can do to improve that experience. You need to have the right tools, and a clear goal for the meeting, you’ll find more on that in this blog post<\/a>.<\/p>\n

Besides that, each person should preferably be in their own machine, even if you have some people together in the same building. In my experience, people that are together in a room tend to share information while the microphone is muted. However, that information could be useful to the offshore team.<\/p>\n

But one thing that I want to demystify is the necessity of meetings.<\/p>\n

Please, only have meetings if you need them! And that is something to consider even in a colocated team. Most people start working with Scrum, Kanban or whatever methodology that comes with their set of necessary<\/em> ceremonies. You need to think, and re-think, all the meetings objectives and check if they are necessary for your context. And if they are, check if all invited people are required. Don’t waste people\u2019s time with unnecessary meetings.<\/p>\n

But I’m in LA and she is in China!<\/h3>\n

If you have distributed teams in just one time zone, you are a lucky one. However, people usually have distributed teams across the entire world, going from 1 to sometimes 12 hours of difference. And each team needs to adapt their process to make sure that everyone receives the same information and participates in decisions over the future of the project.<\/p>\n

The important point here is to stay as a team and try to have at least part of the day (or of the week if the time zones are too different), like an hour, that everyone is online. With that synchronized time you can put everyone on the same page.<\/p>\n

Fly!<\/h3>\n

You’ll need to meet in person eventually. Not frequently though. Once a month, or even once a year, might be good enough. The idea of this encounter is to humanize people since we will often only interact with faces and texts on screen. That improves trust among everyone and brings the team back together. Think of it as a reset for group relationship. Bringing everyone together will relieve stress and improve interactions.<\/p>\n

Different places, different cultures<\/h2>\n

Culture is a crucial point to consider when having distributed teams. We often expect people to behave as similarly as we would in the same circumstances, and it can break our expectations, hence, causing stress. I’ll detail two points that I often face in distributed teams that could help you.<\/p>\n

Can I invite everyone to Carnival?<\/h3>\n

Whether you are hiring someone that will work remotely or are entering a team that has people from other countries, you need first to understand the countries\u2019 differences. I’d suggest a comprehensive analysis of the country’s culture, how people usually behave when facing difficulties, how they say things (if directly or indirectly), what are their working times and related subjects. With all that information, you can manage your expectations and change your actions accordingly.<\/p>\n

Hola, how voc\u00ea esta?<\/h3>\n

That is a very tough subject to address. What if you are working with team members that don’t speak the same language? Well, we’ve been there, and the answer is pretty simple: you need to communicate somehow, and it doesn’t matter how. Sometimes we opt for a common language, Esperanto most of the time (just kidding), and sometimes we try to learn the other person’s language if it is possible, like Spanish. But it doesn’t matter if you speak English, Latin or whatever. What is important is that, at the end of the day, you understood each other.<\/p>\n

Just give them this bunch of tasks!<\/h2>\n

Especially when you have part of a team distributed in another region, it is common to have them as a “black-box team.” It is important to avoid scenarios in which you select demands for that team, instead of having the stories being pulled by whoever is free at the time. It is better not to have this kind of differentiation.<\/p>\n

Ok, but what tools should I use?!<\/h2>\n

Before surrendering yourself to products that claim to be the silver-bullet for distributed teams, think about your process and how you can improve it. Then, if you need a tool, you’ll know what to search for.<\/p>\n

However, if you want to know some of the tools you may need, we have an already extensive guide in this blog post<\/a>. To make it easier for you, I’ll just mention some of the tools we use.<\/p>\n