Async Development Teams: Is Anybody There?

It’s 2023 and we are pretty much doing things remotely. What it means for software development is that many companies will have to figure out how to adapt to these circumstances in terms of how everyone communicates.

Asynchronous communication is what dominates remote work which is why we are talking about it in this article (you are reading this asynchronously, right?)

Keep reading my asynchronous reader and see for yourself why your idea to organize more meetings is not well thought after all!

Working Remotely 

Remote work is a modern concept. Since the IT systems are much more improved in terms of communication (screen share for example) the asynchronous communication became the thing. You don’t need to have another meeting, send an email, am I right or am I right???

Similarly, from the beginning of Scrum, nobody talked about asynchronous communication in development teams. The Scrum itself was designed for synchronous communication. In the beginning, nobody thought that things would go that far.

However, it looks like the situation has changed dramatically.

Because of progress in technology and its efficiency, asynchronous communication is here to stay. 

My personal view is that asynchronous communication is not used enough in this day and age. Let’s talk about asynchronous communication in detail and see why it’s so important right now.

What Is Asynchronous Communication?

To understand a concept, sometimes it is better to start from the opposite direction. Let’s talk about synchronous communication.

Synchronous communication means that there are two subjects present during the conversation. Someone is sending the message actively and someone is receiving the message actively. 

An actual conversation with a person is the simplest example. You have the person in front of you, you can see its gestures, observe how your words are being received in real time, have immediate replies, etc. There is a dynamic between participants.

On the other hand, asynchronous communication means that there is a sender that sends the message but without the active receiver. There is no active listening/reading.

Since there is no immediate feedback in asynchronous communication, it’s very important to have things well defined before sending them. 

For example, if you’re putting the info for the bug in the ticket, it needs to be very precise so that the person can understand what needs to be done. You need to be very accurate.

Since asynchronous communication is not dynamic (you can’t ask for clarifications) it needs to be well structured and exact. Since data is what we transfer using communication, we need to have a mutual agreement regarding data structures.

This is why it is of crucial significance, when it comes to Scrum, to have a well defined DoD and DoR so that the information can be understood by QAs and developers upfront and asynchronously. 

Since the information can be consumed later, there is a great freedom in software development to do all sorts of things asynchronously (I am talking about communication here, of course). 

For example, a truly effective Daily Scrum should be done synchronously but retrospectives for example can be done asynchronously by using deep dives. We can asynchronously accomplish a lot through deep dives, leaving only action points for the retrospective. This leads us to Scrum. 

Scrum and Communication

Scrum started originally with the idea that development teams will be together in one room. The idea was to have all the team members present during different aspects of the process. Therefore, Scrum was developed with the idea of synchronous communication.

In that sense, Scrum events are essentially synchronously organized. For example, retrospective, review, refinement, planning, daily meeting, were all thought of as synchronous events. However, just like any kind of process, this was all very rudimentary in the beginning. 

The logical question arose – is it productive for all people to be present in a single meeting? Is Beyoncé the best female singer in the world? No and yes.

For example, some people are not required in the meeting, they can be informed later with only the essential information, etc.

Since productivity is a driving force of almost anything in this world, people started to question the fundamentals of Scrum and asynchronous communication became a hot topic (not that it became attractive, just, people started talking about it, come on..)

Synchronous vs Asynchronous Communication

Since synchronous communication is more expensive, the logical step is to guide your team towards asynchronous communication. 

Don’t get me wrong, there are obvious benefits of using synchronous communication. For example, synchronous communication is good for pair programming, among other things. However, It’s more expensive and should be used wisely. 

There are some drawbacks in asynchronous communication as well (I am not gonna lie to you, we are here for the facts!)

Asynchronous communication is harder than synchronous communication because you need to have well defined handovers. You need to be very precise in communicating what you need from the other person or your team, by focusing on Definition of Ready and Definition of Done.

An important thing is to decrease the amount of time used for clarifications. You don’t want to lose time on clarifying what was your initial idea. 

That’s why asynchronous communication is slower in the beginning but in the end it does save time (just like the struggle against global warming).

When it comes to software development, asynchronous communication works inside a data structure (contract negotiation). 

Asynchronous communication enables you to “work when others are sleeping” when producing documentation for your features and code. However, by writing concisely and clearly, you’re progressing rather than blocking others.

From Synchronous to Asynchronous Communication?

Let’s go over the various methods of communication and see what can be labeled asynchronous and what is synchronous communication. 

E-documents, short videos and Scrum boards are mostly used for asynchronous communication. Emails can be used synchronously but are mostly used asynchronously. Chat is the most synchronous of these methods of communication.

Short video is used mostly for presenting bugs if it’s a screen recording. It can be used for explaining a concept, a document or a process if it’s a web camera recording.

Emails are for logging important decisions that we can look for in the future. Everything is stored and can be found using keywords.

Scrum board is an excellent method of communication for tracking progress, prioritizing tasks, visualizing impediments, and communicating with others about what needs to be done.

E-Documents is the crucial tool for asynchronous communication. It’s utilized for items that are strategically significant, such as team procedures, user stories, deep dives, tickets, etc.

Chat is another important tool for team communication. It’s used for quick questions/clarifications but also for more urgent issues. Usually over-reliance on chat alone means we are missing opportunities for using other more effective communication tools.

Asynchronous Communication and Distributed Teams

The crucial thing you need to do when working with distributed teams is to have well written documentation and transparent processes and procedures. Every team needs to know what its goal is and what is expected of them.

There is a difference between one team with distributed members and distributed teams. Inside a team, distributed team members need to be well coordinated. You want to minimize handover and clarifications or have the majority of communication done asynchronously.

One of the biggest challenges in leading effectively distributed teams are integration points. Since, for some teams synchronous communication can be impossible due to time differences, it’s important to understand various communications or intersections between teams. These are known as integration points.

Example of Asynchronous Communication in Distributed Teams

Imagine a portal as an application with many systems that are intertwined. For example, one system is a portal itself. Another is a CRM that stores info about the clients, sales opportunities, etc. The third is a system of communication between systems. 

All of these systems are geographically distributed (one is in the US, two in Europe, two in Asia, etc). Teams working on these systems are similarly spread out around the globe. Let’s say there are 200 people participating.

Every team is a Scrum team that is focused on its specific component of the broader system. Each has a product owner, developers, QAs, and so on. Considering the teams’ locations, different time zones, diverse cultures, and specific frameworks, the question arises.

How do they communicate as a single system?

First and foremost, each team must have its own area of responsibility. They are working on a certain component of the system. Each team must communicate internally about the development of that functionality. Then, they need to align with other teams on delivering it as a part of a system as a whole.

They communicate expectations using data structures such as DoRs and DoDs. After each team has agreed on expectations, they work on their part as though the entire product/feature has already been built.

Using tickets and tags, the teams are able to align. This way, each team can see what the other teams are doing and when a specific part will be completed. For example, a testing team can know when they can test a specific feature in terms of what others did, whether they built the feature, updated it, and so on.

When it comes to distributed teams and their mutual agreements, each team needs to share their expectations and define its preferred channel of communication. Then, each distributed team needs to respect the agreed channels and ways of communication with other teams. 

One team wants to have less control in language, others are more rigid, it all depends. The crucial thing is to have a well coordinated network between the teams in terms of communication.

Hybrid vs Full Remote

A lot of people don’t take the financial part of the story when it comes to communication. We all know that remote work is cheaper for the company than work from the office.

Similarly, having a lot of meetings is more expensive than communicating asynchronously. Not to mention that well known feeling when you’re in an unproductive meeting. Someone is talking too long, the only thing you’re thinking is food, my God..

While hybrid style of working makes sense as the synchronous part of communication is easier for a person (body language, easier to speak up, etc.), it is sometimes misused/overused as a compensation for hiding poor processes.

As a matter of fact, what companies are doing is they hide poor processes behind synchronous communication. Instead of improving the process itself, they are adding unnecessary synchronous communication.

Benefits of Asynchronous Communication

There are many benefits of asynchronous communication if done correctly. Let’s talk about the most important ones.

Clarity is the most important benefit of asynchronous communication which is why you need well written DoR and DoD. You can’t afford to be obscure, everything must be concise and clear. The crucial thing is to prevent additional clarifications by being crystal clear. 

If you’re describing a bug, try to describe the actual behavior as much as possible. Don’t leave anything out. The same goes for the expected behavior. 

Thoroughness is another benefit. In synchronous communication, you tend to leave out some details. Here, you have enough time to reflect and really put every relevant part in the puzzle. 

Effectiveness is crucial for communication. However, in synchronous communication, we tend to go into tangents and produce a lot of fluff. Asynchronous communication gives us the opportunity to utilize every inch of our space.

Better organization is another benefit. Live conversations are a mess. A lot of different topics, undefined terms, no sign of structure. It’s chaos. Asynchronous communication is almost always well structured, with logical points and clearly defined terms. 

Learning is among the biggest rewards when it comes to asynchronous communication. With asynchronous communication, you can find the most common mistakes in the documentation. You can find out what are the real errors, problems, etc.

Objectivity is the last benefit. Documentation, for example, should be objective and irrelevant of the author or person reading it. The written words should point to effects that are easily reproduced by others. That way, others can check what you’re saying.

The Bottom Line

Even though Scrum, software development, etc were designed towards synchronous communication, working remotely and asynchronous communication can be definitely cheaper and overall better in terms of productivity.

Decreasing synchronous communication is a way to go, but the crucial move that development teams should make is not toward asynchronous communication, but toward improvements of communication overall.

Communication is expensive in this day and age. Preventing unnecessary meetings, chats, calls, and getting to the point faster etc is the future. That being said, I hope you’ve enjoyed reading this asynchronously.