Culture of Quality

I think that the biggest single thing that stands in the way of the so-called culture of quality having the impact that it desires is the fact that all-to-often the words are simply lip service.  It's far to easy to say to people that it's really important to have the highest possible levels of quality and yet it's not easy at all to actually back up that commitment.

I think that one of the largest things that have you end up in a place where you say one thing about quality and actually do another is the fact that saying you have a culture of quality is not quite the same thing as trying to make one happen.  I've been in countless releases where the QA time budget gets chopped due to timeline commitments and invariably you end up having a risk/benefit conversations.

A risk/benefit conversation is that conversation where you go in knowing that there is appreciable risk from moving forward with the release but the benefits, not only of the product to be released but to the relationships that it will feed are more appealing. The big problem with this conversation is that generally the way that the risk is mitigated comes around to a statement like this, 'sure we'll go, and if it goes badly or there's bugs, we'll figure out how to spin that so things are still ok.'

Simply put, that's not quality.  I don't disagree that you always have to do a risk analysis and weigh the pro's and cons of your remaining issues pre-launch.  That's obviously the way to go but when it becomes a battle between QA and pretty much the rest of the world to go live then you obviously haven't fostered a culture of quality.  You may, in fact, have empowered your QA to fight against the rest of the company but that's a hard battle to fight and it really doesn't help.

In order to achieve the culture of quality you have to give every participant in product design and delivery the idea that quality is the first and foremost goal of the organization.  That means that 'good enough' when figuring out your requirements is never the right answer.  I don't mean that you have to have feature upon feature or that each feature has to be the best possible feature that it can be.  Those goals simply aren't practical but the goal that is is complete requirements that truly define what the end product will be.  Going back to the well to figure out these complete definitions needs to be the norm.

Developers who write code and throw it over the wall to QA need to be schooled.  Take pride in your work.  Use test driven development, always build unit tests into your code.  Above all else, when you do your design work, think about the environment that your code will live in, how it will interact with other systems and the performance needs that will be met.

QA needs to consider usability where it may have been missed, analyse requirements properly to get the root needs and communicate clearly.  They also need to stick to their guns when quality isn't been met.

For all of these things to be possible, from the top down there has to be support to the concept that quality comes first.  That when things aren't ready they don't ship.  C'levels have to protect themselves from this possibility simply by having the culture supporting quality throughout the process.   You won't ever come to the hard question of 'should we ship' that's been guarded by an empowered gate keeper if everyone along the path has already spent their time and their empowerment producing the highest quality that they can.  (ok...won't ever might be slightly idealistic)

Culture of Quality...it starts with you, and you, and you.