Asynchronous Communication and Real-Time Communication – Both Regular Communications

Let’s first look at the following example:

Asynchronous Communication

Many companies now provide their employees with free milk or beverages. But when you want to drink some milk in the morning, you may find several opened cartons in the refrigerator, and you have no idea when they were opened. This situation will be worse on Monday morning. Everyone knows that milk should be consumed within 24 hours after opening to ensure of safely. Given this, when you are not sure when the milk cartons were opened, you have to open a new' one, then there will be another opened carton in the refrigerator.

So, is there any easy solution for us to know which carton of milk is safe for drinking? There are ways, of course. On each milk carton, there is a blank area for us to mark the time of opening, which will banish everyone’s worries. In this case, some figures (the time) play the role of asynchronous communication.

Theoretically, asynchronous communication means that in the dimension of time, information is generated at one point in time and circulates from one person to another, and another person receives this information at another point in time. Asynchronous communication is off-site communication, that is, two people deal with the same information at different points in time. It is somewhat like the traffic offence penalty, if we break any traffic rules while driving on road, we may receive the on-site penalty by the traffic police, or off-site penalty if our offence is caught on camera.

The offshore teams in different time zones rely on such asynchronous communication most of the time. When adopting this kind of communication, we must, from the very beginning, convey enough information and think from the other party’s standpoint, since their context may be different from ours. Although comprehensive and intact information may have something redundant, the foremost thing is to ensure that the other party can get all the required information, and even make a choice.

When working with the offshore teams in different time zones, we need to reduce the adverse impact of asynchronous communication and increase the opportunities for real-time communication. Therefore, the offshore teams are sometimes asked to change their standard commuter time to overlap with the customers’ working hours. But such adjustment shall be made carefully, since any change in working hours may affect team members’ normal life and even their work morale. We shall not only pay attention to the benefits of changes, but also guard against their potential impact, especially the negative impact.

The method of User Persona, which may be taken as an example for improving communication, is used for analysis of requirements. User Persona itself is the product of information extraction, and it represents a specific group of users. After information extraction, it will be easier for people to draw consistent conclusions on some matters. But we should be careful not to confuse it with User Role. The difference between them is that each User Persona corresponds to a specific person, and such concretization benefits empathic thinking, which is the greatest value of User Persona; while User Role corresponds to software, and it is mainly used to distinguish the permissions of different users technically.

Through the document collaborative approach, we can maintain the documents of the latest version, but do we need to mark the changes in the new version? We should think empathically: when a customer opens a document and finds that it has been updated, but he has to read through the document to identify which part is updated. It would be much convenient if the updated parts are highlighted in different colors.

In addition to information (including requirements), many practices that deal with codes are examples of asynchronous communication. For distributed teams, when they are communicating about the code base, it seems like they are involved in a war without smoke every day. The codes themselves must play a role of communication, while the naming conventions for codes are a basic requirement.

To test an executable document, the name of each test method shall be clear enough to reflect the purpose of the test. For example, if we are going to write codes to test the Magic Guess game in Wenquxing (a kind of electronic dictionary), the codes of the first test method shall be as follows:

should_return_4A0B_when_there_are_four_perfect_numbers_in_the_guessing_ numbers.

As shown the name of the test method, we can know that our method of comparing numbers should return to an appropriate value when certain conditions are met. If we follow the above standards to write codes for testing, then when we manage tests, we can find a set of documents describing software functions.

There are some prerequisites for communication: first, communication should be based on a common understanding of all the conceptual terms involved; second, communication should be based on a common understanding of all the practices involved.

Asynchronous communication means that the two parties do not read the information at the same time. This requires the sender to fully consider the conditions and environment of the recipient, ensure the absolute integrity of the information, and organize the information effectively. The recipient of the information must fully understand some “routines” of the sender, and when the information is incomplete, he can deduce the full picture of the information to the greatest extent possible, because the missing part of the information is often taken for granted by the sender.

Sometimes when we detect a problem, we may immediately reflect it to the customer team, since we are eager to demonstrate our proactivity. But we need to know that the personnel of offshore teams changes from time to time, may be someone has already reported the same problem to the customer and figured out a solution, so we should first try to find ready answers inside our offshore team. In the opinion of customers, they always take our offshore team as the same one despite of any personnel changes. If we discuss with them over the same problem time and time again, they will doubt our communication ability. In a word, active communication is sometimes not a good thing but a blind behavior.

Due to the reliance on asynchronous communication, a principle for remote working is to avoid making decisions at the last minute. It sounds to contradict with the lean theory, but it is actually not. If we have a project that requires for input and decision-making, then we need to collect feedback information before the project implementation. We cannot expect to get an answer right away, since the working hours of collaborating colleagues may differ from those of ours.

We shall spend more time thinking and preparing the topics of asynchronous communication. Although this seems like extra work, it will eventually make asynchronous communication more efficient. For example, the meeting is planned in advance, usually once a week, and its topics are based on the discussion of the entire team, so that all participants may reach an agreement rapidly. This also eliminates those annoying impromptu meetings initiated at any time, which not only deprives offshore team members of the opportunity to participate but also distracts their attention to work, forcing everyone to switch contexts in their minds.

The popularity of shared documents has technically solved the problem of information consistency between different teams. When one team needs a piece of information, it may take the initiative to find the location where the information is saved to get the latest data.

Real-Time Communication

Compared with e-mail and shared document, instant messaging software and video phone are more direct and efficient means of communication. And all of them are comprehensive means of communication for resolving the differences in both time zones and geographic locations between distributed teams.

When choosing an offshore team, it is seldom to see the circumstance of no overlap of working hours, because it is one of the key factors in choosing a team at the beginning. Of course, the degree of work time overlaps has a certain impact on the communication mechanism of distributed teams.

■ Few work time overlaps. Arrange real-time communication as much as possible within the overlapping working hours of both parties, such as stand-up meeting, IPM, seminar, and brief meeting. In addition, they shall learn some skills to improve the efficiency of asynchronous communication.

■ Many work time overlaps. In this case, we can invest more energy and employ more advanced means in real-time communication. Organize a nonstop video meeting where a large screen is erected to display the work area of all parties, everyone can directly walk to the screen to make a statement. By performing the automatic answering function of the software, we can simulate the scene where two parties are working together: remain quiet when no one is making a speech, and automatically get through to each other when someone makes a call.

Real-time communication includes direct communication through video, recorded project introduction, or complicated defect recurrence. In many cases, video is the cheapest way to communicate, because it could be no more easier as compared with preparing a separate document for explaining a problem. But most people’s understanding is just the reverse, that’s why document description is still used most of the time despite of its highest cost and worst effect.

 
Source
< Prev   CONTENTS   Source   Next >