Can software teams deliver basic quality?

Anyone who has taken a Lean Six Sigma-training must have shared my initial perplexity when encountering the very extensive toolbox it offers. Lean Six Sigma offers a mass of techniques for analysing and improving processes, and what is worse: each seems to want to outdo the other in finding an obscure name. It's either a very cryptic abbreviation which is not intuitively recognizable - or Japanese. Which, I must confess, is in my case a bit rusty.

Among these tools is an analytical model developed in the 1980s by Professor Noriaki Kano at the Tokyo Rika University. It is known as the Kano-model and is a theory for product development and customer satisfaction. It has an almost natural appeal to many people. There are very few for which it does not immediately click. But I was one of them.

The Kano-model

Most Lean Six Sigma-courses that discuss Kano, focus on three categories of activities that a business can carry out to satisfy customers. These activities are plotted on one of three curves to describe their effects.

<span class="image left"><img src="/images/kano-model.png" alt="" /></span>

The first are activities contributing to Must-be Quality: the things that the customer doesn't ask for but simply expects. If these needs are not satisfied it leaves a very bad impression. Meeting this level of quality will never make your customer happy, and if you screw up it destroys any chance of a relationship. The canonic example for this curve is cleanliness in a hotel. Nobody asks for a clean room, it is expected, and if not satisfied, very few people are willing to give you a second chance. Another example is the length of the queue at check-in - nobody asks to not be kept waiting.

The second group of activities are focused on One-dimensional Quality: the things that a customer actually asks for. The more of these needs you can fulfil, the more your customers will be satisfied. There is a direct relationship between delivery and satisfaction. To stay with the infamous hotel example: an excellent bed, a large walk-in shower, a swimming pool, a car park, a fast internet connection and shuttle services are all part of One-dimensional Quality. Answering these requests makes customers happy, and failing to do so disappoints them proportionally.

The last activities deal with Attractive Quality: those things that no customer asks for, but can truly impress and delight people. It earns you cookie-points as a business: the tray with chocolates on the bed, or returning your car washed & waxed after your stay. Delivering these makes you the best in class.

For a brick & mortar company - like a hotel - this model seems quite straightforward. But I don't own a hotel - I build software! And in my experience - we don't work like this. The problem with the Kano-model for software engineers is in the definition of 'customer requests'. It is quite clear cut for a hotel: a customer needs a room for spending the night. But what does a customer request of a software company? Coding? Can we view 'hosting code' or '24/7-support' as One-dimensional Quality? Do we delight the customer by throwing a launch party when the code is finished? Yes to all, probably. But all of these are tiny in comparison to the elephant in the room: Must-be Quality, the software should do what the customer expects it to do. Nobody explicitly asks for this, but everyone will be deeply dissatisfied when it isn't delivered.

Cue: Lean Six Sigma trainers now proceed to explain that this is comparable to a hotel that promises a room for the night, but is booked full upon arrival... Oh, I wish customer expectations in this industry would be formulated so clearly :)

The customer does not expect code

For a hotel the expectation is clear: I book a room - I expect a room. But when a customer books a software developer they usually don't know what to expect precisely. One thing is clear though: it's not the source code, and it's not a bunch of configuration files plus a database! What they care about is achieving an effect in the real world. A customer may want an app to calculate the answer to a research question, a form to register safety measures on an oil rig, a dashboard to keep track of performance indicators for mortgage investments, or an endless number of other real effects in the world. They expect engineers to deliver something, anything, that will accomplish that.

However, when customers start to clarify the desired effects, they quickly move into the realm of vague and ambiguous descriptions: 'the app is slow' versus 'we need 15% better performance on these database query requests'. Hardly any client is able to precisely stipulate which features they need in order to achieve the desired effect. And the resulting expectations may or may not be technically feasible, are often nuanced, contradictory, or sometimes self-serving and without focus on the actual future user. Many, if not most, of the engineering teams I encounter, struggle with this. The industry has even invented a name for tackling it. It's called 'Expectation Management'. There is not a single software development team in the world that does not have someone responsible for moderating (and restraining) the customer. Moreover, as part of managing expectations, we developed a categorization in must-haves, should-haves, could-haves and won't-haves. The truth is of course that it's not a four-way arrangement at all. We only really deal with two groups: must haves, and won't haves. And if it isn't in the must haves, it is a won't have. The other categories are simply there to soften the blow, for us to be able to say: 'We will do that if there is time.', instead of an outright 'Nope, is not going to happen...'

Sidebar: many management guru's will claim that you can fix these issues with insert-cherished-project-management-method-here. This is at best naive, and at worst smacks of a charlatan. Software management methods, whether they are agile or not, can only manage the uncertainty. They can't fix it. They do this by either working in small and short iterations that are, if necessary, easily rolled back if the customer seems unhappy, or by long pages of "Risk and Indemnity Analysis" that basically boil down to figuring out who is at fault when and where (and pays the bill).

So from this perspective, Kano talking about One-dimensional Quality or even Attractive Quality is rather theoretical. Most often, as software engineers, we are already pleased when we deliver Must-be Quality on budget and in time. And yes, that's why the software industry has a bad reputation, and yes that's why many projects fail. But the demand for software coding is so enormous and the supply so scarce, that we can afford this. We miss the incentive to change.

Delivering basic quality

But given an incentive to change, could we? Is it possible to address these issues and achieve the desired real-world-effect? So that we can structurally learn to deliver on Must-be Quality? Because only when we figure that out, can we start thinking about Kano's other qualities.

I think there are two reasons why we find it difficult to continuously meet Must-be Quality. The first I have mentioned above: the difficulty of identifying actionable requests. This is primarily caused by the huge information gap between customers and software engineers. In most cases the software solution for the real-world-thing does not yet exist. And unlike the software engineer, the customer is often an expert in the real-world-thing. The developer, on the other hand, is an expert in building solutions. As engineers we try to close the gap by going to communication trainings and brainstorm sessions. Some fields even established specific degrees (such as a Master in Bio-Informatics or Digital Heritage) or fund entire sub-industries (like FinTech) to bridge between the two worlds. We are trying everything, and spending a ton of resources in the process, in order to understand each other better. But if that gap was simply solved through education and communication, none of you would be reading this blog - and we would all concern ourselves with the other qualities in Kano's model.

The second reason is our love for technology. Who doesn't enjoy constantly thinking about improvements? We enjoy making things more robust, more precise, more sustainable, more scaleable, and more elegant. There is beauty in code! And we like writing it. The truth is that we can go overboard here. When such improvements help the customer achieve the real-world-thing: a winner is you. But it is my experience that we tend to forget to ask that question. We write the code because it simply could be better, more beautiful, forms a challenging puzzle to solve, or even because saying: 'it is not yet done' is sometimes easier than delivering.

The Kano-model revisited

Now, hold that thought! At this point I discovered that most Lean Six Sigma-trainings are not telling the entire Kano-story. In his paper Kano does not distinguish three categories, he defines five. And the missing two are quite consequential.

Activities that have no positive or negative effect on customer satisfaction, are contributors to what Kano calls: Indifferent Quality. Sounds familiar? Most activities that I just mentioned are exactly that. Every time we sit with the customer and proudly present a technically outstanding and elegant solution, only to see the customer shrug...? That's what was going on. Worse, the conversation will inevitably return to the ambiguous expectations of Must-be Quality. Tragedy strikes if that hasn't been delivered. No amount of technical superiority will then make a difference for the customer.

The final category Kano describes is Reverse Quality and is also highly relevant for us as software engineers. It is the understanding that we may actually be causing dissatisfaction by doing something exquisitely. When we explain e.g. the technical details of the solution at length, in a well-meant attempt to create customer understanding, we may be causing the reverse effect. Especially if our intention is not actually to create understanding, but to gain recognition for technical elegance. Not many people can muster the patience, let alone the appreciation, when their basic needs for Must-be Quality are not met.

The addition of Indifferent Quality and Reverse Quality made the Kano-model 'click' for me. It gave me an insight in how I, as a software engineer, deal with customers - and why some of them in the past reacted the way they did. Over the coming months I will return to the topic and explore the relationship between software engineers and customers further. I intend to go deeper into methods to help customers formulate actionable requests, and how software engineers can deal with the different qualities in Kano's model. Ultimately, I'd like to find the incentive that will change our behaviour - so that we can focus on other qualities. Just in case we manage to structurally deliver on the basic needs and no longer by good fortune.

We love to meet you! If you'd like to have chat over a feel free to send an email to cup_of_tea@fourdays.nl. .

• gertjan.filarski@fourdays.nl
• jauco.noordzij@fourdays.nl

Fourdays is a company registered in the Netherlands.

Chamber of Commerce: KVK Rotterdam - 83363084.

• RSS-feed
• Privacy Statement