In the customer’s shoes

I think it was sometime in 1983 when I first heard the term Quality First in a software context. Callow youth that I was then, I understood it and absorbed it in that narrow context; my view then could have been summarised as “An inspection culture encourages people to be slipshod, because they know someone else is there to trap the faults”.

Some years later, in 1988, I heard someone speak on the same subject, but from quite a different perspective. He ran the Fleet Air Arm‘s medal-winning team for the Field Gun Exercise at Earl’s Court. And what he said was interesting. The way he described quality first made it something holistic, comprehensive, 100%, built around teamwork and trust. When you’re moving a few tons of steel across a large field at high speed, you don’t have time to look around to see what someone else is doing. Not unless you want to be hit in the face by said tons of steel.

Ever since I heard that talk, I’ve had a different view about quality first. A view that goes beyond the arguments about the pros and cons of inspection cultures. What intrigued me about the whole thing was the speed element. First and foremost, the Field Gun Exercise is about speed, about getting a faster timing than other teams. And what this guy was saying (at least to me) was simple:

When your life depends on speed, you don’t waste time checking. You train to build the trust and fitness and strength and holistic view. You train and train and train. In order to avoid having to check. Because checking may mean death.

This concept has stayed with me during all my musings around Agile and around the Customer Experience. The Field Gun Exercise seemed particularly apt when I considered the reduction of Cycle Time or the improvement in Right First Time measures. Now these are things that we really concentrate on where I work, things that we know we have to improve, and improve dramatically.

So here’s where I think we are:

1. You go “live” when you pass all the test cases

A waterfall-model UAT wastes precious cycle time. The only reason we use waterfall tests is because we don’t trust the user stories, we don’t believe that they are comprehensive enough. We must concentrate on getting the user stories and test cases better, rather than fall back on waterfall processes.

We have to regard user stories as a means of reducing programme risk; as the quality of user stories goes up, the risk of delivery failure goes down. David Anderson, in Agile Management for Software Engineering, recommends the use of a 3×3 matrix for classifying stories. Risk is measured as Low, Medium or High, while Complexity is measured on a scale of 1-3. The nine possible combinations help us understand more about the nature and quality of the user stories upon which the test cases rest. David also believes that level-of-effort estimates will converge over time, for a given risk-complexity level in a given organisation. So estimation should also improve. The risk-complexity matrices also help in scheduling development of the stories, allowing the use of simple options theory in that process. More on this later.

2. You need increased user involvement in order to improve the test cases and user stories

Agile end-to-end testing in the context of improving the customer experience requires us to think differently, requires us to ask different questions of the customer, requires a different level of participation by the customer. We have to keep asking “tell us all the things you need in order to use this” ….. physical things, what needs to be acquired or moved and to where; skill-related things, what training and education and knowledge transfer needs to take place; emotional things, what will make the customer feel comfortable with the changes, with the new functionality, with the new way of doing things, what support will be required, how much of that support is face to face. And systems things, both “functional” as well as “non-functional”.

It is easy to say this, doing this is much harder. There is often an organisational inertia to change, particularly when that change encompasses processes and systems. So getting internal users committed to participating in that change is often like pulling teeth while walking blindfolded through a bed of treacle. When it comes to “external” users, the problem is somewhat larger.

So what’s the answer? In my opinion, it’s all about incentive alignment. If someone feels that they will be able to do their job quicker, better and more easily as a result of their participation, then they will participate. This is true for internal as well as external customers. We need to get better at telling people why. Why the effort is worthwhile, why the change is worthwhile. And guess what? Most people are actually interested in seeing cycle time reduced, in seeing right-first-time improved. What we have to do is make the payoffs really clear, then people will commit. The User Stories will get better, the Test Cases will get more comprehensive, standard deviation in the quality and size of user stories will reduce, estimation processes will get more accurate. Everyone wins.

3. You need to iterate, iterate, iterate.

Somewhere down the line, all this comes back to the Field Gun Exercise. We need to practise. Keep practising so that we’re fitter at what we do. Keep ironing out process weaknesses. Keep building trust, improving teamwork, raising customer satisfaction.

That’s why we need permanent places to meet, to train, to iterate, to build and to deploy. Where I work, we call them hothouses, but the terminology is less important than the principle.

You know what? When you look at the teams taking part in the Field Gun Exercise, one thing stands out. They make it clear that they really enjoy what they do. Let’s not forget that.