Over the course of my career I’ve attempted and failed at defining “quality” in a meaningful and/or actionable way many times. It all too often resulted in a over prescribed set of metric targets or a very fuzzy “you’ll know it when you see it”. This was largely due to the fact that I, and those I was collaborating with, were approaching it from a very constrained perspective: That of a tester. Let me be clear, this is a very valid perspective, but it is incomplete.
As I evolved as a software professional, so did my view of quality. Part of this evolution led me to ask the question – “Why is quality important? Why should I care?”. Again, this was easy enough to answer from my perspective, but it was still incomplete. But I was on the right track.
Quality is funny thing, it’s something that everyone “knows”, but it is rarely something that people can describe in any helpful way. Why is this even important you ask? Simply put, if you get it wrong, you lose customers, your reputation is tarnished, your company goes bankrupt, or even worse, your company dies a slow and miserable death because there’s just something wrong, but nobody really can put a finger on it. Avoiding that requires a common understanding. Something that everyone can understand and take action on.
Fast forward a few years and I found myself pondering the question more deeply. I started approaching the question from a different perspective, namely: “What does good quality result in?”. I hate to be obvious about it but… good quality results in happy customers, engaged and happy employees, and a fiscally successful company (i.e. profitable).
This led me to a fairly simplistic working definition of quality – “Quality is doing the right things right”. What does that even mean, and how the heck is that actionable?!?
My experience working with several organizations, as well as most of the literature on the topic, generally focus on the latter part when they discuss quality. This is something most are familiar with and has been the source of endless methodologies such as CMMi, ISO 9000, Six Sigma, etc… All of these focus primarily on the internal processes related to making sure things are done correctly. The problem with that is they are only one part of the equation, and arguably the less important part. What’s missing all to often is the ability to choose the right thing to build – products or services that customers actually want.
As we love to use analogies rooted in other industries in software, here’s mine: You can build the most reliable car with square wheels, but nobody is going to want it (unless of course Tesla develops it :-)). That is a bit of an extreme example, but less obvious versions of that are at the root of countless failures.
Earlier I mentioned that building the right thing might arguably be more important than doing it right. I want to be clear here, both are critical to sustained quality and thus sustained success. It is not an either/or, but if you need to start somewhere, you start with the “what”.
Some organizations fail at this from the start. You rarely hear about them, but many start to encounter these issues later on, as they grow. I’ll dive into that in another episode/post.
So in the end, quality is quite simple to understand. It is doing the right things right. Getting there can be hard though and each organization will have a different path. Next in the series is [[The Quality Triad]].
Leave a Reply