We’ve been busy building a mobile application at Espeo. We had a remote software team of two backend developers and two mobile developers — one for Android, and one for the iOS platform. For most of the project, 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. Here’s our practical guide to getting the most out of a development project with remote software teams.
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.
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 in 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 with an overseas client — such things should be fixed much earlier. It should also be understandable for each team member and for the client as well.
Feedback is everything
Blunt but constructive criticism is essential in any software development project. Well, it always should be, though sometimes changes in the teams need some time, some wounded pride and bruised egos need to heal 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 on the night before the demo with the client
- Errors described in such a hasty manner that it was hard to figure out what to fix
- 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.
Use retrospectives and solve problems immediately
We used retrospectives after each demo (once a week the mobile devs turned up at Espeo for the demo and the retrospective), 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.
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 solid, 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’ll limit productivity
- Be flexible. 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 interpretation.
