We’ve been busy building a mobile application at Espeo. We had a remote software team which 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.
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 our remote software team 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).
Wyświetl ten post na Instagramie.
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 behaviors 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:
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.