Communication with your Offshore Development Team – Introduction for App Owners

Are you afraid of hiring a remote development team because of a lack of control? Do you fear your money will be wasted due to inefficient communication? Do you think the time zone difference will ruin your communication?
If yes, you are in the right place.

In this post, you’ll learn why communication is crucial for your app development process, how asynchronous communication works, and what benefits does it bring for you.

Why communication is hard

Before developers, clients, and Product Owners…, we all are human beings. Communication between people is difficult by nature. You probably have many examples when improper communication was the only reason why somebody got upset or sad, even though nobody had such intentions.

What exactly is communication? I’m no scientist, but to me, it’s sending messages from one head to another – leveling the information gap between people. Messages are being sent one by one. See this diagram showing how complex communication is on the scale of only ONE message:

Source

Now think about how many parts can fail in the process:

• Sender – maybe the sender is incorrect (for example, a non-technical project manager trying to send a technical message that a developer should have sent instead)
• Encoding – maybe you used a wrong form of encoding (eg. used a word that the other person doesn’t know)
• Message – maybe the message contains too much information or too little? You rarely know the answer until some feedback is given
• Decoding – maybe one word has many different meanings and the receiver picks the one you didn’t mean?
• Receiver – maybe the receiver should be someone else? Maybe it should be the whole team instead of one particular person?
• Feedback – maybe there’s no feedback at all, and the sender doesn’t know if the receiver understood everything correctly?
• Noise – maybe the sender made a few typos in your message, and the receiver misread one of the longer words in the message?

Of course, the errors on different layers add up. Now think how many messages you send and receive every day, and try to determine if the “information gap” has really been leveled or it’s just an illusion.

Why communication is important for successful software development

In IT, it gets even worse. The IT world is pretty complex by nature and, therefore, the message itself must often be big and/or numerous. This means that each level of communication has more chances to interfere with the message in the wrong way.

Think about it this way. The application that we’re going to create for you has a technical level (which is our expertise) and a domain level (which is your business problem). In order to write the perfect app for you, we need to understand your domain to a perfect degree. In fact, we can only implement our understanding of your domain. Therefore, it’s extremely important for your success to communicate your domain and ideas as efficiently as possible. Read also: What is Product Discovery in Mobile App Development?

On our side (the development team), it’s the same story. We need to communicate the progress, challenges, technical obstacles, etc. as efficiently as possible, in order for you to make the best possible decisions.

I’m a developer and, from my point of view, communication is the bottleneck of software development. Typically, for a product to be better, there is no technical limitation, it’s only the goal, problem, requirements, the idea of implementation, etc. that are not clear by some sides.

The theory of constraints advises us to improve the bottleneck. So, if you want a better product, you should improve communication in the first place.

This is especially true in 2020 when a lot of teams and companies have undergone deep changes. Even if they didn’t want or weren’t ready for it, they needed to switch to complete or partial remote work. They were forced to abandon their past communication patterns and habits, learning new ones in the process.

Before going to more precise pieces of advice, let’s introduce who you can expect in your offshore team.

Who is who & assumptions

In this article, I’m writing about the Scrum team, because Scrum is the most popular agile framework and a significant part of our craftsmanship. In Scrum, there are three roles:

• Product Owner (PO)
• Development Team
• Scrum Master (SM)

Even if you decide to not use Scrum, we’ll insist on nominating a Product Owner on your side because it’s a necessary role in agile development. The Product Owner is a person, typically chosen on the client’s side, who is our decision-maker. If you need more details, you can read our blog post about app development in Scrum.

From the perspective of this article, there is a couple of important assumptions worth highlighting:

1. The PO will most likely be onsite (this might be you, for example), while the Development Team and Scrum Master will most likely be offshore.
2. It’s extremely important that the PO is one – and only one – person. You’ll learn why later. Get a free Ebook – Guide on how to be a great Product Owner.

The biggest mindset shift you need to employ as a remote App Owner

Effective remote communication is asynchronous. If you haven’t already, you need to switch your mindset to asynchronous communication, instead of synchronous.

What does synchronous and asynchronous communication mean?

What’s the difference between asynchronous and synchronous communication?

Synchronous communication

For synchronous communication, think of office-like interactions. Each side of a conversation needs to be in the same time (the same place is not necessary but advisable). For example, a meeting in a conference room or face-to-face interactions. Sometimes the same place is not needed (think online meeting), but in my experience it is desirable, and still requires the same time.

Asynchronous communication

In contrast, asynchronous communication is when you don’t require participants to send and receive messages at any particular time. For example, instead of announcing some message at a meeting, you can write an email. In general, writing instead of telling is a great step towards asynchronicity.

To be clear: this doesn’t mean that much time must pass between sending and reception. We only allow for such possibilities in this model.

At first glance it may appear that it’s a much more costly way of communicating – people can reply much later than I need it! In practice, because of this assumption, people learn how to communicate more effectively, make reversible decisions by themselves, and waste less time in the run.

Of course, it also has lots of other benefits.

Key benefits of asynchronous communication

• People are free to utilize their time. For example, they can read and reply to all the messages after finishing a Pomodoro (a very popular technique among programmers).
• Asynchronous communication is long-lived. A face-to-face conversation can be hardly forwarded with exactly the same message. The same message, if written in an email, can be forwarded easily and quickly, and is also searchable, quotable, etc.
• Because of the aforementioned “forwardability”, it’s transparent to people not present at a hypothetical meeting (and for example new members of the team in the future).
• People can read the message as many times as they need, and take as much time as they need to reply.
• It’s an easier way of communicating than speaking directly for people who tend to be shy in person.
• It resolves numerous problems – time zone differences, connection issues, finding a common time slot for a meeting, etc.

When to be asynchronous

• It is true that on a smaller scale (2-3 people) face-to-face communication (and therefore synchronous) is more efficient. It is even advisable in the Agile Manifesto – a famous paper made by developers who wanted better products. If your team is of this size, you need to reconsider some points of this guide. However, when hiring an offshore team for writing an application, you can expect a team of 4-8 people. On that scale, synchronous communication starts to be not only problematic but also too time-consuming to convey. So asynchronous communication would be better here.
• Regardless of the team size, there are other factors that favor asynchronous communication, such as geographical differences or remote work.
• The recommendation in this series are also valid if you want to focus on asynchronous communication for any reason (there might be many reasons for this: you need more information, you want your team to be bigger soon, you live in a problematic timezone, and so on).

Let me repeat. Your remote development team will have a higher chance of success if they are free to work and communicate asynchronously.

Wrap up

Communication is not a piece of cake, yet it’s extremely important, especially in software development. Mistakes can be made on different layers. To improve your communication with your offshore development team you have to tackle the most fundamental feature of it – that is, you have to turn it all into asynchronous communication.

If you’ve employed this mindset and understood what it is, as well as why it’s important, you’re halfway through.

In the next episode of our series: How to Communicate Asynchronously with your Development Team – 8 Tips, you’ll find a few pieces of advice on how to achieve asynchronicity. In the third episode, I’ll share a few secrets for improving communication overall and not just for asynchronous methods, so be sure to check it out even if you’re using synchronous means. Stay tuned!

Related posts