Communication isn’t usually associated with coding geeks, pardon… software engineers. Some people may think of developers as shy nerds alone in their basement who prefer the company of their computers over that of other human beings. I’ve not met many of that kind.
In reality, communication in software development is omnipresent and I claim that almost 100% of software development is related to communication.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. Melvin Conway – Conway’s law
In Software development, communication happens literally everywhere, between customers and users on their needs, and in the project team between product owners, designers, architects, developers, and testers about technical solutions. And finally when our development teams give computers instructions to solve the problem and "code" our product.
It is not about whether or not we communicate – it’s about how and what we communicate. In this article, we will explore some of the communication challenges that can occur during the software development process, and offer some suggestions on how to overcome them.
The Vision, aka North Star
Development of software means the process to implement a solution for some sort of capability gap that ideally is described in form of requirements. Requirements can come from a variety of sources, have different intentions, and be relevant to different stakeholders. They are one of the strongest drivers of a project’s direction, so it is important to be clear about them and have a frame for them.
It all starts here – we need to have a vision in order to achieve common understanding. Some call it "North Star" and it will help to provide us with guidelines, boundaries, and an overall goal to strive for. The vision also plays an important role to align the project team. Anything that is not part of the vision should be rejected as invalid. In the past, this by the way has been an effective way to shut down any discussion about unsuitable requirements. The vision will give us the "Why" and as a result it will provide information about our target audience and their objectives, which will help us to establish a starting point and direction.
Ok, so you have a vision for your product, great! Let’s look into some of the traps you may step into.
Team Size & Direct Connections
Direct communication in a project team has a cost, which partially can be described with the number of connections needed for direct peer-2-peer communication: connections = teamMembers * (teamMembers-1) / 2
.
The more people are added to a team, the obviously higher the number of direct connections and with them the overhead gets:
- 3 people – 3 direct connections
- 5 people – 10 direct connections
- 10 people – 45 direct connections
- 15 people – 105 direct connections
Of course, we try to compensate for this challenge with daily scrums, weekly demos, playbacks, retro-perspectives and other formats to transform a peer-2-peer communication into a more one-2-many flavour, however the need for direct communication will never fully go away.
Fred Brooks described the logical consequence of this fact already in 1975:
Adding manpower to a late software project makes it later. Brook’s law by Fred Brooks
In the real world, I prefer to work with a maximum of 5 people in a single squad and a feature or capability should be given to that squad that is challenging but still achievable and can be fully owned by the squad. Many software projects require a much larger workforce; the pattern, however, should remain the same: divide and conquer – break a larger offering into pieces that can be assigned and owned by much smaller squads, herewith scope-efficient communication within the squads and create another level of cross-squad communication that is limited to feature-overarching topics related to areas that need standardization and governance— more details can be found here:
Loss of information
We had a fun test years ago at the university called "Ways of a Message". One person told another a ten point story in isolation, which was then passed on and so on. The result was pretty amazing after the whole group had gone through it: Roughly three points survived as they were, seven got lost completely and a few more were creatively added. The loss of information was blatantly obvious. When we think about communication, we need to factor losses in, so we better validate what was received or repeat what we understood.
Perspective constraints
Different people have different perspectives, usually leading to different conclusions, opinions, and priorities – and none of these should be considered as the whole story. The larger the user audience, the more the constraints in these perspectives should be considered. You may see a group of potentially very vocal users screaming about the search behaviour in your app, business stakeholder making a big deal out of an in-app dashboard, and program management maybe paying the most attention to instrumentation improvements. It may be the Program or Portfolio Owner and/or the Lead Architect who hopefully is able to see the full picture. Prioritization now becomes a balancing act between several forces, and the only generalizable recommendation I have here is to determine what is really needed to maximize business outcomes, not what is desired by a specific stakeholder group. Communication obviously is critical in this context and questions to ask may run along the lines of:
- What do the users & stakeholders need to achieve?
- How do they currently achieve it?
- What is it that makes it difficult or even impossible to achieve today?
User research is key in this context, however I would not recommend to carry out research **** for solutions – instead, research problems.
Silent information & information hiding
Whether we identify the reason for silent information as just being ineffective, rather than a lack of communication or even conscious information hiding, the key consequence is similar – a risk resulting from information not being shared among team members, sometimes referred to as Bus factor.
If you realize that someone on your team is both key and irreplaceable, it’s time to manage the situation, to urge and facilitate communication, documentation, and knowledge transfer. From my experience, the most effective way to prevent information hiding is to have an open and respectful work culture where all team members are appreciated for their contributions, feedback flows constantly and micro-tracking does not exist. Once the benefit of sharing as opposed to hiding become very obvious, open and effective communication usually follows naturally.
Expectations
From the perspective of the project team, expectations are constantly being raised by multiple stakeholders, which obviously need to be understood. In my experience, the "What" usually demands the highest level of attention, but the "Why" and therefore the purpose are much more important in reaching a common understanding and agreement and all of this has to fit to our vision.
On the flip side, stakeholder expectations can and have to be managed in a Software Development project in order to avoid unrealistic expectations that inevitably lead to dissatisfaction. The amount of knowledge at the beginning usually creates a much higher level of uncertainty around the length of time required to complete a project. This uncertainty introduces risk and a trade-off between scope and time, which all parties should be made aware of from the outset. What would effective communication for expectation management look like, you may ask?
The key here is transparency about unknowns, clear commitments on the knowns, sizings created by the delivery teams, solid delivery on the commitments, flexibility on course-correction, and many small but steady steps into the desired direction that demonstrate continuous improvement and herewith create trust. Personally, I’ve never been a big fan of project plans that tried to lock scope into time – my mindset was never compatible to Waterfall. A plan imho is just needed to select the rough pathway on a map, the details can be worked out as we go. However, it won’t hurt to have some buffer in your plan 😜 .
Summary
We have learned that communication is a pervasive and critical factor in any software development project. It was explained why a vision is foundational to orientate and frame requirements and we have seen that team size, loss of information, perspective constraints, silent information, and expectations are potential challenges in a software development project that can be overcome with efficient and effective communication.
Further Reading
Communication in distributed software development – Wikipedia
The most important skill of a software developer is communication
About Thomas Reinecke – in my roles as Chief Architect on several key IBM-internal transformation projects executed during the last years, I’ve had unique opportunities to co-lead and influence some of the most complex, comprehensive and impactful activities inside IBM, with transformation of Support, Sales and the Business Partner Ecosystem being mentioned as examples. I have always been a very curious and reflective person, and so I have been trying to understand the impact of communication on software development since years, and obviously I’ve practiced it 😁 . I’m still an IT engineer at heart, so I’m mostly interested in the practical side of things and I share my own real-world experiences here on medium.
If you liked this story and want to read thousands of stories like this on medium, you can become a medium member for as little as 5$/Month. If you’d like to support my writing, use my referral link below, I will get a portion of your membership without any extra cost to you.