Summary: Quality driven dev, when dialed to 11, can quickly reduce error rates to near zero. At least that’s the theory.
Big Bang fails too big. Frequent delivery fails more often and provides better learning opportunities. That’s a huge improvement. Quality-driven dev, which focuses agile dev on salient quality factors, can further improve dev results.
Operational definition of “quality”
Q(total) = f (q1, q2, … qn)
That is… for any cycle, quality is some function of the salient quality factors in your context.
Knowing your context, *you* are responsible for defining quality for your customers. If you want someone else to define and manage your quality, you are sinking not swimming.
If this sounds like a heavy responsibility, relax, here is a theoretical life preserver:
- Atomize and timebox your cycles
- Select ONE QF as the driver
- Ignore other QFs (!)
- Make your code change(s)
- Run your acceptance tests for that QF
If you have concerns about potential side effects (e.g. a focus on security may have affected performance), then explore or rerun the tests for this other QF (in this example, performance).
The theory is that as cycle time approaches zero, the risk associated with ignoring secondary QFs also goes to zero.
My recommendation is to try this at home… or at least with an engaged customer.
I’d love to hear your results.