The Myth of Quality vs Quantity in Software

One of my favourite Agile parables tells the story of an art teacher who gave her students an assignment to produce a ceramic vase. The class was divided into two groups, the first group need only produce a single vase, but they were to be assessed on the quality of that one piece of artwork. The second group had to produce as many vases as possible; they would be assessed on the quantity of work they submitted. At the end assignment, when the teacher ranked all of the vases, it was the second group (the quantity group) that had also produced the highest quality vases.

Depending upon the organisation, and how far along they are in their “Agile Journey”, it can be difficult to win support for this sort of approach – yet it is one of the key insights provided by Agile. 

All teams need to figure out their definition of “done”, and it’s going to vary, not just from product to product, but also with where you are in the lifecycle of a product. If your software has a strong consumer emphasis, you might decide early in the project to focus on pixels and UX. If the core requirements are around analytics or data, you might decide to focus on getting the numbers right. In all cases you will fail to deliver if your definition of done for a single iteration is perfection across all areas.

Of course, once you choose a definition of done that is less than perfection, you will deal with criticism from people that don’t really get Agile. “This approach is good for rapid prototyping, but it won’t produce quality”. The most important thing is to take that feedback, the bugs, the kludgy UX or whatever the criticism is, make sure it’s backlogged and prioritised, and wherever possible ensure you have an automated test that can reproduce the fault. Don’t slow down, don’t worry that maybe this Agile stuff is wrong. The quantity trajectory will inevitably give you the best quality as well.