Considering Continuous Improvement in Software Quality

By: Ernest Toh

Despite many companies knowing the importance of continuously seeking improvement in their software (including fixing bugs), how many are exactly doing so? Today, customers are more demanding. They are demanding more features in a shorter timeframe so that they are able to meet the demand of their customer. For example, in the world of mobile phones, most consumers are always expecting new features to be launched in every new OS update. Companies are struggling to deliver new features in the market against bug fixing so as to stay competitive in the market.

According to Herb Krasner as mentioned in ‘The Cost of Poor Quality Software in the US: A 2018 Report’ published by Consortium for IT Software Quality, the cost of poor quality software in the US in 2018 is approximately $2.84 trillion.

In this article, we are not going to discuss quality management. However, it is important to understand the definition of quality, i.e. the definition of quality to every individual organization. There are many versions and best practices that define Quality. The American Society for Quality (ASQ) defines fitness for use, conformance to requirements, and the pursuit of excellence.

Organizations need to define their own definitions of quality; do a benchmark of current state, introducing metrics to measure before and after. Organizations need to define a purpose, cause and this sets the reason why the organization exists. This is the core of what sets an organization apart and defines their products and services.

We have seen the cost of the poor quality software. And we know that it is important to continuously seek for improvement in software quality. But how much is effort and time should a company be investing to improve in the software quality? Should a company be looking at 70% of the time and resources to be allocated to develop new features and 30% of the time and resources to be allocated in bug fixing. Or should it be an 80/20 rule? There is no one size fits all solution. Organizations need to understand their capability and what their end goal is.

No matter whether it is 70/30 or 80/20, it is important that continuous improvement should be part of the ongoing process within the organization. There are many tools and best practises in the market that provide great information on how to work on improvement. This includes Kaizen, DMAIC, PDCA. No matter what best practises an organization is adopting, it is important to know that there are many factors that potentially affect the outcome. There are elements that are observable and there are elements that are non-observable. Take a look at this iceberg to see what I mean.

According to Peter Drucker: “Culture eats strategy for breakfast”. And, according to Sascha Bates: “Tools and processes are a reflection of your cultural choices.” We see how important culture affects the outcome of the software delivery. When any organization introduces changes as part of the continuous improvement, it is notable that people go through different stages of feelings. In 1969, Kubler-Ross described five stages of grief in her book ‘On Death And Dying’. All these five stages describe how a person will react during changes. This helps any organization to be able to manage the human side of the change.

To embark on a continuous improvement process, organizations should define and communicate what is the value that they are delivering to their customer. ITIL V4 defines value as the perceived benefits, usefulness, and importance of something. According to the DevOps Foundation course by DevOps Institute, time to value is replacing time to market.

Organizations need to move fast to deliver value to their customer. ITIL V4 highlighted the importance of co-creating value between suppliers and customers. This is especially important in the customer journey. In an article ‘Are You Undervaluing Your Customers?’ by Rob Markey, Rob shared his research that shows that loyalty leaders — companies at the top of their industries in Net Promoter Scores or satisfaction rankings for three or more years — grow revenues roughly 2.5 times as fast as their industry peers.

So now the next question is, who owns the continuous improvement process within an organization? Who owns the Jira dashboard and who is accountable for the quality of the software? Should it be the development team or should it be the operations team within an organization to own the software quality?

According to the ‘2020 Upskilling: Enterprise DevOps Skills Report’ published by the DevOps Institute (DOI), research shows that there is a mixture of DevOps topologies used by organizations today. According to the report, DOI highlighted the three main models currently used: DevOps team silo, DevOps collaboration model, DevOps tool team (where the DevOps team is responsible for tooling required). The report further commented that the second model (DevOps collaboration model) is probably the most challenging but most rewarding approach.

Organizations should consider breaking down silos and look into collaboration between the development team and the operations team should they wish to maximize the reward.

Is continuous improvement necessary? The answer probably depends on what the company’s belief is. What is the value that the organization is delivering to their customer. In today’s highly demanding market, organizations should continuously ask themselves what are the most important reasons why they exist. Continuously improving on their software quality has become an important factor to stay competitive.

At the end of the day, customers are looking at the outcome more than a product and time-to-value (delivering a quality software to meet the Customer needs) has become more important than time-to-market (delivering something new to the market).

Where does your company stand today? And what is your company’s definition of value?

DevOps Institute is dedicated to advancing the human elements of DevOps success through the SKIL Framework: Skills, Knowledge, Ideas, and Learning. Learn more.

This blog was originally posted on DevOpsInstitute.com.