In a broad sense ‘Quality’ is when an organisation can take its product(s) to the market as quickly as possible with minimal investments by giving the customer the best possible experience. However what it means specifically, differs across each organisation, product, and even within teams. If this is the case, how can we empirically measure quality which is subjective?
Most organisations maintain a set of metrics that indicate if they are running successfully and serving their users' needs. To measure something is easy but understanding what to measure is often tricky. Measuring something that is not relevant to the quality of the product and user satisfaction might mislead our view of the product. This is where most of the anti-patterns emerge.
Moreover, we can think of quality along two axes. One is the Quality of the Product; while the other is the Quality of Processes that lead to the development of the product.
Both of these axes will ultimately be assessed by the end user, as a high quality product cannot be produced by a team that has low quality processes. A successful product team is one that can balance the Quality of the Product with the Quality of Processes.
Often organisations and product teams have a notion if the product they are building is of a good quality. On deeper questioning about how they measure quality, people quote metrics such as number of automated tests, or production defects. These are definitely useful but do not indicate the value gained by the customer or the end user.
Thus understanding user needs before building the product and then observing if those needs are being met is a suggested way of measuring quality.
Thus, measuring the following parameters could provide a better view of the quality of product:
User feedback: Organisations that act on user feedback produce a product that caters to specific user needs. This in turn creates a sense that the product is of good quality as it solves user problems in the best way possible
Active users for time: Measuring active users of the product over a period of time (monthly, quarterly etc) is a good indication if the product is catering to user needs
Market share of the product: Products that solve user needs are normally perceived as high quality products and have a leading share of the market in their segment
All organisations have a process that takes an idea and converts it to working software, however chaotic and non-documented it might be. The process ideally should give sufficient autonomy to the people working through it making people feel valued which in turn increases team morale. Such a team will produce a high quality product. Some metrics related to process are:
Time to market: Product development process should be continuously optimised, such that the time taken between when an idea is generated by the business to the time an end user gets the value of using a feature is as minimal as possible, balancing the Quality of the product
Time to fix a defect: Development processes should be set-up such that teams catch a fault in the application before the users discover it. Once set, the process should be robust enough to identify the defect, fix and deploy the changes to the user in the least amount of time possible
Team happiness index: By providing autonomy for technological decisions, creating opportunities for learning and development and relaying the purpose will give the teams a sense of success. Such a team will have less attrition, and generally produce good quality products
Thus, higher quality processes lead to a higher quality product. This results in a flywheel that pushes the product to be better which in turn pushes the process to get better.
There might be other factors that you may be considering to measure the Quality based on your situation at hand. Please look out for a blog in which we talk about why some of the other common metrics may not always give you a true representation of Quality.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.