Getting Value from the Quality Department (Part 1)

It's a been a while since my last entry on this blog but I've been doing a lot of thinking in the meantime and I keep coming back to one of my favourite subjects which is the role of the Quality team in a typical software development environment, both in terms of what they think they are supposed to do and what they should actually be doing.

Over the next few entries I want to have a look at the problems I encounter in quality teams and organisations and what to do about them. I'm likely to get a bit sidetracked onto some connected bugbears so I'll beg forgiveness in advance and hope that it doesn't put you off reading!

I was introduced to the organisational concept of "Quality" quite late in my career. None of the first four organisations that I worked for had any documented processes or standards other than the Employee Handbook which was almost all HR oriented. One company took a tentative step towards ISO 9000 back in the mid-1990's, and even went as far as hiring a quality manager. They made him redundant after a few weeks when he told them how much it would cost them to get their ISO certification.

Later, I took on the role of "quality person" in my immediate department, and that's pretty much where everything else in my career started. I introduced a few things like code inspections, facilitated JAD sessions, and coding and documentation standards which were tolerated by the majority of our developers, and appeared to generate some improvements. Bearing in mind that my brief was pretty much "develop and implement some stuff to make us better" I'd like to think that I was quite successful. My only qualification for being given the role was "you're the only one who could actually give a fig".

About this time, we elected to change our development model from 'none' to Objected Oriented Development and Rapid Application Development using DSDM (Dynamic Systems Development Method). We engaged a consultant, Paul Allen who worked for Select Software at that time. As the person responsible for the implementation I worked closely with Paul and he taught me a lot about processes and process improvement. Our pilot project failed dramatically for various reasons, and I left the company before they threw me out, as it was quite clear that my final job title was going to be scapegoat.

I learnt a lot from that experience, but when I started my new job as a process improvement specialist in 1998 for a large global outsourcing company on a major British manufacturing account it quickly became clear that I was now in a different league. Quality wasn't just a buzzword; it was taken SERIOUSLY. Getting SW-CMM Level 2 was a priority objective and goal, along with maintaining ISO9000 certification.

Since then, my own role grew in size, influence and diversity so I got to see things in many different parts of the organisation. I later moved into consultancy and saw things from the outside looking in, rather than purely inwardly focused. And a dozen years later I have rather a different view and a much better understanding of the reality of Quality in the enterprise.

Very few of the quality and process improvement people I used to work with still have jobs with that corporation. Much of the cash spent on improvement initiatives has largely been flushed down the pan and the company has little to show for it. A few groups have been successfully been steered through CMMI L2 and L3 assessments, but regular reorganisations tend to dilute even that achievement - not to mention the loss of tens of thousands of developers and other staff. Quality is a necessary evil that has to be tolerated rather than embraced. It rarely appears on meeting or review agendas any more, and the higher in the organisation you go, the less likely the chance of it being mentioned. I've seen exactly the same happen at other companies, small and large, so this isn't an isolated case.

So where did it all go wrong and how can we get back on track to where we really ought to be after years of investment, research and more failure than success? Over the next few entries I'll look at Quality Perceptions, Management Responsibility, the Audit Process, Quality Metrics, and Quality People, and examine the issues and provide some ideas on resolution.



Print this post