We all have to communicate with each other on an everyday basis. In private life, at school, at work. Everywhere and all the time. Some have better communication skills than others but at the end of the day, we all make mistakes every now and then.
While some miscommunications have a minor impact on our lives (it’s not the end of the world if you order a non-alcoholic beer ;)) some may have greater consequences (pointing out the wrong tooth to be extracted). Misunderstandings in communication in software development are rather the latter and may have financial implications.
One of the most common problems we all have is assuming that another person can read our minds. We’re all guilty of this sometimes. Have you ever heard this phrase: ‘It was obvious!’? I bet you have.
I don’t believe in objective obviousness. We think that some things are obvious to everyone, but what’s clear to one person, may not be so apparent for others. To achieve effective communication in software development let’s stop believing in mind-reading and just say what we have in mind.
Why is that easier said than done? Let’s analyse the communication process first.
Elements of communication
More than 50 years ago Roman Jakobson presented a communication model that can be very useful for analysing problems with understanding one another. Take a look at the diagram:
It’s clear that communication is more than just a message between a sender and a receiver. Context, channel, and code influence the message and can change the reception of the words. Even if two of the factors are in place and one is missing, issues will occur.
Since we are talking about communication in software development in specific, we should analyse what would happen during the project refinement sessions if we were to miss any of the factors mentioned above. In other words, let’s take a closer look at the importance of communication in project management.
Always provide context
Context provides an explanation of the bigger picture around any issue. One may not see the point of telling a backend developer about the target group of the product. It may seem that the development team only needs to know what is required on their side, and not the business reasons behind it. Nothing could be further from the truth.
Communication in software development is not only about functional requirements. The more context you can provide to the team, the better. The proper introduction to the product concept can be time-consuming and may look like a waste of time and money but, in the long run, it helps to avoid poor technical implementation.
If the team knows what the long term plans for the product are, they can provide more suitable technical solutions. Even if you don’t want to implement promotion codes in the first version of your food delivery mobile app, it’s good to let software programmers know that it is coming in the next version.
To be sure you have provided the full context, ask yourself if you have shared all the information you have. If you catch yourself thinking ‘this is not important for developers, they don’t need to know this, at least ask the team if this information could help them. You might be surprised by which factors others may find crucial.
Use the channel wisely
Channel is a commonly forgotten communication factor in project management. Nowadays, when development teams very often work from different countries, when the backend is in India (now, as many as 85% of American companies outsource most of their operations to India), frontend development in Poland and the Product Owner is in the USA, we all use lots of different tools to communicate.
Choosing the proper channel and using it effectively might be impactful. Conference calls, emails, and chats are great and allow us to be in constant touch. But they also create new ways for the message to be misunderstood.
We can’t pretend that chatting online is the same as having conversations in the same room with the team. What we can do is keep in mind the limitations of remote communication and try to overcome them.
Tips for effective remote communication
- Switch on the camera while having a conversation via conference calls. Depending on the situation, non-verbal communication can account for more than 50% of the message. It is much easier to catch if you’re being sarcastic when others can see you, for example. You can also see the real-time reactions of your interlocutors. You are able to notice if the others are confused with your words or not.
- Use separated rooms on chat to categorise the conversations. When the project is complex, communication in software development tends to get complex as well and new topics for discussions appear constantly. Separated rooms allow you to keep the messages organised and reach the proper recipients with less hassle.
- Tag the recipients of the messages while writing via chat. It’s not easy to follow each conversation. It is in your best interest to be sure the person you are writing to is notified.
- In written conversation, use emoticons when suitable. Don’t use too many but let the audience know that you are joking about Friday’s afternoon deployment 😉
Communication code review
At the very beginning of work, you need to establish a common code to understand the main terms in the same way. Even the ‘obvious’ ones. For instance, we have a requirement: ‘As a user, I can make an order only in the morning so that the chosen product could be sent the same day’. Looks clear, doesn’t it?
Well… So what exactly does morning mean in this feature? When does the morning begin? When the sun raises or at an exact hour i.e. 7.00 AM? If at 7.00 AM what timezone do you have in mind?
Communication in project management, especially in IT, needs to be crystal clear. There is no place for guessing. In our case, it may cause a situation where products can’t be ordered before 10.00 (when the main developer wakes up so that’s what morning means to him) and the app owner loses money from the lack of orders from early birds.
Best practices of common communication code
- Create a glossary with commonly used terms. It helps at the beginning of the project and it’s extremely useful for new joiners to understand the language the development team is speaking.
- It’s also good to ask the receiver how they understand the requirement or the phrase. And I am not talking about the useless: ‘Is everything clear?’. Be specific. Ask about the details. Be sure you are understood. Do a communication code review.
Let’s look at our example once more: to reach a common understanding of the term “morning”, ask that person who used it to rephrase it. - The rule of thumb is that it’s better to be repetitive in communication in software development than to leave room for guessing games.
The expertise issue
In addition to all the methods of communication in project management mentioned above, there is one more crucial thing that’s good to keep in mind while discussing software requirements. No matter if it’s a startup or a corporate product, in most cases, before a client goes to the software house, they spend a fair amount of time thinking about their product. The more time spend on it, the more experienced they become on the topic.
When you are an expert, it’s easy to forget that not everyone around you has the same domain knowledge as you have. This means that the issues that are obvious to you are not so clear for the development team you are talking to.
How to avoid the expertise issue
- Take a step back to the beginning of your journey with the product and explain to the development team all the decisions you have made. When they understand how it all started, they will find better technical solutions or even fill gaps in your way of thinking.
- Allow the team to ask as many questions as they need. There is no exaggeration in the proverb that there are no stupid questions.
How to effectively communicate in software engineering team
As clearly as possible! There is no place for miscommunication as the consequences can be painful. Remember that there is no objective obviousness and it’s better to repeat yourself several times than to miss an important piece of information.
Keep in mind all three factors of communications and double-check to see if your message was understood as you intended it. With time, communication in software development will be easier for you, and explaining the requirements properly won’t be a problem anymore.
If you’re looking for a software house that is an expert in both app development AND communication – look no further!
Just talk to our Miquido specialists and bring your ideas to life!
Top AI innovations delivered monthly!
The administrator of your personal data is Miquido sp. z o.o. sp.k., with its ... registered office in Kraków at Zabłocie 43A, 30 - 701. We process the provided information in order to send you a newsletter. The basis for processing of your data is your consent and Miquido’s legitimate interest. You may withdraw your consent at any time by contacting us at marketing@miquido.com. You have the right to object, the right to access your data, the right to request rectification, deletion or restriction of data processing. For detailed information on the processing of your personal data, please see Privacy Policy.
