When I used to think of quality with respect to software, I thought about bugs-and hopefully the absence of bugs. No bugs equals good quality. But, of course, I knew it wasn't quite that simple.
I own a German car, and I really love its quality. Sadly, it breaks down more often than my father-in-law's Lincoln. But I keep my German car because I like its quality. So, what exactly am I talking about when I say "quality"?
The truth is that I'm talking about two kinds of quality: objective and subjective. Forgetting that there are two types of quality and not paying close attention to both can lead you to releasing software that, while bug free, is actually of poor quality. Let me explain.
Some of you may have heard a bit about Kano and the Kano Method, but don't be sad if you haven't. When I first heard someone talk about Kano, I was pretty sure they were talking about the evil guy from the Mortal Kombat game. Then I came across Mike Cohn's article " Whipped Cream on Top of the Sundae ," in which he did a good job explaining the Kano Method-and didn't mention Mortal Kombat once.
The Kano Method separates product features into general categories. The three big ones are "must haves," like: brakes on a car (we need those); "one-dimensional" items like gas mileage on a car (higher mileage is better); and attractive quality or "delighters" (leather seats in my German car are a delighter). The idea is that your product should have all the must haves, maximize the one-dimensionals, and toss in some delighters.
The tricky thing about Kano is that you can split just about any feature of a product along different Kano aspects. For example, it's true my brakes are a must have, but stopping distance is a one-dimensional aspect-at least that's what Car & Driver tells me-and adding anti-locking is a delighter since I live in a snowy climate. Trying to precisely identify the Kano category of a feature is almost impossible because of this splintering, so don't try too hard.
To further complicate the matter, things change. Airbags might have once been considered delighters, but now they're sort of a must have. Meeting government safety regulations is a "must have," but manufacturers like Volvo have converted the above-average safety aspects of its cars into delighters. In software, Ajax field auto-complete may have been a delighter a few years ago, but it's drifting into the must-have category for most commercial software. In other words, don't try too hard to classify your features because they'll change over time.
There are other twitchy issues about applying the Kano Method. The questionnaire can be difficult to interpret and can deliver inconclusive results, not to mention that people are famous for inaccurate self-reporting. People often describe a feature as being necessary, but when allowed to use a product without that feature but with other high-quality aspects, they don't find that feature quite as necessary. For example, I use AutoDesk's SketchBook Pro, in which I can only open one drawing at a time. If you'd have asked me if I'd be OK with a drawing program that can only open one drawing at a time, I'd have said "No way!" But, I'd have been wrong.
So, rather than throw the baby out with the bathwater, I wanted to dig deeper into Kano.
What Were Kano and His Colleagues Getting at?
I felt like there had to be more to the Kano Method than this. And, after going back to the 1984 Japanese