Skip to main content


Iga Stepniak
Dev Team

How To Deliver a Great Product With Remote Software Teams: A Practical Guide

We’ve been busy building a mobile application at Espeo. The team was partly remote, and consisted of 2 backend developers and 2 mobile developers – one for Android, and one for the iOS platform. Most of the time, the mobile part of us was truly mobile, working from home. It also wasn’t our first experience with remote software development. I’d like to show you how well it can work if you focus on the right things.


Let’s get down to basics. There are several rules to keep in mind:

 

1) Maintain continuous communication

Communication needs to be easy. We had one official channel for customer contact and one private channel, where we talked about current issues related to the project. In the beginning, we used Google Hangouts, but we later moved to dedicated Slack channels. In urgent situations we used the good old phone, but there were very few phone calls that really needed to be made.

 

2) Make sure you have really good documentation on APIs

Good documentation should be essential for any team, but for ours it was particularly important – the API had been created shortly before the developers started using it, so we were very strict in maintaining good documentation, which was immediately updated when a change on the production server occurred.

 

It is also important to get high-quality documentation from the client before the start of the project.

Sometimes, the documentation delivered by the client is so unclear that you need to recreate it and discuss it on a regular basis. With remote teams – or/and with an overseas client – such things should be fixed much earlier. It should also be understandable for each team member (and for the client too, obviously).

IMG_20151208_110645

 

3) Feedback is everything

Constructive criticism has been greatly appreciated in this project – and often utilized. Well, it always should be, though sometimes changes in the teams need some time, some wounded prides and bruised egos need to be healed… and so on. However, there’s no time for diva behaviours in a remote software project. You just need to be humble and eager to learn.

So, we immediately pointed out the things we thought were wrong, though all criticism was presented in a nice tone. We had several things to correct during our work:

  • implementation of important functionalities for the night before the demo with the client
  • errors described in such a cursory manner that it was hard to figure out what should be fixed
  • accessibility problems with the test server

We used positive feedback as well, as I believe nothing motivates better than feeling appreciated. Thanks to the feedback, our remote software programmers had a strong sense of duty and coped well with providing functionality for a demo. I tried not to control them too much. The remote morning ‘standup’ is generally just enough, as long as everything is on time. And it was – we were very motivated, which, I suppose, is the key to success for a remote software project.

 

4) Use retrospections and solve problems immediately

We used retrospections after each demo (once a week the mobile devs turned up at Espeo for the demo and retrospection), and we then coped with the few problems we had. Here are some examples:dealing with issues with remote software development

problem: the guys do not want to visit the company except for the demo once a week, because they live quite far away and prefer to work from home

action: as long as everything is going well and we’re sticking to the schedule, then why not? We want our developers to be happy and code in the most comfortable conditions for them.

 
problem: API methods have to be created during the sprint before their implementation by mobile devs. It’s not something that can (and should) be done simultaneously.

action: Mobile devs worked on mocks and later integrated everything with the ‘real’ API

 
problem: having too many communication channels hampers communication instead of improving it

action: our communication moved from Hangouts to Google Sheets, and in the next phase of the project – to Slack.


5) To sum up – what should you do with a remote software team?

If you want to work with remote or mixed teams, there are certain rules that should be obeyed.

  • employ good and solid developers, who have a high level of motivation and responsibility,
  • as the head of the team, react quickly. It’s your duty to remove all obstacles for your developers,
  • if you don’t remove the obstacles, you will give team members a good reason to make excuses – and you can’t afford it,
  • flexibility – developers have their habits, if it’s better for them to work in the comfort of their homes – let them,
  • the most important meeting should be always summarized with an e-mail. Always write down notes from the meeting, then email them (along with the action points) to the participants. Make sure you use a concise and simple language – one that leaves no room for (mis)interpretation.

 

We’ve written about deali1ng with remote teams before (we’re experts in long distance projects). We encourage you to take a look at those articles as well. And we always welcome comments and discussion

Share:Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on Pinterest

Like what you see?

Get in touch! We'll respond quickly, and we'll keep your data confidential.