One of the most common reasons for organizations to adopt Agile is to improve quality.

Still, Quality is one of the hardest things to define and even harder to measure.

Quality is relative and subjective. A real understanding of a product quality level is only known after delivery.  How can we create a high quality product if we have no feedback about the quality along the way?

For this matter, many organizations use leading indicators that they follow for the purpose of creating a high quality product. Common quality leading indicators may include:

• 0 critical bugs.
• Up to 20% medium and low severity bugs
• 80% automation coverage

All the above measurements imply the outcome of perfection.

Unfortunately too many times there is not enough correlation between the status of these leading indicators and the true quality of the product that is revealed only after it was released.

There are many examples where the release was rated with low quality while customer satisfaction was high or vice versa. Why is that?

Let’s look into the definition of (business) quality From Wikipedia:

“…Quality…defined as being suitable for its intended (fitness or purpose) while satisfying customer expectations…”   (https://en.wikipedia.org/wiki/Quality_(business))

Quality is defined by satisfied expectations, not by perfection.

So why do organizations use perfection measures as leading indicators for quality?

Following these leading indicators may achieve perfect code with minimum number of known bugs and maximum coverage. Does this mean they achieved high quality with regards to expectations?

Agility promotes quality because delivering frequently and often enables sharing expectations frequently and visually (working software) and revealing hidden assumptions early.

The longer we wait for something, the more starvation we create and hence our expectations get higher. Therefore quality will get lower by definition. We expect more, we get less.

The faster we get something, we can use it and ask for more or ask for something different. If we did not get what we expected, we would be disappointed. However, since we did not wait for too long, our disappointment will usually be smaller accordingly.

The gap between the actual delivered product and the expectations will get smaller when we get value earlier. Getting value fast promotes trust and improves satisfaction.

For that reason, a better leading indicator for quality, in my opinion, would be cycle time.

Cycle time is the latency between the initiation and completion of functionality. It’s the count of elapsed time between that time we started to work on the required functionality and until it is DONE and delivered to the customer.

The shorter the cycle time is, the less time the customer has to wait in order to get it and satisfy his needs and therefore the higher quality he gets. If the customer request was not fully achieved, he can expect a fix in a short period of time.

Shorter cycle time promotes higher quality

Zero defects approach promotes perfect code.

Which of these is your goal?