Since the beginning of this year I’m working in a remote team. There are two developers in Romania and me in Germany. To successfully develop software in this constellation, we are doing some things differently than with a team that is working in one place. This article explains what we do and why. Although these points seem to be pretty obvious, it can be helpful to have them at a list when starting with a remote team.

Train the Language

Because it’s a corporate presetting, we speak German. Even though the Rumanian teammates have plenty of experience speaking in German, they continue visiting language courses even in the running project. That way we avoid errors in the language that all team mates got used to but are nevertheless wrong.

Have a Real-Life Meeting at the Beginning

We began working in the project without having a meeting to see each other in person. However, we used the first possibility to fly in our two teammates so they can meet the people here in Germany and the customer. I think it is very important to see each other’s faces and have that first in-persona-impression. Even in digital times, real human contact cannot be substituted by technology. Every couple of months, we meet again at corporate events.

Use a Code Review Tool

Usually, technical questions regarding the daily development can be answered by doing a short pair programming session and learning from each other. That is a great way to ensure high code quality standards. Of course this is somewhat more difficult to achieve with a remote team, but possible. Our definition of done includes a code review by another developer, so code reviews are a regular thing. To document the current reviews and do them asynchronically, we use Stash.

Keep Calm While Desktop Sharing

There are a lot of situations where a developer just has to “come over” to have a look at something, maybe for discussions and code reviews. There has to be a good infrastructure that provides stable desktop sharing. We use Lync. Because of the unavoidable lag, it’s important to move the mouse and click only with half of the speed you would normally use. While explaining something, move the cursor only when pointing to something. It’s very annoying to see a wild cursor chasing over the monitor while trying to listen to explanations that have nothing to do with that movement.

Sometimes you want to navigate somewhere, for example another part of your software or another program. Say that your mouse movements are now just quick navigation. Go to where you want to go and say when you arrived there and when your mouse movement is relevant again.

Dependent on your sharing software and settings, you have to enable screen sharing for single programs instead of your whole screen. Have the preview of your broadcast in sight, for example on another screen. Now you can see what your teammates see. The preview also shows you the lag of the connection.

Use the Same Keyboard Layout

Especially while Desktop Sharing, it’s highly recommended that all team members have the same keyboard layout and shortcuts in their IDEs. It’s just overhead to change the layout or shortcuts in the middle of a debugging session and loose time and concentration.

Use a Webcam

At first, we didn’t use webcams. After explaining something in our conference calls, there often was a pause from the other side. It was unclear if the colleagues didn’t understand what has been said, if they were waiting for more input or if the line was dead after all. Using webcams solved these problems because we can see what is going on in the remote office.

Once, we had a meeting during which I explained something. During my talk, one of the remote developers started playing with her phone and realized a few seconds later that I could see her now.

Invite the Customer to Multi-View Meetings

Our customer is invited to join our Dailys and hear about our progress and discussions. That way, he is up to date on a daily basis and has the feeling of being “near” us. To enhance this effect, we all have our webcams online so we can see each other. That also brings the customer closer to the remote-working colleagues who we would not see otherwise.

Currently, we have trouble setting up a multi-view meeting in which every participant can see every other participant. We’re working on this.

Use Headsets

In the first few months, we used normal telephones to call each other. Quickly, we realized that holding a telephone receiver, typing at the keyboard and moving the mouse is not very handy. Sooner or later we would turn the phone speakers on, which was just adding to the usual noise in a big office. With (good quality!) headsets we can understand each other much better and have two hands free to type.

Have a Common Knowledge Database

This one is really obvious and not just related to remote teams, but especially important here. When working remote, all of the knowledge has to be accessible by everyone at anytime. There is no “have a look at the diagram at the whiteboard in the office” or “take that note from my desk”. Everything has to be in a wiki, SharePoint or whatever. Because we are so lucky to use the Atlassian toolchain with Bamboo, Jira and Stash, we use Confluence as our primary knowledge database.

Use Some Kind of Chat

A chat is our equivalent to talking over the screens on your desks. It’s important for short requests like “Do you have time for a meeting right now?” or “Do you know that library xyz?”. We use Lync.

Do Agile Development

Because we don’t see each other in person every day and cannot meet in the kitchen to have a coffee, there has to be another way to keep in touch with what the colleagues are working on. Using Scrum with its daily meetings and self-organizing team works great for us. I explicitly state this here because I also heard other people say that small task packets are “thrown over” to the remote site without much human interaction. I don’t think that this is a sustainable way of working together.

Make Your Management Understand Your Situation

Until here, I listed behavioral changes and technical solutions. To build a great remote team, there also has to be a working management for this team. In my experience, it is especially important to have a common understanding of the goal and the current status of the project. Failures in communication in the management level, for example having different plans for the project or making different commitments to the employers, propagate to really different situations in the teams. Management has to support the team with the solutions listed above and trust to find the own working balance.

Know the Holidays of Your Team

My team is working in Romania, so we have different holidays. Because the awesome Wikipedia has a page for nearly everything, there’s also one for holidays in Romania. Knowing the holidays of your team makes the sprint planning easier. Also, knowing some cultural background of the people you spend the majority of your day with cannot hurt.

TL;DR

To work successfully in a remote team, have every team mate practice the language, meet regularly face to face, use tools for code reviews, chatting and video calls. Also, buy everyone a webcam and a headset, do agile development and create management awareness that remote working is something different than onsite working.

Edited, 30th of July 2016, added “Use the same keyboard layout”.

Edited, 14th of August 2016, added “Know the holidays of your team”.

Edited, 3rd of September 2016, added “Invite the customer to multi-view meetings”.

(Photo: https://www.istockphoto.com/photo/businessman-using-laptop-in-a-desert-gm495083494-77804103, Stock Photo ID 77804103, master1305)