[Repost] Quality Engineering as philosophy, a framework and a tool
How can Quality Engineering foster a culture of quality for healthier socio-technical systems?
I’m currently travelling back from StarEast (write-up coming soon!), so this week I’m resharing a post from November 2023.
I keep coming back to this one because it really helped me shape how I think about quality engineering. It’s not just a set of practices, but something that can shape culture. It’s about how philosophy, frameworks and tools all work together to build quality into people, processes and products.
If you’ve ever found yourself trying to explain what quality engineering actually is or how it connects to real impact, this one might help.
In What do Quality Engineers do? I said Quality Engineering nudges and boosts aspects of the system to make it more conducive to creating a culture of quality:
By applying a Quality Engineering mindset to make the system healthier, we can nudge and boost aspects to produce the quality attributes we want, which can be the seeds that grow into a culture of quality throughout an organisation.
In this post, I would like to delve deeper into how we can cultivate a culture of quality by examining quality engineering from three distinct perspectives - as a philosophy, a framework, and a tool. Which we can use to nudge organisations towards a culture of quality.
As a philosophy
Quality Engineering as a philosophy (a way of thinking) is about creating a culture of quality throughout an organisation. From this perspective, Quality Engineering as a philosophy is focused on building quality into the people. Using approaches such as the organisational mission statement and values and behaviours, to name just two.
You'll also see the most senior leaders constantly modelling behaviours, encouraging the organisation to build quality into the system. Not just pushing their teams to deliver more but focusing on making their customers the best at what they do with the products and services they provide.
Quality Engineering as a philosophy is about infusing how quality is built, maintained and lost into the organisation's way of thinking. Engineering teams don't think about building quality; it's just how they work. For instance, they don't think this product/service needs to have quality attributes x, y and z (outputs). But they are focused on how those product or service features support their stakeholders to achieve a particular goal (outcomes).
As a philosophy, it's not just about engineering but is present in every aspect of the business, from human resources to finance, marketing, sales, and strategy.
As a framework
Quality Engineering as a framework (a way of behaving) is about creating processes that encourage people to build quality into their work. As a framework this can be at many different levels within an organisation and is about creating structures that nudge people towards building quality in.
Approaches such as OKRs (Objectives and Key Results) and agile software delivery methods (Scrum, Kanban, DevOps, Continuous Delivery, etc.) focus on outcomes and helping people improve their work environments. Processes like these encourage teams to learn iteratively about their products and services and how they enable their stakeholders to achieve their outcomes.
When considering Quality Engineering as a framework, it's not about one process fitting all but finding which processes enable teams to make their products better, faster, and cheaper. But most importantly, it allows those teams to deliver sustainably.
When thinking of Quality Engineering as a framework, it's about applying the ideas of how quality is created, maintained and lost to the team's ways of working. It's about helping those teams adapt and iterate their processes and how they encourage them to build quality into the products and services they develop and maintain for the long run.
As a framework, it's about helping teams practically apply Quality Engineering as a philosophy.
As a tool
Quality engineering as a tool is about techniques. These are things people do that create quality in the products their teams build.
For instance, this could be code-level tests that help you understand if the system's behaviour has changed. It could be building telemetry into your products to understand how your users interact with your systems. Or Continuous Integration pipelines that allow you to go from code commit to running in production.
Quality engineering as a tool is all about outputs and putting our thinking and behaviours into action to build and maintain quality in our products and services.
Just skip all the philosophy and frameworks and build quality in via tools
Some may wonder why we should not just skip all the philosophy and frameworks and focus on the tools. While this may work in the short term to improve the quality of your product. It does nothing for the long-term health of the system in which your product exists. This means the environment your product operates within will eventually begin to work against it. At this point, it will not matter how much quality you attempt to build into the products. The environment will mean it is never good enough.
The other issue with just focusing on building quality into the products via tools is that any change to the product can mean the existing quality could be degraded or lost. So you are constantly trying to detect if the quality has been degraded and trying to put it back in. However, by building quality into the processes (via frameworks), the team is continuously improving their capability to do the work, improving product quality. Therefore, it doesn't matter how often the product is changed. Quality remains.
Let's say the team only focuses on frameworks and tools and skips the philosophy stage. You see this when teams stick with a particular framework or process. Remember, the environment in which we work is constantly changing. So, if your processes remain the same, they are not adapting to your new environment. At this point, your process will eventually be the limiting factor in your product quality.
Not only that, if the people who created the process in the team leave all the understanding and learning that occurred to develop that process goes with them. Therefore, new team members will not understand why the team does what they do the way they do it. This problem is most acutely felt when the teams have adopted a custom approach that doesn't make sense to people on first inspection. At this point, most teams revert to whatever default ways of working they know. Therefore, any quality improvement the custom approach created is lost. Resulting in an overall degradation of the product's quality. But worst of all, the learning the original team members acquired is lost with it, and the whole improvement process (if ever) has to start again.
However, building quality into the people via a philosophy approach means that as team members move on, new team members are educated in how quality is built into the process and tools. Not only do they understand why the team does what they do, but a mechanism is in place that allows those new team members to incorporate learning from their past experiences, further improving the processes and tools.
Backing up the tools with the thinking and the behaviours allows teams to begin improving their work environments for the better. It gets them on the path of continuous improvement.
How does this build a Culture of Quality?
Approaching Quality Engineering from the three perspectives of philosophy, framework, and tools allows you to start infusing quality into every aspect of an organisation. From how they think to how they behave to the very work they produce. They are fostering a culture of quality rather than one that looks to tack quality on at the end.
Building quality into organisations this way gives the people who work their autonomy in what they do and how they do it. But with a way for them to assess how well they are doing it and how they can do it repeatedly, consistently, and reliably.
This is not to say this is the only way to create a culture of quality, but it can be a starting point and help you assess which levels are currently covered and which may need more work.
These three perspectives may make it seem that if you follow this neat process of setting the philosophy, creating frameworks and having the right tools in place, you'll produce quality products repeatedly. That is probably not what's going to happen. It's going to be full of missteps, failures and misunderstandings. What these approaches are for is helping you get back on track and keep making progress.
Building quality into products, processes, and people is about more than creating the ideal system that is bug-free and has perfect quality; it is about creating a system that is better than before and continuously improving. Remember, the environment in which your system operates is constantly moving, so you should be, too.
By building quality via a philosophy, a framework and tools, you begin to nudge the socio-technical system at the levels of thinking, behaving and acting. This results in each level boosting the other, fostering a culture of quality throughout an organisation.
All of this leads me to the question: Who is responsible for making this happen? Which I’ll cover in the next post.
This is a free post 🔓 so if you find it helpful, feel free to forward it on as others may do too, and if you’re not already a subscriber, then sign up so you can stay up-to-date with the latest Quality Engineering posts.
Great point! If your organisation seeing quality as a gate, something that needs to be overcome, a problem then you’ve got bigger issues to solve.
How have others approached this?
If a business recognises >>Quality<< as a conciseness of the organisation such approach as presented above has a right and opportunity to emerge. However, a business with a thinking like >>Quality = Police<< won't change and won't implement such culture, not mentioning Q 4.0