Why business and IT don’t understand each other
Let’s say you’re a product owner with a great idea. You explain it to your development team so they can build it and your end result is completely different — Sound familiar? When it comes to communicating your vision for software it can feel like describing a tire swing and getting a completely unfunctional plank swing instead, sort of like this graphic depicts.
It’s nothing new. In fact, this tree swing cartoon first appeared in 1973 depicting the communication pitfalls in product development. Apparently, not much has changed…
Even in this day and age of advanced technology and real-time communication, software development teams still build things that don’t meet the client’s expectations — but why?
That’s the topic and question this article will address.
We can’t hear 75% of what the other is saying
The product owner has an idea about something that needs to be built. He tries to find the words to describe it. He says them out loud so the team can hear them. Unfortunately, the team typically won’t hear (at least) half of the words he’s actually saying. Instead, they will try to make sense of the words they do manage to grasp. and simply imagine what it is the product owner was talking about.
Graphically, our communications go something like this:
Lost in translation
In this depiction (which is based on a model first created by Shannon and Weaver in 1948), it’s clear that something important is lost between the original speaker and the receiver. People have a tendency to misunderstand each other, it’s just how we’re wired. It’s not a new problem, and it probably won’t change any time soon.
The Shannon Weaver model illustrates the communication process from a technical perspective, but it later came to represent the psychological aspect of communication as well.
We forget things
To make matters worse, humans can only store seven things in their short term memory. According to a study published by George Miller in 1956, the human mind saves bits and pieces of information in a particular way. For example, try to memorize the following numbers: 07201969. Notice those are more than seven digits. Memorizing every individual digit is pretty hard. It’s easier to break it down into smaller units: 07, 20, and 1969. And it’s even easier to break it down into one chunk: 07/20/1969, the day Apollo 11 landed on the moon.
Do you still think you can build what they wanted?
Domain experts don’t usually know how to code. Software developers do. But they have less knowledge of the domain. Those who have that domain knowledge ask for new features in the software. They usually share that knowledge through requirement documents or refinement sessions. But it’s pretty safe to assume the development team will misunderstand and forget parts of that request.
“It is not the domain expert’s knowledge that goes into production, it is the developer’s assumption of that knowledge that goes into production.” — Alberto Brandolini
We are visual learners
Multi-disciplinary DevOps teams that deliver value-increments at a high pace need more than just software development and operations skills. They need requirement engineering and testing skills, too. Why? Because managing expectations and getting done what needs doing, without breaking things, is difficult without both!
Reading a requirement document or listening to a monolog in a refinement session is like trying to remember those eight digits. It’s hard. Visual information is much easier for us to process and remember.
When you visualize first, you get a common understanding of the software requirements. A picture says more than a thousand words.
Fast feedback is essential
Misunderstanding each other and forgetting things is in our nature. That’s why we need feedback. Without feedback about how the other person understood the message, we can’t clarify whatever wasn’t clear.
Putting post-its on brown paper or doodling drawings on a whiteboard is not a silver bullet., but it does create a common understanding of a problem and a solution. At some point, we actually need to build things. Ultimately, there’s no clearer feedback to the business than seeing something on a screen that works.
Keep your stakeholders involved all the time. Demonstrating new, working versions of the software’s specific features in every sprint review is a great way to do this. Discussing the specifications for the new software with stakeholders directly is another way.
Don’t be afraid to demo something that’s not done, or not good enough by your standards. The sooner you know if you’re heading in the wrong direction, the better.
“Fail fast, fail often and fail in a way that does not hurt”
Summary
Communicating is more difficult than we imagine and written communication is often the worst way to express our ideas.
We’re unable to hear everything the other person is trying to say and can’t remember it either. Transferring domain knowledge through pictures while having a conversation about it, is fun and effective. Use tools and processes like Event Storming and Example Mapping to visualize what you’re talking about.
Posting stickies on a wall will not magically solve every problem. Communicate about the software that’s being built all the time. Involve the stakeholders in the development process as early as possible. Show them working software every week to see if you’re in the right direction.
