It couldn’t happen here, could it?

It couldn’t happen here, surely!

Consider this story.

A BA, experienced, attentive to the customer need, knowledgeable in the process, gathers requirements from the business and carefully sets them out in the Requirements Document. The document is reviewed and signed off.

Solution time. The functional specs are retrieved from the repository. The solution is designed with developers and the business. The functional specs are updated and sent out for review by all stakeholders. Comments are dealt with, final sign-off obtained and the functional specs are handed to the developer and tester.

The developer designs and builds exactly what the functional specs require. Good move – only giving the business what they need and no more is efficient.

The tester writes scripts that match the functional spec, then tests against those scripts. The scripts are peer and team leader reviewed – quality is assured. Defects are raised, resolved and the software is put into production.

But, the solution had a problem.

Five new fields created by the project accept and validate data, but do nothing with it. It isn’t saved, and it isn’t used in a calculation. It is captured, then it vanishes – David Copperfield style.

We know it cannot happen here, don’t we?

I have spent a lot of time talking to people in IT about how they achieve quality.

I asked many because I wanted to understand the collective approach to quality. One of the questions was: “How do you ensure that what you do is quality?” The answers have been magnificently consistent.

First quality step: Peer review. Second: Review and sign-off by the business. Third: Check it back to the Functional Spec. Fourth: It has been tested.

All these steps were done in our story and yet the customer received a flawed update to their application.

Is there a gap in your quality? Could this have slipped through where you work?

If it did happen here, who would we blame?

The developer, tester and then the BA, in that order, is the logical reaction.

But that would be wrong.

We work in a system. We pay homage to a process. We get blamed when we do wrong (we even get blamed when we do it right, generally because of immovable deadlines). “Things would work much better around here if we only followed the process” is a frequent comment. Our KPIs are chosen to make sure we do the process.

Our work is challenging. Project Managers are under pressure from the business to deliver. BAs, Developers and Testers are under pressure from the PMs and their Team Lead’s. We work with complex and highly integrated systems. Errors are abhorred – errors in production rightly get a strong reaction, because they cost us money and can potentially put us out of business. Our knowledge management is not top notch. We are held to initial estimates and deadlines, even though we know we tend to underestimate the time it takes to deliver. Our processes are high level, because our context is too complex to get specific.

Blaming the people is wrong. People do the best they can. Nobody deliberately fails to save or use data captured through the user interface.

We would have to blame our process, if this was to happen where you work.

The correct question

“Better Every Day” invites us to make a great Quality decision every time. The process is not the point, getting great results are.

We have “Better Every Day” because our complex environment means that we cannot make rules that cover every eventuality.

Too many rules means we no longer think for ourselves – that we will start to believe that we succeed by following the rules. People thinking and learning is what brings success, not rule following.

The correct question is not: “How do we make the process perfect?” It will never be perfect.

The correct question is: ‘How do we make it “Better Every Day”? ‘

The bizarrest part of the story?

This really happened. I was told the story by a number of participants, and it must be true because the boss told me too.

It could easily have happened where you work.

It almost happened to me, once, when I was working as a Business Analyst. Fortunately the developers caught my error.

So, how are you getting Better Every Day?

Hopefully you don’t say: “I just follow the process”. Hopefully your answer shows that you bring your whole brain to work, and use it, not just the process following bit.