Friday 18 December 2009

Getting Value from the Quality Department (Part 2)

In this post I want to discuss the problem about Quality terminology and how it is chronically abused in the IT industry and in software development in particular.

Somehow in software development, the term quality is now generally taken to mean testing, and worse still it is often limited to testing after the event. In other words, once the code has been written and integrated, a group of people run a batch of test scripts using an automated tool and look for problems.

Without wanting to belittle the role of the testing team, this is not quality or quality assurance. This is testing, and it is a part of the software development lifecycle just like analysis, design and build phases. Any book on Software Engineering will explain this. Nowhere is it written that quality equals testing. You don't test for quality, you build quality into the system and you build an organisation based on quality principles. Once you move away from those central tenets you may as well pack up and go home. But look through the job adverts on any recruitment page and you will find positions such as Quality Engineer, Quality Assurance Manager, and in ninety percent of cases the associated job description talks about testing; developing test scripts, using testing tools, and more often than not having ISEB qualifications.

At my girlfriend's former place of work they even used to run testing bootcamps for graduates, which turned non-IT graduates into certified testers in four weeks. In my opinion, any organisation that works in such a fashion is certifiable itself.

If you read the ISO 9000 set of standards, which despite its faults, is still a reasonable place to start in a discussion about quality, you'll read about Quality Management which incorporates Planning, Control, Assurance, and Improvement. You really have to dig quite deep into the standards before you get to any serious mention of testing, and by that time you should have worked out that it is one of set of tools available to an organisation, along with reviews, audits, inspections, and other verification and validation methods.

Which brings me onto the subject of audits. I've worked in a number of organisations where the quality team only performs audits. Armed with nothing more than a checklist and set of pre-prepared questions, the person doing the audit goes into the project and runs through the questions, ticking the boxes. I use the phrase 'person doing the audit' advisedly. These are not necessarily trained auditors. Even those that are, often appear to have little understanding of the domain, whether it is project management or even software development.

Often the people assigned to the quality team are those with least experience of anything - it used to be common practice to place graduates and new starts into the quality team to keep them out of the way. Nowadays the quality team simply doesn't exist because it's just been made redundant to save costs.

The point is that audits performed by people without the necessary training, understanding and experience of the problem domain cannot add value to the process. We'll cover this in more depth in a future post but an organisation that relies on this type of audit, to identify problems after the event is unlikely to add any value to the organisation, and by that account, sets itself up to fail. A Quality Manager in this position deserves to be looking for a new role.

At the heart of these issues is the failure of the organisation to really address what it is trying to achieve. If the organisation sets itself objectives it needs to consider how to achieve those objectives, and it's very rare for one activity to work in isolation. Different methods and techniques (and tools where appropriate) need to be considered, and each needs to be evaluated from a value and cost benefit perspective. This is where the Planning element of Quality Management fits it. It's not enough to create a Test Plan or an Audit Schedule. A Quality Plan needs to align to organisational / programme / project objectives and customer requirements and it needs thought and expertise.

My challenge to today's quality teams is to put themselves back in the forefront of organisational operations and be counted as people who make a real difference by adding extraordinary value to the organisation and not restrict themselves to one dimensional entities who only do one thing, and don't even do that very well.



Thursday 17 December 2009

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.