 |
Home > Detail: The Forgotten Side of Quality
Viewing Item 1 of 483
| A StickyMinds.com Original |
|  | |
The Forgotten Side of Quality
By Jeff Patton
   
Summary: Our perception of quality includes objective and subjective factors. In this week's column, Jeff Patton explains the difference between the two and proposes we forget those differences so we can start viewing the two as equals. | | |
|
|
 |
 Hear more about this topic in the StickyMinds SoundByte podcast interview with Jeff Patton.
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.
Considering Kano
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 translation of the original work, I found I was right.
Before describing the simple Kano Method, the authors spend a fair bit of time on the concept of subjective and objective quality. Using good references and a long narrative, they trace quality discussions back to 300 B.C.—really, I'm not kidding. They summarize by saying:
"Discussions of quality have revolved around the two aspects of subjectivity and objectivity since the time of Aristotle. Embedded in this objective-subjective split is the idea that objective quality pertains to the 'conformance to requirements' while subjective quality pertains to the 'satisfaction of users.'"
If you've ever released bug-free software that people hate or software with bugs that people love, you know what I'm talking about. Lately I think more about the aspects of the software that would lead me or anyone using software to believe the quality is high. Where the Kano Method attempts to give a bit of a heuristic for identifying subjective aspects of quality, it's just a simple heuristic. The main point—and mine, in this column—is to consider subjective quality on an equal level with objective quality.
Feature Polluted, Quality Starved
A product manager friend once grumbled to me about a problem he commonly has. When introducing a new feature into his product, he'll initially introduce a simple version of it. When he goes back to improve it, his stakeholders will stop him and say, "We've already done that feature! We've got all these other features to implement before we go back to that one." He'll reply, "But that feature is crap"—to which his stakeholder will say, "But, it's been tested thoroughly. It works fine."
You can see from this story that my less-than-tactful friend has a desire to improve the subjective quality of the feature, while his stakeholders are focusing on the objective quality. In addition, they're guilty of some bad behavior I often see in product management: feature pollution. And sadly in these sorts of products, while the feature count may be high and the bug count low, the subjective quality is often low as well. Customers often don't like the product, and an unenlightened product management's response often is to add more features at customers' request. This is what Alan Cooper calls a "customer-driven death spiral."
In software development, more features is often considered better. Since we're consumed with the quantity of features, we often forget the quality of the software as a whole unit.
Use Product Report-Carding to Evaluate Subjective Quality
A while back I wrote an article about managing feature scale, but what I was talking about was the feature's subjective quality. Well, that and building stupid variations of product features that cost too much to build and don't really improve customer satisfaction.
In the process of teaching others iterative development, I explain that a feature is never really done. We can always add a bit more to it or change it to improve the feature's subjective quality. Once, when I was explaining this during a class, someone piped up and said, "We do that! And we use a letter-grade system to evaluate how good it is! We'll give our features a grade—say, a D in an early iteration. As time goes by and we add more, we'll up the grade. We shoot for an A."
Ever since hearing this disruptively simple solution, I've been creating report cards for my product. Give this a try on your product:
- In a small group, brainstorm the major features of your product.
- Independently for each feature write your "grade" for the quality of the feature. Answer the following questions: Do you like the feature?; Do you like using it?; and Is it a valuable part of the product? Let your answers help you grade the feature with an A, B, C, or D, or fail it with an F.
- When done, discuss your grades with those in your group. Agree on a grade that best represents the group's opinion of the quality of that feature.
Ideally you might perform this experiment with your customers, since you're concerned with customer satisfaction. But doing a quick temperature check inside your team is a good starting point. It's also good to compare your impressions with those of your customers.
I started with a bit of a rant about the imperfections of the Kano method. And while that method may have its limitations, the idea of looking more closely at the subjective quality of a product along with the objective quality is what's most important—and is what I believe was Kano's real point. Before polluting your product with more features, consider a quick report-carding exercise. What grade would you give your product today? Consider that grade a measure of your product's subjective quality. Before you add additional features, consider whether you may want to improve the quality of the features you have instead.
Further Reading
- Attractive Quality and Must-be Quality, by N. Kano, N. Seraku, F. Takahashi, and S. Tsuji.
Originally printed in The Journal of the Japanese Society for Quality Control.
About the Author
Jeff Patton leads teams of Agile developers to build the best software possible. He proudly works at ThoughtWorks. Jeff's series of columns on software design and pre-design tips appears regularly on StickyMinds.com. Among Jeff's accomplishments, he can add winning the 2007 Gordon Pask Award, which he received at the Agile2007 Conference in August. Jeff's blog, presentations, and other articles can be found at www.agileproductdesign.com.
Back to Top
StickyMinds.com Weekly Column From 9/10/2007
|
