Starting my job at Viacom as Android Lead brought with it something new: working with a distributed team. I worked before in global companies with meetings via video conferences, I worked from home here and there so we did the standup online. But it’s different when you have your team spread over different offices.
In our team we are two people in Berlin, four developers in Poland working from Szczecin, Lublin and Wroclaw plus one developer in our headquarter in New York.
Having seven developers in five locations meant that we truly needed to build a remote team culture.
Face to face
When you run into such a setup, it is crucial to get to know each other! This is much more important than any tool money could buy.
We all met in Szczecin and Berlin in the beginning and this proved to have been so important. We discussed how we wanted to work together and what we needed to do to improve the code. But more importantly, we spent time outside the office together. So, leave the office and get to know each other. Without knowing your team members you can never be sure how a sentence, emoji, or gif was meant.
The communication tools we used in the beginning were Hipchat and Skype. But switching to Slack improved the communication a lot. It’s hard to tell why, but this is a phenomenon that lots of teams feel when switching to Slack. We even ended up having a channel for sharing pictures from the meals we ate all around the world.
We didn’t have to wait long before people started customizing Slack. After a while we had lots of custom emoji and hashtags with animated gifs like
Slack ended up playing a big role in creating a team culture and in bringing us together more.
Our QA team is distributed as well: Minsk, New York, and Berlin. So, they also joined us on Slack. We started a
#jobmarket channel where QA gets informed of tickets or builds ready to test and this improved the communication between development and QA and sped up our feedback cycle.
You might ask, "Why not emails for this?" We all use email and to be honest, our inboxes are full of notifications, including, of course, from JIRA. The problem is that you get swarmed by those. Using a more direct, but, less intrusive way for communication helps a lot. So, when QA creates a new ticket there is also a notification in a Slack room (similar to when a new pull request gets opened or a build fails on CI).
For those Slack rooms, no one needs to look at this. Someone in the team will see the chat notification at some point and can react. This is different than the whole team getting a direct email.
Our source code is hosted on Github and we work with pull requests and each pull request requires two approvals. When your colleague is not sitting next to you it’s harder to communicate changes about a pull request. You need a different mechanism. Could Slack be a solution? Not really, because people don’t look at their chat all the time and you should not expect immediate response in such an environment.
It is a good practice to mute Slack with
/dnd 25min while working in a Pomodoro cycle, for example. But, then the next time you look at a list of pull requests it’s important to see the status to see what you missed.
So, we started using labels in GitHub a lot. We categorize the PR in size:
urgent. We update its status:
comment to new or previous reviewers: question, recheck
An important one for us: everyone can flag a PR as
needs_manual_qa if it might affect functionality outside the ticket. This way we make sure the approver checks not only the build but starts the app with the changes.
In a normal office situation you talk to your neighbour about the code you are writing or planning to write. How does this work remotely? Chats do not really help here as you might need to show code or just talk to someone. We found Screenhero, a tool acquired by Slack, where both users have control: two mouse cursors that work in the same time. Unfortunately our network wasn’t good enough for pair programming via Screenhero but we still believe it’s a great tool.
Have a Backup Plan
As we all know nothing in software development works perfectly. Things happen. So don’t be focused on one tool. If Slack video chat does not work, be ready to move to Hangout or Skype. Be pragmatic and don’t spend too much time in trying to fix the tool.
Agile stand-ups are done, as usual for remote teams, via video conference. But remember it’s called a standup. Let people stand up and get away from their computer for a few minutes.
No one likes meetings but in a remote environment, communication is very important. We ended up having a separate tech meeting to discuss together once a day. This might be done in 10 or 45 minutes, depending on the topic
More Face to Face meetings
Meeting each other is important, not only in the beginning, but all the time. It needs to be a continuous effort.
We try to meet from time to time and this is where the big architecture discussions happen. No video conference can be a replacement here. Because of the different locations we try to find a place that works best for all or us. For the German and Polish teams Warsaw, for example, works out very well even if we have no one there.
Of course it’s not always possible to have everyone like with our US developer. In those cases we try to bring them in for some topics on a monitor. Give isolated team members a presence in the room!
Some companies try to save money by having their developers in cheaper countries. But you need to add the costs of travel for the entire team. At least if you want an effective and well working team!
Remember the manifesto
When you think about lots of the changes mentioned it is a lot about reapplying the agile manifesto. Because it can be really easy to fall back in time once you start having remote developers. Remember the manifesto:
Individuals and interactions over processes and tools.
It’s about making sure communication is great. Don’t go back to emails and don’t rely on a specific video or chat tool just because that’s what is in place.
Use a piece of paper and hold it to the camera if it's easier and faster than using a fancy tool to draw via screen share.
Working software over comprehensive documentation
Don't start writing specifications that you would not write for a local team.
Getting the communication right is the key to success.
I learned that we can make remote teams work really well. Some things are harder and need some time and money investment to keep the team motivated and focused. But, it also opens new possibilities. Not everyone would move for the next job, so you may find that you can work with the best talent even if they are not from your city or country.
And don't forget, it does not matter if you have a remote or in-house team, create a fun environment to work in.1
special thanks to my great Playplex team at Viacom, thanks to Florina Muntenescu for helping with this article and the attendees of Codefreeze Finland for their ideas ↩