Many of my episode talk about an experimental mindset - have a hypnosis, try something, act on the feedback. The timeliness and quality of the feedback has real impact on our outcomes. And I illustrate this in this episode through the act of providing our customer the perfect bath.
Or listen at:
Published: Wed, 26 Jan 2022 17:21:45 GMT
Transcript
Hello, and welcome back to the Better ROI from Software Development podcast.
In many of my episodes, I talk about that quick experimental mindset, that minimum viable product of having a hypothesis, testing it and acting on the feedback.
In this episode, I wanted to focus a little more on that feedback and why it's so important to shorten the feedback cycle as much as possible.
The dictionary defines feedback as:
"information about reactions to a product, a person's performance of a task, etc. which is used as a basis for improvement."
In short, the better the quality and the timeliness of that feedback, the better and in the improvement.
And to demonstrate this, I'm going to talk about running a bath.
Your customer comes to you and ask you to run them a bath. You say "no problem" and you start the process. Now, you know what sort of bath you like - how deep the water is and what temperature. So you put this into a requirements document.
You pass that into your project management office with instructions of how this is super important.
A couple of weeks later, the development team run the bath based on your requirements.
Eventually, the customer gets - it only to find the bath is empty. No one put in the requirements that there was a need to put a plug in the bath.
Now, let's compare that to the customer working directly with the developers.
The customer asks the bath to be run.
The developers turn on the taps.
The customer immediately points out the water going down the plug hole.
The development team add the plug.
The customer provides constant feedback on the water temperature and depth.
The development team adjusts the flow of hot and cold water based on that feedback.
Within minutes, the customer is ready to enjoy the perfect bath.
The difference here is striking; In the first example, the customer is disappointed, and a lot of time and effort has been wasted. In the second example. The customer has been delighted and it's been considerably cheaper and quicker to provide.
Let's look at a third example; We add a project manager.
The customer communicates with the project manager.
The project manager then runs down the stairs to the development team. They deliver the feedback.
The development team adjust the flow of the hot and the cold based on that feedback.
The project manager runs back up the stairs to check for more feedback.
Due to that delay, the customer will experience feedback oscillation. If the water is too hot, then feedback is passed on and the cold is added. But due to the delay, once it reaches a customer's correct temperature, more cold will continue to flow in making the bath too cold. The feedback, then, will be to add more hot - and this feedback oscillation will continue potentially forever. Or more likely until the water overflows the bath.
So the moral of this story, the shorter the feedback cycle, the better the outcomes.
Traditionally, we haven't wanted the development team talking directly to the customer. We have seen that as a waste of an expensive resource. Rather, we prefer to get everything ironclad into requirement documents, or control the conversation via intermediary.
We focussed on the wrong thing. We focussed on the development team's utilisation.
Modern software development teaches us that focus on utilities is at the detriment of outcome. We should be focussed on the outcomes. And for that, we need to keep our feedback loops as short as possible.
Thank you for taking the time to listen to this podcast. I look forward to speaking to you again next week.