Communication Problems with and Within the Development Team
Communication Problems with and Within the Development Team
Communication within teams of developers can be difficult without proper clarification and extesive planning in communication.
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
Misunderstandings at work can have many causes, especially when complex problems need to be solved. One of the reasons for the misunderstandings can be the description of the problem, which can be incomplete, wrongly written, or incorrectly interpreted.
In this article, I want to mention some conflict situations and their possible causes. The reasons for the discrepancies can be the team members' personality, the knowledge, the ways of thinking based on their backgrounds, or the industries where they've worked.
This article is dedicated to the daily misunderstandings at work, such as when people from many different departments are involved in a conversation about a new feature, and each participant creates his own (possibly incorrect) assumptions about its structure.
One cause can be the terms which are used for explaining different things which sound similar. Talking about the same topic on the abstract level looks very different from the point of the view of each person.
Other goals for writing this article includes exchanging experience with other developers about this kind of problems and finding solutions for them. It is also an introduction to the beginners in the software development industry to this kind of unpleasant situation which is something normal and happens often during the working day.
There are different reasons why the team has problems while planing features, but only two are highlighted in this article:
- Background (education/industry) – when the colleagues have different educational background or come from different industries. When working longer in the same industry you are learning new terms and new work approaches, which leads to a new way of thinking and talking. An outsider who is not familiar with this knowledge can potentially lead to misunderstandings.
- Culture – when the colleagues are from different countries or different parts of the world, then the culture is an aspect of different way of thinking and communicating.
The following diagram shows the two criteria and their weight, which influences the complexity of the misunderstanding problems.
Different Way of Thinking
From the diagram we can read out several cases where we can interpret them as difference in the way of thinking depend on the culture and the background of the persons:
The larger the bounding line, the higher the possibility for misunderstandings.
Same Background, Same Culture
This is the Case A where the initial person communicates with the person A (person - person A).
The difference between the two aspects of the individuals is low, which means between them there will be the fewest communication problems comparing to the other cases. They will have the same language of communicating, doing it fast and almost failure free.
Same Background, Different Culture
This is the Case B where the the initial person communicates with the person B (person - person B).
The colleagues are working in the same department, or they are sitting on different parts of the planet and communicating in the same language, which is usually English. In this case the same term or sentence from another language can be misunderstood or incorrectly translated.
Different Background, Same Culture
This is the Case C where the the initial person communicates with the person C (person - person C).
This case can occur when the colleagues are working in different departments which implies they have different backgrounds. Here a problem can occur when they are talking about the same topic but have different associations with it.
Different Background, Different Culture
This is the Case D where the the initial person communicates with the person D (person - person D).
This case is a combination of the previous two cases where the person's competencies are most different. The culture differences and the distinct backgrounds increase the chances of misunderstandings. Much more communication is needed here until both sides are synchronized on same know how level and communication level.
The intensity and probability of the following examples depend on the differences explained before. The more the difference is, the higher the probability for such a mistakes. The following examples describe several problematic situations which result are based on the previously mentioned aspects, the background and the culture.
Global vs. Criteria Dependent List Creation
A list for an GUI drop-down menu has to be filtered, meanimg some drop-down options are displayed but disabled (they can not be used for selection). On defining the features it was talked about was a general list creation which is executed only once, when the system starts. But during the implementation it was noticed that the list needs a new creation method which is triggered by particular GUI interaction. Redefining the behaviour of the feature made its complexity higher.
To avoid this situation, an early recognition of the issue is recommended by more discussions about the detailed feature.
This problem can occur in all situations mentioned above, but the probability is different and it increases from A to D.
One Property vs. Collection
As a developer you certainly had a situation where a property of a model (bean-class) needs to be exchanged with a collection of it. Not only changing the class but the code where it is used can be very time consuming task which sounds easy at the beginning but can lead to complex refactoring.
A solution for this case is an early recognition of the property as collection an its appropriate implementation.
This problem can occur in all situations mentioned above but the probability is different and it increases from A to D.
The same term or sentences from one language to another can be misunderstood or mistranslated, which results in misunderstanding. Here, rethinking and rebuilding of the sentences is needed so the real idea behind them can be understood correctly.
This problem is culture-defined, therefore, the cases B and D can be the causes of the most misinterprestation.
Same Term Different Meaning
Communication between be difficult if persons of different departments or companies use same term for different things. This leads to problems which will be visible later in the middle or end phase of the product development and the changes for implementing the feature correctly can be very expensive.
Since the translation part is clarified above, this example is meant as translation independent and from the same culture, so this problem background can also be C and D.
With translations problems this situation will be worse and will occur more often.
Different Term, Same Meaning
This leads to confusion if the definition of certain terms are not known for the person who is hearing and reading the content. Knowing that the different terms point to the same thing makes the understanding correct and easy but only if the persons know that.
The persons involved in the meetings need to be educated about the topic and the terms used there beforehand.
Since the translation part is clarified above this example is meant as translation independent and in the same culture, this problem background can also be C and D.
With translations problems this situation will be worse and will happen more often.
Solving these kinds of problems can be done with discussions and a good description of the task. If the description changes, then everybody who is involved into the specification process has to be informed. Also planning enough time for the specification and high commitment are welcome.
Some suggestions for solving or softening this kind of problems are listed below.
Sense of Problem Understanding
Sense for specification understandings, which tells a person when the information was recognized correctly, is needed as well. This sense can only be trained by having high knowledge about the topic and enough experience in working on this kind of projects. The more people who are involved in the specification have those skills, the fewer misunderstandings.
Communication Quality and Quantity
Communication quality means the way of communication and how often the communication is done.
When a feature is more complex and large, then much more communication is needed. The communication process should last until all question are answered.
The best way of communication and explanation is done by writing texts, e-mails, or using a project management system. Creating diagrams for the processes and the system structure can be very helpful and impove the understanding of the system in general and in detail.
Mediator or a Middleman
A person who acts as a "translator" between the departments or companies can be employed whosd has the task to stimulate better understanding between them. He will be responsible for communication between the parties, acting like an mediator. His duties are to get the data from one partner, then "translate" them and sent to the other communication partner. For this task knowledge about the topic is needed and about the way of communication of the both partners.
Is this an issue only in the IT or also in other industries? Maybe this can be seen as one problem or part of the IT because of its abstract nature and the globalization in which the collaboration takes place everywhere on this planet.
Do we need "translators" for solving this problem, persons who translate the ideas between the partners in the right manner? Are middlemen necessary for solving this problem, or do the parties involved in the working process need to have extra communication and professional knowledge?
Maybe there is another solution for this problem which is not mentioned in this article, which exists and is described in other writings and is used in the practice.
Note: All solution proposals in this article have theoretical nature.
Opinions expressed by DZone contributors are their own.