I’m copying this post verbatim from an old blog. It was originally written on August 2011. I found it while searching for my old posts, and it was quite a surprise to find this. I had forgotten about it, and it is still a relevant topic. Both because my current project is also distributed, but also because we are seeing more and more people working remotely these days.
My current assignment is done together with a distributed team, in a different country. From time to time we have new projects starting with them. Usually we travel to their site, but once in a while the whole process is done remotely.
Normally, our inceptions take from 1 to 2 weeks. At first, a Distributed Project Inception may look like any other normal meeting we often do (it’s worth to remember that we also do remote stand-ups daily), but I assure you it will become a nightmare if you don’t make some proper decisions at the beginning of it.
Based on my previous experiences here are some ideas you might consider when doing your Inception, or even any other kind of meeting where part of the team is not physically present.
Use proper tools
A distributed inception or meeting in general can go all the way down if you can’t understand what is going on in the other side. To properly understand what the guys on the other side are doing/speaking, you need good tools. I’m not only talking about a clear voice reception, which is mandatory, but also video, which is just equally important. It’s way better to understand what is happening on the other side when you can see the actions of the rest of the team.
Furthermore, don’t forget about mic, speakers and camera. There is no point having the best tool if the microphone or speakers you are using are crappy as hell. Nowadays We’ve been using a ClearOne Chat 60, which is working successfully with a team of about 10 people. That stands for cameras as well. Avoid using that cheap one that comes with your old laptop. Instead, use a good USB one with enough resolution for the task.
By the way, another very important thing to keep in mind: if you have a camera, use it! Don’t hide on the corners trying to avoid it. Speak on the front of it, so that the rest of the team can see you. That’s very important for a good communication.
Have a plan B
Bandwidth can be a problem. Depending on where you are, power supply can be problematic as well. There are several things that can go wrong during a remote meeting. And like Murphy once said, “anything that can go wrong will go wrong”. Along with one of the tools cited before (or any other of your preference), think about having a open phone line muted and with the volume down. If the first one fails you can quickly switch to the second option until the service is reestablished.
Don’t forget time zones and daylight saving time
It might happen on the first time and you really don’t want to miss the meeting just because you got confused with the clock. That’s easily avoidable by using a calendar application that support multiple time zones.
Laptops/cellphones/etc are not allowed
During meetings, it is deadly easy to lose focus. This is even worst when the rest of your team is across the globe. As soon as get minimally lost in a discussion, there is a big change that your next move is pull your cellphone and check your e-mails. That will soon lead you to twitter, facebook,… you name it.
This rule applies to any kind of nearby toy as well. It’s better to just leave them outside the meeting room and come back to them after your meeting is done.
Let the remote side read what is on the screen
It happened several times with me, where the other side is driving a shared screen and the person driving the computer keeps moving the browser/spreadsheet/whatever up and down, changing windows, etc, and the screen on your side never get’s updated with what they are actually seeing. All you see is a messy image with a lot of pieces of several applications :(
Every time that a new point is about to be discussed and part of a document needs to be read out loud, let the remote side (the one that is not driving the screen) read it. That will ensure that they also can see what is being displayed. Better yet to not have a fixed guy, but doing that interactively, choosing another person each time.
Time boxed tasks
No matter how good is your tooling, it’s very tiring to have remote meetings. You spend a lot of effort to understand everything that is going on: different voices, accents, subjects, etc. So, don’t think you have all the time in the world to discuss that specific subject, and even if you do, that’s not productive. The more you take to end a conversation, more tired will be the participants and, likely, worst will be the final result.
That’s why you should define a time box to discuss a specific topic. For instance, having a frame of 5 to 10 minutes to discuss a story and the the tasks related to it. That will make everybody focus on the current goal, leaving aside any kind of distractions.
Use big screens/projectors
Com’on, they are getting cheaper day-by-day. Even if your team has only 3 people, why put everybody staring at a 17” monitor? That will harm your health and make you burnout faster.
If you have different stuff to be shared, like the video for the other team and also some application screen, look for a second monitor, or as many you might need to nicely display all the shared information.
Remember the rest of the team
Although they are not sitting at your side, they are there and they do want to hear what you have to say. Avoid speaking only with your local team or have side conversations. Don’t forget that muting your microphone can be very impolite too. It’s weird to see mouths moving on the TV, but no words coming out from the speakers. That opens room for various assumptions on what is being talked on the other side.
If there are too many people talking at the same time, consider using a token on each side. Only the person with the token is allowed to speak and after finished, he/she should select the next one to have the token.
Feel free to request someone to repeat of what he/she just said. It’s important to have everybody on the same page and to remember that they are part of your team, and not as “the guys on the other side”. You’ll probably need them to have a successful project.
That’s what I can remember so far.
- RFID, Dryers, and IoT
- Trunk Based Development with Multiple Services
- Problems with Branches per Environment
- Services Version Lock with Docker and Jenkins
- Secure Configuration Management for Microservices
- Efficient Timer using a Circular Buffer
- Learning From My Mistakes: Building a Crawler
- Circuit Breakers and retries in Scala with autobreaker
- Integration testing for nginx Routes
- Blockchains as Part of the IoT Architecture