Sunday, September 23, 2012

Agile and the Definition of Quality


A Bug in the Family
"It's a rare bug," he said.
How would you have answered?

The Relativity of Quality

Finding the relativity
Take for example Crosby's definition:
"Quality is meeting requirements."
"Quality is meeting some person's requirements."
a. To Terra, the people involved were her readers.

Who was that masked man?
"Who is the person behind that statement about quality."

a. "Zero defects is high quality."
2. to a manager who would be criticized for those defects

b. "Lots of features is high quality."
2. to marketers who believe that features sell products

c. "Elegant coding is high quality."
2. to professors of computer science who enjoy elegance

d. "High performance is high quality."
1. to users whose work taxes the capacity of their machines
2. to salespeople who have to submit their products to benchmarks

e. "Low development cost is high quality."
2. to project managers who are on tight budgets

f. "Rapid development is high quality."
1. to users whose work is waiting for the software

g. "User-friendliness is high quality."

The Political Dilemma
More quality for one person may mean less quality for another.
Whose opinion of quality is to count when making decisions?

Quality Is Value To Some Person
"Quality is value to some person."

The Impact on Agile Practices


Anthony Green said...

I consider the lines:

c. "Elegant coding is high quality."

a little disparaging

Could we say instead
c. "Elegant coding is high quality."
1. to future developers who have to return to the code to maintain or develop it further.

Robert Carey said...

I read your book on quality software management in the mid nineties and loved it. However, I have always had trouble, not with your definition of what you call quality, but your choice of the word "quality." At at least one place that I worked, rather than help understand requirements it led to more or less bike-shedding arguments about the meaning of the word.

I worked for a wall street program trading (index arbitrage) company. There was a window of, say, two weeks in which they needed a way to price a certain kind of product. The IT department was broken down into research (mathematicians) and systems (programmers). The software to do the pricing was written by someone in the research department. It was a command line program written in C to run under Unix. About half the time it was run it printed "segmentation fault, core dumped" and exited. The author of the program said, "Don't worry about that, just run it again." (I never personally analyzed the code, so I have no idea why rerunning it fixed the problem).

There were a number of high priority projects going on, and no one in systems was available to spend time on this. The guy who wrote the program was not up to the task of finding the bug. The program seemed to work reliably when it worked at all. My main concern about releasing it into production was that it lowered the standards of what people would accept.

At any rate, here's the problem with talking about this program in terms of "quality." The subroutine that did the real work was clearly of pretty high quality in the sense that it took in the necessary information and spat out what the traders needed to know. The packaging of the program was abominable. No one at the company, even the traders who needed it, would have referred to that piece of software as high quality. However, no one would have asked the programmer to spend time fixing it. It was needed "now" and for the coming two weeks. After that it would have no value at all.

While no one at the company would have said that program was high quality, everyone knew that it made reasonable tradeoffs for its intended purpose. So, I think the problem here is that recognizing "value to some person" is important, possibly more important than "quality," but "quality" is possibly not the best word to use to describe it.

Peter Varhol said...

At the very least, MiniCozy can be faulted for false or deceptive marketing. That may not be the project manager's problem, but it is the company's.

Great post, it illustrated a point I had tried to make with much less success recently.

Yaki Koren said...

The golden calf was there because the "who" was unreachable. When the customers are far away we start making assumptions which in time become facts in our minds.

robertvl said...

A point well made. Reminded me of your "quality versus apple pie" story.

Sadly, many teams just jumping on the agile bandwagon focus on the wrong things. They pride themselves in number of user stories delivered, velocity, or other numbers, at the expense of quality, because it is not straightforward or because it doesn't fit their user story template.

I'm delighted you're writing on the subject; hopefully these posts will help inspire them to give it some more attention.

David said...

It seems there is a shift in agile community so now all teams must release a high quality / low defects product. Why we don't let our product owner and customer decide what level of quality they feel most comfortable with?

Kouros Mohit said...

Product "quality" can only be viewed from the consumer's (enduser, customer) point of view. If the product fails to perform any of the required functions per specification then it may not be qualified as high quality. It is as simple as that.