remote

Remote is the future - you just need to adapt

Rasmus Tolstrup Christensen

14 Nov 2018 • 7 min read

For the past 6 month I've worked remote on a project where none of us worked from the same location and across 2 different timezones. I want to share my learnings and why I think working remotely is the future with the right setup.

A little background

In may 2018 I started working on an amazing project, GoalStation™, together with with a new client Syndicate. I work as an independent consultant and for this project and was hired as a lead backend developer. The goal of the project was to make a digital add-on to the existing GoalStation™. GoalStation™ is a very cool setup where you can practice different football skills to increase your skills on the field. The project goal was to collect all data from each players training sessions, analyze the data and present it to the player in a mobile app. Inside the app, the player is able to follow his own results and get feedback. From a social perspective, the player can make friendships and compete against their friends or the rest of the GoalStation™ community. All in all a very cool project.

The team

When I first met with the customer and the rest of team I was on a family vacation in Rhodes. Without knowing it, this was a good indicator of how we would do our meetings in this project, online from remote locations, but not always from Rhodes :)

The app should target both iOS and android with native technology, be scaleable and look good, while still be informative to the end user. To achieve this, the team consisted of 2 app developers, a UX/Designer and a backend developer (me). We were all located in Denmark, but spread across the country and not able to meet every single day of the week in an office from 8-16. Very early on we all agreed this should not be a barrier to make a great product, as long as we always had good communication channels and project facilitation. The latter added the final team member, our agile facilitator, coach, tester, call him the man in the middle. With the responsibility to make the team work as a team with a common goal and as effective as possible. Last but not least, we had to integrate with the GoalStation™ setup to collect data. GoalStation™ is using a technology called FitLight™. This required us to work together with FitLight™ located in Canada, and suddenly we also had to deal with one more dimension, working across different timezones, more on this in a later section.

Worktime and regular meetup

Working remotely is not a new thing, but it has gained a lot of attention lately. For us working remotely also meant we would save a lot of time on commuting, also known as "dead time". You could argue you're able to a have meetings while commuting by bus or car, but why not save the time and make progress instead of a meeting, just to kill time. In our team we agreed to meet at an onsite location only once a week, known as our weekly assembly. The purpose of this day was to get the social benefits of meeting as a team in person. At the weekly assembly we would do planning, retrospective, review, meetings with the customer and all the other stuff needed to make you work in the zone all the other days of the week. It really helped us from the start of the project, and we kept this for the rest of the project. I know it's not always possible to meet once a week depending of how remote you work, but I would always recommend doing it if possible, it's a great way to make a team.

Team and technology decisions

When you work in a team of our size, you have to think about the choice of technology very carefully. Our technology stack consisted of Swift to develop the iOS app, Java to develop the android app and finally C# and Azure for the backend. Not exactly a technology stack with a great overlap. As we also experienced, this can lead to some challenges as you might not be able to help out during support and vacation time.

Meaning each part of the system can be a roadblock to the others, because of the technology stack.

In my opinion this should be something consider very carefully before choosing your technology stack. You will meet those roadblocks at some point during the development. I would recommend you always have some level of technology duplication where your can assist if required. You don't have to be the lead but you must have some knowledge about the technology. One thing I discovered during our development and didn't focus on before this project, is how we as programmers think about and solve technical challenges. Either we work as framework developers in a high-level language or we expect to build from the ground up with a deep knowledge of each piece of code. Funny enough this is very well explained in this episode of the developer podcast DotNetRocks. Something I think you should be aware of when you're working in a project with different technologies as it helps you understand how the person you're talking to might approach a problem.

If it's not on a code level it might also be pairing on design decisions or business problems. When you sit all day with your own "domain", you can easily end up with a kind of tunnel vision to solve it. You can only imagine there exists a single solution in the whole world that can solve this issue. I would always recommend to at least explain your solution to another team member when you find yourself in this situation. As soon as you start talking loud and explain, your brain also starts to listen once again. This might open your eyes and see the problem from another perspective.

Get away from the keyboard and start talking.

Remote location and communication

I mentioned communication a couple of times and I'll try to explain why. Let's start with a look at your "office" location as a remote worker. Many tend to think of remote workers as some hipster sitting downtown drinking a coffee, while working. Others think of working remotely as working from home while you try to avoid all the small things you could do while you're home anyway....laundry maybe...

To me working remotely is not working from a coffeeshop or at the dinner table at home.

When you decide to work remote, you also need to make sure you have the right office setup. This means a place with limited noise, a place where you can concentrate and have online meetings without any disturbance. I've rented an office in a shared office space, only 2 km away from my home. It provides me with all of the above. Finally it also means, I can "go to work" and "come home" to the family. This keeps a good separation between work and home. Trello has a very good guide on how to setup your remote working environment .

Okay you have a place to work, but you also need to communicate with the rest of the team and you need to communicate often. We decided to have a daily meeting, approx. 15 minutes. Very agile, with the goal to keep everyone on track and highlight any obstacle. Most of the time we just used audio and screen sharing when needed, but...

I would always recommend to use video when working remotely. It always improves communication when you can see the person you're talking to.

Our daily meeting took place at the same time each and every day, and it only required we agreed on a time of day where we would all be available online for 15 minutes. The rest of the day we could work on our own schedule. This seems like a huge freedom and it is. Still we found it effective to have an overlap of multiple hours where one or more of the team members were working at the same time.

If you make your features small enough, this also makes it easier to manage the time when you need to be available at the same time.

Mixed timezones

As mentioned the integration with GoalStation™ was made with a technology called FitLight™. FitLight™ development is located in Canada and this meant we needed to work across timezones, when we needed to talk directly with one of their developers. After some initial attempts we decided on a fixed time where we could have these meetings. For us in Denmark, this meant at the end of our workday and at the start of the workday in Canada. Again we used video most of the time and it helped a lot. Of course we sometime had to wait additional hours to talk about a feature, as we tried to avoid working late hours.

Tooling

No doubt tooling played a huge impact on how our team worked, and we tried many different tools to always improve our ongoing communication and task tracking.

Say goodbye email....

One thing we discovered early on as a no-go tool for communication was email. We needed better conversation tracking and not a mail thread mess. We used an online task board to keep track of our work items, in our case Azure Boards from Microsoft. As we also kept our sourcecode in Azure Repos, this was an easy tool to get started with. To keep track of external communication we used Trello as a task board. For us Trello provided more flexibility and if possible I would recommend only using a single tool. The board was also used at our daily meetings to track progress and obstacles.

For video and audio meetings, we used a combination of Slack, Skype and Zoom. Zoom was the most stable video tool, best in sound and video quality. It even provides an easy way to share the screen of your mobile device, a really great feature if you're developing a mobile app. We used Slack as an ongoing chat where we didn't expect instant feedback. To avoid the noise a tool like this can produce, we made separate channels for each feature we developed. This worked very well and reduced the noise of slack quite a lot.

The last tool we needed was a tool for file sharing, here we decided on DropBox. This worked ok, but we had mix of personal and work accounts, causing some storage space issues from time to time. When working with files you also need to think of versioning as with source code.

The terms "new" and "old" along with manually file versioning is not an option. You need to find a tool that provide you with version control and use it.