8 Quality Principles that everyone should adhere to

At various times in my career to date I've held the role of Quality Manager or Quality Leader either at project, programme or organisational levels. Over the years I've developed a set of eight simple Quality Principles that are easy to understand and more importantly, easy to achieve by everyone in the organisation. In fact these aren't so much Quality Principles as common sense principles which often fly out of the window in times of stress. However, if you follow these principles, and communicate them across the team, department or enterprise you may find that some of the things that cause the problems in the first place will start to disappear. Print them out and post them on your noticeboards, issue all members of staff with a laminated copy to keep on their desks. And make sure that you follow up on them by ensuring that at the very least you yourself adhere to them whatever pressure you find yourself under.

Quality is a collective responsibility

• Everyone must be actively involved
• Your actions and what you produce reflects on all of us

Honour your commitments

• Create a realistic estimate prior to making the commitment and document your assumptions
• Don’t commit to something you know you can’t achieve
• Provide an early warning if you cannot fulfil a commitment you made

Right first time, every time

• If you don’t have time to do it right initially, when will you have time to fix it ?
• Perfection is not a contractual requirement

A second opinion is not optional

• All contractually required deliverables that you create must be reviewed by a person other than yourself
• Allow time for review and rework in your estimates

If in doubt…ask

• No question is stupid if it helps you to do your job, as well as helping others…
• …but use your common sense

If you see something wrong (or know of something better) …tell someone

• All processes can be improved
• We can’t fix things we don’t know about

Plan your meetings

• Make sure you have a clear purpose, a published agenda and the right participants
• Record critical decisions and actions in meeting minutes

Keep It Simple, Stupid (KISS)

• Life is complicated enough – don’t make it any more so

The SPI Manifesto - What's It All About ?

It's election time in the UK, and this week the major parties have all released their manifestos outlining their policies and plans for the next five years should they be elected into government. Earlier this year the SPI Manifesto was published; the work of a group of people who attended a workshop in late 2009 in conjunction with the EuroSPI Conference in Spain. The publication of the manifesto appears to have polarised the SPI community into staunch supporters and those who are rather more sceptical about it. For myself, the manifesto certainly raises more questions than it answers, and in this entry I'll try to explain why. However this is not going to be an in depth analysis of the manifesto - although that may come later!

The Facts The SPI Manifesto is a 17 page pamphlet which is structured as three values and ten supporting principles. The three values are concerned with People, Business and Change, and each consists of a context and problem statement, a section explaining the value and a number of "hints and examples". The values are statements of what the authors truly believe. Four principles support the People value, three support the Business value and a further three support the Change value, and are explained as principles that the authors trust to support the values. Each principle consists of an explanation and an example. The front page summarises the values and principles, followed by an explanation of how the manifesto came into existence and what to use it for, and the final page is given over to the presenters, authors and reviewers.

Manifesto or Manifest ?

The dictionary definition of a manifesto is

"a public declaration of policy and aims, especially one issued before an election by a political party or candidate" 

The word originates from the 1644 Italian word "manifesto" which means a public declaration explaining past actions and announcing the motive for forthcoming ones". My first issue is trying to figure out what this document actually is. It is titled the "SPI Manifesto", but in the description of what it is, it suddenly becomes a manifest which, when used as a noun, is defined as a customs document listing the contents put on a plane or ship. Clearly this isn't one of those! Semantics aside, this is the first of numerous inconsistencies which percolate through the document.

Three Unanswered Questions Despite having read through the document several times and having been in discussions with various knowledgeable colleagues I cannot find the answers to three fundamental questions. Quite simply these are:

• What is the real purpose of the SPI Manifesto ?
• Who are the intended audiences ?
• Why was it thought necessary to create such a manifesto in the first place ?

A basic principle of process improvement teach us that we undertake a change or improvement activity in order to fill a requirement or to meet a need. A second basic principle is to identify the stakeholders impacted by the change or improvement. However, the SPI Manifesto, at no point that I can see, addresses either of these principles. And without these critical issues being addressed, the manifesto is left in a state of limbo. In a real life business environment, such a document would never see the light of day without having a requirement to meet or a defined target audience.

An Academic Exercise ? Given the failure of the manifesto to address the three questions I posed above, can we surmise that the undefined purpose of the document was to purely to complete an academic exercise to see whether such a document could be created? Without wishing to demean the contributors, when I cross-referenced the list on the back page of the manifesto, I wasn't surprised to find the vast majority appeared to be academics rather than practitioners. There is a certain irony in this because the first value regarding People talks about the failure of ivory towers in the drive for successful SPI!

Methinks there may even have been an unstated desire to create something akin to the Agile Manifesto simply because nothing existed in the SPI space. Unfortunately it's probably 20 years too late! It is probably fair to say that most of what is written in the SPI Manifesto is available in standard industry texts on process improvement and change management. It may not be as concise, but it is often written in a more appealing way, better explained and, almost always, with a specified target audience in mind.

Missing the Real Target

When you look around at the attendees of SPI conferences, seminars and SPIN groups, it doesn't take long to realise that most of the attendees are either SPI or Quality consultants or people suddenly faced with the prospect of leading or participating in process improvement initiatives for the first time.

Rarely do you see the CIO, CEO or CFO of an organisation, unless they are sponsors or key notes speakers at the event. In fact it is very rare for any decision making executives to turn out to these events. Clearly, they are busy people and cannot take four days out to attend conference. But these are the very people who we, as an SPI community, should be addressing. If I was a C-Level executive and this came to my attention I'm fairly certain my reaction would be along the lines of "So What?".

The trouble is, even as an experienced consultant and practitioner, my initial reaction to the SPI Manifesto is also pretty much "So What?"...

The Trouble(s) with Software Process Improvement

Fifteen or more years of software process improvement efforts have not lead to the remarkable changes that people like Watts Humphrey may have envisaged when he wrote "Managing the Software Process". The reality is that despite our efforts software development projects continue to fail either completely or to meet their intended budget, time and quality objectives. Even high maturity organisations deliver poor quality software, and the return on investment from quality and other process improvement activities remains low. That’s not to say that SPI has failed and we should give up on it, but if we continue to perform the same actions and fall into the same traps we can expect the same relatively poor results. Even companies that were early adopters of CMM and CMMI and have reached the highest levels of maturity now find themselves struggling to retain their status and suffering the mediocre results of more naïve organisations. Some of the reasons for failure are:

• Insufficient management sponsorship, ownership and responsibility - SPI is viewed as a technical activity and management directives are delegated to groups without sufficient authority to “Just go and do it”
• Software Process Groups lack the discipline and management skills required to undertake improvement projects, with the apparent effect of causing a “Do as I say, not as I do” environment
• Expectations of return are grossly over-exaggerated in an attempt to secure funding, and funding is removed before any real benefits are realised
• Supplier management is poor, and outsourcing suppliers often mismatched against the organisation’s values and beliefs, especially with respect to quality
• Focus on CMMI, maturity levels and specific goals rather than doing what is best and right for an organisation using diverse methods, tools and techniques
• An unmanaged approach to change leading to employee resistance at all levels of the organisation
• Failure to adopt a holistic approach across the organisation, with associated confusion, duplication of effort, and critical activities falling between the cracks
• Decision makers are informed about SPI activities rather than consulted and involved
• Waves of initiatives roll on without pausing to understand the effects of the previous initiatives and often undoing the good that has gone before
• Improvement plans are based on perception rather than fact - data is not used to verify that the right areas are being targeted
• Quality and process teams undermining their own efforts by failing to add genuine value to the organisation and its business

If you pick up any book on process improvement you will see that these and other issues like them have been identified and understood for many years, yet some or all of them still abound in any organisation currently running SPI initiatives. Given that those same books often provide the solutions on how to avoid the problems, I can only assume that there must be something more fundamental going on which is causing the software industry to fail to rise to the challenge, namely the people problems I described in my last post on the 7 Deadly Sins of Process Improvement (or Change Management). Next time I'll describe the first of these - Arrogance.

7 Deadly Sins of Process Improvement (or Change Management)

No-one ever said that Process Improvement was easy but there’s no reason why we have to make quite so hard. By understanding some basic principles it is possible to give ourselves a fighting chance of success. Gerald Weinberg famously said: “No matter what the problem is, it's always a people problem”, so it might make a bit of sense to start looking at some fundamental people problems which are often responsible for thwarting process improvement initiatives or indeed any other kind of organisational change programme.

Typically, when we look at do’s and don’t of Process Improvement or Change Management we focus on tasks, activities and actions which are recognised as good practice. “Run the initiative as a project”, “Obtain visible and effective sponsorship”, and “Communicate, communicate ,communicate” are some of the more popular concepts. But as Peter Leeson suggested at last year’s SEPG conference in Prague, despite understanding what good practices and techniques we should be using, we are still largely failing in our Process Improvement programmes even after 15 or more years.

One of the key issues is that while Process Improvement experts understand the problems, most of the people that they have to deal with don’t, so we need to step back and understand what makes these people tick, and how we need to approach them to help to better understand their roles and to adapt their behaviours to enable change to occur more smoothly.

This posting takes a different approach to the traditional Do’s and Don’ts by looking at key behaviours of people which are often the real reasons why improvement and change programme fails. If we can understand what dysfunctional behaviours to look for, how to spot them in ourselves and others and how to take steps to prevent them from interfering in our process improvement efforts we may be able to eliminate some of the problems which continue to plague us.

The 7 Deadly Sins described here are not the original Biblical sins which don’t translate too well in an SPI context, but are useful monikers to help describe the dysfunctional behaviour we are trying to eliminate. It’s important to appreciate that these terms, which could be considered somewhat emotive, are associated with behaviours, not individuals, although I’m sure we would all be able to recognise these traits in some of the people we have to deal with.

1. Arrogance - typified by Ivory Tower and Not Invented Here Syndromes, but also failure to use data rather than perceptions and refusing to take internal or external advice. Most likely to affect change agents and teams
2. Inertia - lack of momentum, analysis paralysis, fear of the unknown. Often associated with weak or ineffective leadership
3. Ineptitude - using the wrong people with the wrong skills. May be as simple as not defining roles and responsibilities carefully enough, but sometimes due to leadership appointing the wrong people
4. Impatience - dealing with unrealistic expectations. Specifically associated with executives who want instant results, but can affect all areas of the organisation
5. Carelessness - failing to focus on the details. Poor planning and poor implementation are often to blame, the devil is in the details
6. Ignorance - understanding what you don’t know, aligned to the attributes associated with arrogance, but often a common cause of resistance in the end user community
7. Extravagance - getting carried away. Process Experts, especially from a technical background are just as likely as programmers to gold plate solutions. Senior Management may also play a part in demanding more than the organisation can absorb

We'll examine these sins in more detail in future postings.