In my previous post, I spoke about The Forgotten First Principle of Software Delivery: Quality. I promised to explain more about how to measure and define Quality, but to do so, we need to also consider Value, because there is an intrinsic relationship between Quality, Value and… Love! Allow me to explain.
Quality Is Like Love
When you love someone or something, you invest your time and energy to express that love. You care about their wellbeing and their condition. When applied throughout a child’s life, the love manifests itself in the child being balanced and secure. For a car to be admired as a “classic” 70 years after it leaves the factory, it needs to have had love applied throughout its life, from the designer to the owner.
Quality is exactly the same. When due care and attention is applied throughout, the quality of the resulting outcomes can be both measured in tangible ways, and felt in emotional ways.
High quality comes from care and attention.
Applying Quality To Value
Let’s look at how this works in product development. Consider the following coarse-grained stages of value creation:
Value creation always begins as an idea that you realize through an iterative series of steps. At every single stage in this process, you are assuming that your idea and its implementation are valuable. This is assumed value. When a consumer receives value from your realized idea, then and only then, is your idea truly valuable. This is when assumed value becomes real value.
Quality Functions
The way in which assumed value is transformed into real value is through quality functions. I briefly introduced the idea of quality functions in my previous post and said that “quality functions are the methods and practices that are essential for the continued delivery of value.” Perhaps a simpler way of thinking about them is that:
Quality Functions are acts of love, care and attention that you apply throughout a product’s life.
They are the means by which you adapt the idea and its implementation to increase quality.
Putting Quality Functions Into Practice
I like to use extreme examples when trying to prove a concept or theory. Consider these two extremes:
Extreme 1:
- Idea
You get the idea when you’re drunk. - Research & Refine
You check with your mum that the idea is good and she says, “yes dear”. - Specify
You write the idea on the back of a napkin and spill tea on it, rendering it unreadable. - Build & Test
You write the code to realize it without running the code at all, and your test is a simple check that there were no compilation errors. - Deploy
You copy the code manually to the server in your closet. - Monitor
You ensure the server power is on as you enter and leave the house
Will the assumed value be transformed into real value? Will the real value be of high quality? Extremely unlikely!
Extreme 2:
- Idea
You have been training yourself to have better ideas regarding a specific problem you want to solve. You go over it in your head and try to prove yourself wrong to make sure the idea makes sense. You trash the first set of ideas and think of a few more until you have an idea you’re happy with. You socialize the idea with people outside of your circles to see if they think it’s valuable and you rinse and repeat this process. - Research & Refine
You iterate on this process a few times. You apply design thinking and modify the idea based on the feedback you get. You research the market and the opportunity and figure out how you will reach customers. You go back and modify the idea according to your findings. You iterate on this and go back to step 1 a few times until you finally have empirical proof that shows your idea is in demand and ready to be realized. - Specify
You use a combination of UX wireframes and BDD style stories to define the idea with the team that is going to build and test it. You sit with the team and work with them throughout the development stage. You change the original idea some more based on the feedback from the team. - Build & Test
The team writes clean code that respects the separation of concerns principle, amongst other engineering best practices. They practice pair & mob programming and embrace a testing culture. They use an automated testing approach and are dedicated to creating tight feedback loops that allows them to iterate quickly. - Deploy
The team creates automated deployment to clustered cloud servers that autoscale on-demand, and you ensure you can trust the deployment through smoke tests. You use services like LaunchDarkly to diligently roll out your assumed value. If any of the deployments fail, the code or the automation is changed until the deployment is successful and the smoke tests pass. - Monitor
You regularly monitor the health of the app and receive automated notifications. You also monitor the usability metrics, customer feedback and web/app usage metrics. When you see the usage dropping you go back to step 1 and repeat the entire process to ensure your customers are receiving real value.
Will the assumed value be transformed into real value? Will the real value be of high quality?
I know which extreme I would put my money on!
When the end result is of high quality, it is because quality functions were applied throughout every single stage of delivery. The quality functions are the mechanism that transforms the assumed value into real value. This implies that:
Value cannot exist without Quality
And I mentioned above, quality cannot exist by itself, so the inverse is also true:
Quality cannot exist without Value
In other words, Quality and Value have a Yin-Yang relationship.
Q()
Now as a programmer by trade, I like to think of quality functions as I see them in code, which looks like this:
Q() {
researchAndRefine()
specify()
buildAndTest()
deploy()
monitor()
}
The above simply says that Q() is all of the quality functions that you apply in your delivery process.
And since quality functions are what transforms assumed value into real value, we can pass the assumed value into the quality functions:
Vr = Q(Va)
In other words, real value is the product of all the quality functions applied to assumed value.
Quality Belongs Everywhere, and to Everyone
When you look at quality like this, doesn’t it seem completely absurd that in most companies, the “job” of quality is given to one person or department, right at the end of a process?
Have a look at Parasoft’s research where they asked 780 IT professionals to answer a series of questions about their team's development process. When they asked the different teams “who owns quality?”, these were the results:
You can clearly see that the responsibility of quality falls on the testing team in all of the development methodologies, and the testing team typically operates at the tail end of the process. The truth is, most of the opportunities to influence the quality of the assumed value have already passed by then.
There are hundreds, even thousands of quality functions that can be applied to the product development process. Every single person that touches the assumed value is responsible for applying quality functions to it.
This is why, quality needs to be a holistic concern across the whole lifecycle, and this is why I think we need a whole new category of product that unites quality functions to really make a dent in the software quality problem.
Join our mission
I promise you, we’re working on this problem. It has been haunting me my entire career and it’s time to do something about it.
If this theme and my comments resonate with you, please let me know by clicking that heart icon and recommending the article to expand the reach of this message.
And if, like me, you feel passionately about the need for prioritizing quality in software development, please connect with me by following me here on Twitter and at the Xolv.io site and blog where I will update you on our progress.
You can also help me by telling me your story, your opinions, or any other resources you think are pertinent to this cause. How does your team transform assumed value into real value? What quality functions do you apply? I cherish any and all feedback in the comments below.
I look forward to helping you deliver higher quality software, faster.
Sam.
Let me know if you have any questions or thoughts in the comments below.
