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.

On fixed and variable costs and infinite loops

Everyone seems happy with the proposition that fixed costs should be kept as low as possible in a volatile business environment. That way, you can respond quickly if and when the market moves in an unexpected direction. Everyone also seems happy with the proposition that in the services sector, compensation for human endeavour overshadows any other type of cost. Services are fundamentally people businesses. Many of the arguments that support outsourcing and/or offshoring rely on some of these propositions, at least in part. It is normal to augment the propositions with other arguments, usually to do with comparative advantage, with core competences, with a need for focus, with location, skill and wage arbitrage, and so on.

This post is not about any of those arguments, or about offshoring or outsourcing. You have many places you can go to for those arguments. What this post is about is the little bit that stays behind. The people and processes and skills that are not outsourced or offshored or anything like that.

What intrigues me is how we manage this little bit. This little bit that’s made up of people spending time alone and together.

How does these people interact? Via something called diaries and schedules and organisers and what-have-you. What tends to happen? We have some strange form of negotiation that takes place between all these diaries in order to bring people together. As a result of many such negotiations, the diaries and schedules get filled up, and people then go about their Assembly Line lives. Move from meeting to meeting shuffling bits of stuff every now and then. Attending conference calls that could be audio or video or physical or some mix of the three.

Park that thought for a minute.

Now take a look at time. How long it takes for things to be done. Quite often, the biggest single delay in a process is the time required for getting the “right” people together. How do these people get together? Via the strange negotiation process I referred to earlier. As a result, the time taken to do something is often heavily influenced, if not altogether dictated, by the interactions between the diaries of groups of people.

In principle things like prioritisation and importance fall by the wayside, although organisational structures and status and hard-working PAs can do something to raise priority. Most of the time, it is the scheduling process that sets the priority. Which is strange in itself.

To make matters worse, particularly in large firms, there is some implied code whereby someone who wasn’t at a meeting is able to reopen debates about decisions taken in his absence. Now, since there’s always someone absent at every meeting, what it means in practice is that decision loops become infinite. And nothing gets done.

I have always tried to counter this tyranny of meetings and schedules by having a concept of fixed time versus variable time. I limit the number of meetings that I commit to more than 48 hours in advance. This way, there is a balance between things I commit to well in advance and things I commit to in the short term. I have this sense that what I do makes sense (otherwise I wouldn’t do it….), but I wondered how other people viewed this. I try and describe this attitude as “fixed time versus variable time”; fixed time refers to the meetings you fix more than 48 hours ahead, and variable time refers to the shorter term; call it what you like, I don’t care, as long as we speak about the same thing.

I was in Brussels recently, attending an Identity Open Space organised by The Liberty Alliance and Kaliya Hamlin et al… thanks to all who made the event happen. It was a good session, one where I met old and new friends: Doc, Adriana, Steve, Ben and Kaliya, amongst others. More later on thi.

Kaliya kicked off the second day by reminding everyone about the Principles of Open Space, shown below:

The image “http://blogs.zdnet.com/images/rules2.jpg” cannot be displayed, because it contains errors.

What intrigues me about all this is the following:

Owner-managed companies have no problem with schedule and meeting conflict, or about reopening decisions after they were taken. Why? Because what the boss says, happens.

Self-organising events also have no problem with all this, as the Open Spaces principles suggest. Open Spaces have been around for a long time…. Johnnie Moore, who introduced me to them, suggests that the concept was formed sometime in the 1980s by Harrison Owen, and has continued to evolve ever since. For those who are interested, here’s Johnnie on the subject: link.

At the two extremes, owner-managed and volunteer-self-organising, there is no problem. The problem is in that great space in between, particularly in large firms and public sector companies and governments. All bureaucracies.

Which makes me think. If you want to kill a bureaucracy you must kill the diary and schedule first. Views and comments welcome.

One more thing…

Sean told me he was going into hibernation a few months ago, with the intention of surfacing again after Easter. He reiterated this when we had dinner a few weeks ago.

He’s kept his word. Nice to see him up and about again, I really enjoyed working with him. If you have the time, go take a look at his latest post on The Park Paradigm. And if you haven’t seen it yet, follow the link in his sidebar to AmazonBay, if it still works. He’s a really inspirational guy to work with.

Made a difference to that one… why customer service is not a numbers game

I’ve written many times about the reasons why, in a commoditising world, the only true differentiator is the quality of the customer experience. You can read about it here; earlier, when guesting on Shane Richmond’s Telegraph blog late last year, I covered it here, here and here as well.

Where I work, we take this very seriously. And I mean we, everyone in the firm is focused on the issue of customer service. Which brings me to the point of this post.

A poster at work has a summarised version of this story, I’m sure most of you have come across it before:

Two men were walking toward each other on an otherwise deserted beach. One man was in his early 20s, the other obviously much older. The smooth damp sand was littered with starfish, washed onto the land during high tide. They were stranded there when the tide ebbed. Thousands of starfish were doomed to die in the warm morning sun.
The younger man watched the older man pick up starfish one at a time and toss them back into the ocean, giving them a chance to survive. The young man thought, “Why is he doing that? How foolish. He can’t save them all.”
As they came near one another, the younger one felt compelled to point out to the older man the futility in his action. “You know,” he said, “you can’t save them all. Most of them will die here on the sand. What you are doing really won’t make any difference.” The older man studied the young man for a moment. Then he bent down, picked up a starfish and tossed it into the water. He smiled at the young man and said, “It made a difference to that one.” Then he walked on, picking up starfish and tossing them back into the sea.

Sometimes we can get lost in the metrics of what we do, we start hiding behind the numbers. This is dangerous when it comes to customer service, particularly if we start managing what we do according to those numbers. To put it bluntly, getting something right 90% of the time is not much use to the people who had the misfortune to receive the 10%. This is the sort of thinking that issues instructions to “downsize” departments by “66.51 FTEs”.  This is the sort of thinking that designs economy/coach seats on airplanes, I am still looking for the “average” person they used….. or maybe the 0.89 average person they used after someone else “haircut” the budget….

A person is a person is a person. Flesh and blood. Not a number. Not a statistic. So we have to be careful. Customer experience is not something abstract, it is what real customers experience all the time. One customer at a time.

When anyone seeks to improve “the customer experience”, he or she would do well to think about a real customer. Talk to the real customer. Improve the real experience of that real customer. Plan to improve the experience of every customer, one by one.

When you think that way, and plan that way, and execute that way, you will improve the customer experience.  You have to think like the old man in the fable above, and make sure “you make a difference to that one”. One by one if necessary.

Site specific random surfing and related subjects

random pageSome of you may have noticed that this blog now has a Random Page feature. The way I heard it, StumbleUpon announced a Site Specific Stumbling facility; someone asked Photo Matt whether there was a WordPress plug-in that did something similar, and soon there was one. Because Matt built it. Thanks, Matt! and thanks as well for the link to Curt Schilling, fascinating…. particularly for someone like me who follows cricket….

What Matt did is a perfect example of what I meant in an earlier post:

Scarcity models are by definition not scale-free; a hit culture prevails. Opensource, given the lower barriers to entry, allows someone to build a left-handed credit derivatives juicer because he felt like it. There’s a long-tail effect. You are more likely to find esoteric tools in an opensource world than in a closed source one. Opensource people don’t go around asking “Is there a market for this?” They solve problems and see if others have similar problems to solve.

Things happen in opensource communities, happen in ways that are fundamentally different from traditional models. The WordPress community is a good example of how this happens, how an ecosystem evolves around a many-sided marketplace. What Matt did is what opensource people do. And it is worth bearing in mind that while we speak of the community at large, work is actually carried out by individuals. Individual people doing individual things, but aligned to a common set of values and ethics. Values which include experimentation and learning and sharing and transparency and openness and component architecture and reuse. Values which do not include Not Invented Here and selfishness and not-sharing.

What you see in action is the A in NEA. Anyone can improve it. [See earlier post on CIOs and responsibility]. So now I look forward to further improvements, as someone adds collaborative filtering support to site specific “stumbling”.