Agile Principles: Communication

The next topic in our series on Agile principles is communication. (Previous articles of this series can be found here: customer satisfaction, change vs planning, team.)

In a nutshell: Agile puts personal communication first. This is underlined by the sixth principle of the Agile Manifesto: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” But what does face-to-face really mean? And who should be considered a member of the development team?

Before answering these questions, let us examine the rationale behind the principle.

Effectiveness and Efficiency

Although the terms are often confused in professional literature and especially in translations, it is important to distinguish between effectiveness and efficiency. 

Efficiency refers to how much effort is needed to accomplish something. For example, sending a product development request via email may take three minutes, while arranging a personal meeting may take half an hour plus travel time. In this case, sending an email is clearly more efficient. In the short run.

Effectiveness is a broader and more general term. Being effective means having the desired, expected effect, result. If the product, based on an email sent in three minutes, does not meet the customer’s needs, but a half-hour conversation ensures that all participants in the development process have the same understanding, then, even if more time is spent, a face-to-face conversation is a more effective solution.

Information transfer

If we wanted to criticize the referenced principle, we could only argue with one point: “The most effective and efficient method for transferring information…”. The highlighted excerpt suggests one-way communication, someone giving, and someone receiving information. But one-way transfer is rarely the goal in communication situations that arise during product development. The real goal is to create a mutual understanding, shared thinking, and to brainstorm.

A common source of error in product development is that the customer, the salesperson, the business side’s representative, misunderstanding their own role, communicates to the product development team how the product should behave. The responsibility of planning and establishing the correct behaviour of the product always belongs to the product development team, as they are the experts of it. The communication job of the business side is not about the product, but about the customer. What problem does the customer have? What does he want to use the product for? How do they want to use it? What’s important to her and what’s not? Etc.

The very problem with development requests sent in writing is that they are about the product, not the customer. The advantage of personal conversation is that it provides the opportunity to ask questions. And once the product development team understands the problem to be solved, they may see more than one solution. One is cheaper. Another is faster. The third can be delivered sooner. The fourth will be easier to extend later. The correct choice again requires the business side.

Therefore, product development communication cannot be a one-way information transfer. It requires multi-directional coordination, discussion and shared thinking. This latter, shared thinking, is supported by simple visual practices in Agile. You can read about the meaning of using colored post-its in a previous article of ours.

Development team

The shortest answer to the question asked in the introduction who should be considered as a member of the development team is: everyone involved in product development. This means not only development engineers, but also representatives from the business side, quality assurance, etc. (the specific job titles may vary from industry to industry). However, the principle does not only apply to the development team. It speaks of communication “to and within” the team. The “to” means that the proposed personal communication applies to everyone who is affected by the product, i.e. all stakeholders.

Would this mean that every little detail should be discussed with all stakeholders? Of course not. It would be a slow and costly solution, and of course unnecessary. Agility helps the organisation to identify the communication situations where simple written communication is not sufficient and to get the right tools for them.

It is unnecessary to discuss the technical details and hows of product development with customers and business experts, they probably don’t understand and don’t need to. Issues related to the operation of the product are likely to affect only a subset of stakeholders, so it is sufficient to involve them.

You can learn more about the communication tools used in Agile in our Advanced Scrum Master and Agile Leadership training courses.

Personal conversation

What does “personal” really mean? Do the participants always have to meet face to face in all cases? This question is especially relevant now with the rise of working from home.

Different levels of communication methods can be identified:

– written communication
– verbal communication (phone)
– audio and video (video conference)
– personal communication in the same physical space

As we move down the list, the amount of information that can be transferred and exchanged increases. In written communication, there is no emphasis on tone, mood, or pitch, and even emojis can be misinterpreted ?. Phone communication gives more, but the body language and gestures are still missing, as well as the nonverbal part of the communication. To understand these, the participants need to see each other as well as hear each other.

We often recommend real personal communication and working in the same physical space to beginning Agile teams. The main reason for this is that it speeds up the process of becoming a team, and developing common work practices. For experienced teams, however, it is not a problem if they have to work physically apart from each other. They already have experience recognizing when an email is enough, when to call, and when to see each other. You can read more about this in our article on the relationship between Agility and working from home.

Should we not write anything down?

The second value pair of the Agile Manifesto: “Working software over comprehensive documentation” is often quoted and is frequently misunderstood. The software word can be replaced with product in other industries.

We always emphasize that the value pairs of the Agile Manifesto do not intend to eliminate the elements on the right side, but rather to find the sufficient minimum from them. The main purpose of the elements on the right side is to assist the element on the left side, for example, the main value of documentation (with the exception of some industries) is that it contributes to the creation of a working product. Therefore, there is also documentation in agility. Probably less than in a traditional project, but the essential difference is not quantitative, but temporal. A significant part of the documentation in Agile is not prepared in advance, but during or after the meetings. The initial documentation is hopefully rough: it is unnecessary to define the small details, as we know that they will change while reaching a common understanding and personal discussion. However, the recording of decisions made during discussions and agreements is critical, so that we do not forget what we agreed on.

Therefore, Agility does not oppose documentation, but rather supports it at the right time and in the right amount. And not at all instead of personal consultation.