I came across an e-book written by Eric Van Veenendaal, in which he has shared Dr. David Garvin’s framework on how to define Product Quality. It’s a very useful e-book for anyone who is interested in exploring Product Quality, and specifically Software Quality in Agile context.
Eric quotes a KPMG report that stated that ‘improper testing’ is the reason for bad quality. Eric also explains how Software Quality is still a challenge in the Agile environments, in spite of the 12 points in the Agile manifesto each individually addressing Software Quality. Eric also says that Dr. Garvin’s framework has to be applied on a blended basis to come up with concrete objectives that could be quantified and measured, to achieve superior quality.
It’s a great recommendation, and I agree that there’s a lot of value in it. Yet, practical implementation considerations often cloud the effective implementation of the framework, and they should be addressed. These are some of the challenges that I have seen:
1. Not everyone in the team understands the product thoroughly. This could be because, communication, which is the vital nerve in the Agile environment does not happen as expected. Also, misunderstanding ‘working software over comprehensive documentation‘ as ‘no documentation’ leads to team members having no reference points on how the software works, and what is the current software architecture. This can be addressed by solutions like Structurizr.
2. Agile is misunderstood as just speedy and constant delivery of features, as against the value the deliveries provide to the end-customer. Balance between delivery and value should be obtained.
3. Testing is overlooked in many aspects. Proper thought process of Software Testing has been cornered into something called ‘Exploratory Testing‘, and a few hours are allocated for it. Instead to taking automation’s help in Test orchestration, automation is considered prime (because it can be integrated in the CI/CD pipeline) and human thought process in Testing is considered wasteful and negligible. This should be clearly addressed. This could also be the reason for the ‘Improper testing’ quoted in the KPMG note mentioned in the above e-book.
4. Finally, as Eric stated, the 5 facets of product quality mentioned by Dr. Garvin are not looked into, and the framework that’s appropriate for the product is not designed. This leads to bad product development including bad testing. Efforts should be made to come up with a balanced framework that addreses as the 5 facets.
Big thanks to Eric for writing this e-book on Quality in Agile Context!
I would be be glad to provide customized Quality solutions for your product based on your needs. You could contact me through the Contact form.