Why Nothing Is Ever Obvious: The Art of Communication In Software Development
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 we all make mistakes 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 from the second group 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 obvious for one person, may not be clear 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.
What communication consists of
More than 50 years ago Roman Jakobson presented a communication model that can be very useful while analysing problems with understanding one another. Take a look at the diagram:
It’s clear that communication is more than just a message between sender and 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 missed any of the mentioned factors. In other words, let’s take a closer look at the importance of communication in project management.
Context is for kings
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 should know what needs to be done 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 the 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’s worthwhile and helps to avoid an unsuitable 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 facts are crucial.
Use the channel wisely
Channel is a commonly forgotten factor in communication in project management. Nowadays, when development teams are very often working from different countries, when the backend is in India, frontend 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 to become misunderstood. We can’t pretend it’s the same as conversations while we are in the same room with the team. What we can do is to keep in mind the limitations of remote communication and try to overcome them.
- While having a conversation via conference calls, switch on the camera. Depending on the situation, non-verbal communication can account for more than 50% of the message. When you are being sarcastic, it is much easier to catch it when others can see you. You can also see the reactions of your interlocutors. You are able to notice if the others are confused with your words.
- Use separated rooms on chat to categorise the conversations. When the project is complex, communication in software development is complex as well and new topics for discussions appear constantly. Separated rooms allow you to keep the messages organised and reach the proper addressee.
- Tag the recipients of the messages while writing on 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 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 requirement gathering 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 he or she understands 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 factors mentioned above and methods of communication in project management, 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, he or she spends a fair amount of time thinking about his product. The more time he spends, the more expert he becomes in the field.
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 which are obvious for you are not so clear for the development team you are talking to.
How to avoid it
- 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, they will find better technical solutions or even find 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 communicate in software development
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 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.