Huib Schoots and Joost Voskuil, had the idea to bring together people with an interest in Quality and ask them questions like “How can you sell Quality?” and “What limitations or barriers do you hit?”. On January 30th, 2021 the first (of many?) Quality Acceleration Peer Conference took place and I was lucky enough to participate along with a great group of people.
There were many interesting discussions. What specifically stuck in my head is that it is easier to have conversations about specific “quality values” rather than about something as abstract as Quality. So, I rephrased one of the questions to “How can you sell quality values?” and reflected on it for a while. The outcome is that I think there are (at least) two groups of people in software that are trying to “sell” their quality values to one another.
Development quality values
Many, if not most, development teams want to do good work. They want to deliver valuable code, so they ask for time to think things through and refactor when needed. Development teams also want to have the time to instrument their code properly for better insights when it is deployed to production. And they want to test their code to feel more confident that what is being built is functional, secure and performant. These are the quality values they try to push forward because they consider them necessary conditions to produce good software.
Product quality values
Product teams are equally interested in delivering a quality product to their customers. They know the market and are aware at what pace new functionality needs to be released to stay competitive. They are interested in keeping their product’s market share so they want the product to uphold to certain standards to maintain their certification. Budget might also play a role in what would make a feature “good enough” to do its job. All of these are parameters that affect the success of a product and they need to be in place to enable said success.
Balanced quality values
Successful software products have managed to find a balance by having both Development and Product be aware of the entire set of important quality values and everyone is aligned to uphold them. Nobody needs to “sell” their quality values to the other. But, my assumption based on my experiences is that in many organizations Product “wins” over Development. Even if there is no direct management connection between the two, Product quality values might be imposed on Development while Development has to convince Product to get their quality values through.
Now why this is still the case, is a bit of a mystery to me. One of the biggest findings of the research published in Accelerate is that development quality values lead to more performant products. So how come development teams still need to argue for buy-in for refactoring or testing? There are probably good reasons that might be based on bad experiences or just some false beliefs but I think that it is something interesting to look into. Maybe in the next instalment of the conference.
More Questions Than Answers 
2 thoughts on “Balancing the Quality Scale”