Remote development teams: three commonly heard challenges (and how to tackle them!)

If you ask us, remote agile development teams are an excellent solution to the scarcity on the technical labour market. However, having your people stationed thousands of kilometres away does demand something from your organisation.

What are the commonly heard challenges of remote development and how can you best deal with them? Are they even real challenges or just misconceptions that keep getting repeated? In this article, we will bust three myths regarding the use of remote agile development teams.

1. The time difference is a major hurdle

When you hire people abroad – specifically in Asia – the time difference does come into play. That can be difficult at times, especially when scheduling meetings or discussing urgent matters. However, the advantage of working with a self-managed team is that you do not have to be there when your developers are working and vice versa.

The Agile development method that you use with a self-managed team prescribes standard consultation moments. In the meantime, the remote development team can keep working on its own. If your project has reached a critical stage, your remote team can take care of everything while people in the Netherlands are still asleep. Besides, if you opt for a remote team in Nepal, the time difference is just three hours and forty-five minutes. That means there is considerable overlap between your respective working days.

2. Communication is a challenge

Language, distance and sometimes culture can get in the way of communication. Sometimes, intelligibility is a factor as well due to people’s accents, especially in countries such as India. On the other hand, understanding our Dutch accent can be quite a challenge for many Asians as well. It can be hard at times to understand each other properly. A fast internet connection and good cameras and microphones will make conference calls a lot easier already.

It is also very important to make sure everyone has a good enough command of English. That goes for the developers, but also for yourself (and any of your colleagues who work with the remote development team). Fortunately, verbal communication will be a relatively rare occurrence. Any communication about truly important matters, such as user stories and requirements, will happen in writing after all. During the development process, there will be plenty of “writing” as well. Tools like Jira and Slack make that process a whole lot easier. In other words, verbal communication is generally only used to make sure you understood everything properly.

“We have been working for Dutch companies for around nine years now and have had few problems with communication so far. Every remote team always has plenty of people with an excellent verbal and written command of English. During the onboarding process for new employees, we test their linguistic abilities and we help colleagues improve their language skills if they want to. On the other hand, some developers just want to sit behind their computers and build excellent software. You need that kind of talent as well.”

Babish Shrestha, Project Manager at Proshore in Nepal

3. Testing, briefing and managing take too much time

The third and final challenge associated with remote development that we will cover in this article has to do with “time.” It is often said that things like testing, briefing and managing your team all take a lot more time and effort, compared to working with an in-house team. Is that actually the case? The great thing about Agile development is that you do not have to write out your requirements in full.

You specify what the user stories are, what you expect and what goals you want to realise and the team will then draw up the requirements and the acceptance criteria. All they need from you is your verification of their work. A self-managed remote team does exactly what the name implies: it manages itself. That means you can keep your project management efforts to a minimum.

The team should also do its own testing, which forms part of the development process. You can use the “four-eyes principle,” for example. This means developers always have their work tested and evaluated by a colleague before it is sent to the client. Furthermore, any team should include a tester and automated tests should be embedded in the development process itself.