Mike Cohn recently asked the following question:
Is quality best thought of as “conformance to requirements?” Or “fitness for use?” Or perhaps something else entirely? -Mike Cohn
This subject is important because all too often the industry of software development thinks quality comes from the software itself. That would be the camp of people that think conformance to requirements is an indication of quality. But software is just a means to an end. That’s what Mike is asking about. How best do we define that end? And then can we define quality in terms of it?
How I define quality
The definition of quality makes this conversation potentially ambiguous… “the standard of something as measured against other things of a similar kind; the degree of excellence of something.”
My standard for business is that my customers are successful. If they aren’t successful, I won’t be successful. Also, if I’m not successful, I won’t be around to help them be successful. When we are successful together, we can amplify our abilities to produce value for others.
With that standard in mind, quality to me then is measuring our success. High quality or having the attribution of quality is directly related to that success.
Success is about producing value. Both tangible value and intangible value. And producing value in such a way that the cost to my customer and to myself does not exceed the value we each receive. The only sustainable model of business is a win-win situation. A lose-win or a win-lose situation won’t work in the long run.
In so far as success is my standard, then quality is simply a matter of ensuring investments can and do produce a significant return. And the return should be greater than other possible investments that could be made. In other words, avoiding marginal investments in favor of highly successful investments.
From that I would conclude that quality is producing software, or anything for that matter, that leads to a substantial return on investment.
Value is subjective though, I can’t specify value for a customer but I can help them explore and diagnose value. It’s my job to make sure that we have substantial room for success from the get go. The requirements are derived to achieve the desired value. Requirements can be adapted as we learn.
Maybe I’m splitting hairs but even the “use” of the system will be constrained and altered to create the desired outcome and value. Use is a step in the right direction. Requirements are not guaranteed to be useful. But use isn’t enough to imply valuable. People use things all the time that don’t produce any value for themselves, let alone anyone else.
In fact, many times organizations think something is valuable and it’s not. That’s why value shouldn’t be taken for granted. For example, many organizations use timesheets. Software that tracks timesheets can be created and used but it won’t necessarily produce any value for the organization.
Circling back to “quality is fitness for use.” I would make the alteration: “quality is valuable use.” I’d drop fitness to avoid implying it’s fit for use but not actually used.