In software development, the term quality
has always been an area of concern and a point of active discussion. Because customers are the entity around which an organization's business strategy grows, they are considered the driving force that defines quality. This approach basically keeps you focused on "what customers need," which is also the backbone of most of the Agile development methods. Studies show that Agile methods have been more successful when they address the customers' demands and timely delivery.
For organizations that are involved in software product development, the approach toward quality has to be considered in a broader sense. The problem is in how we define quality. Quality is not a single parameter but a multidimensional concept. Depending on a particular scenario, quality involves various areas of interest and the viewpoints and attributes for that area. Its definition stems from the concept of conformance to a customer’s expectations and requirements. The Agile methods also support this definition in a big way.
Agile methods help development improve its product by aggregating and tracking product and process problems, customer complaints, and enhancement requests. When product deficiencies are reported and investigated, one can capture all the key findings for different work areas across development. Agile methods provide a robust decision-support platform that involves all stakeholders and their multidimensional analysis. But is that what we perceive as Overall Quality Management (OQM)? OQM is perceived in various ways, depending on how it is interpreted and applied in the individual field.
Overall quality management
In general, OQM represents the way management aims to achieve long-term success, linking quality with the customer’s satisfaction. Apart from focusing on the actual needs of customers and delivering on these needs, it would also include the organizational factors, such as long-term sustainability of performance, quality of work, and the maintainability of the product source.
Unlike a project, a well-established product has a long life span in the market. During this time, several new features are added, enhanced, or removed from the product. Moreover, as technologies change, the same product has to align itself with the speed of global technology changes and keep itself up to date. In such scenarios, apart from satisfying a customer’s expectations, consistency and efficiency also are added in the overall quality of the product.
The Agile method makes sure that you develop what will be used by the customer. It also helps to cope with the inevitable changes to the requirements. But what factors ensure that the way the team is performing today is efficient enough and that they will be able to perform in this way consistently in the long run? Agile practices are mainly designed to quickly react to changes, but how do we ensure that while responding to changes, our quality of work, efficiency, and consistency are intact and are not affected?
This requires that we clearly define quality concerns. It also requires that we build a culture in which all stakeholders in product development actively participate not only in meeting the customer needs but also the continuous improvement of all processes linked to product development. The main challenge lies in how efficiently we capture the findings in different process areas during product development. We translate these findings and make them visible to the team, enabling it to prioritize development needs as well as assess the reliability of the next-generation products. Such analysis provides engineering teams with the information they need to continuously improve the product. Hence, the quality must be clearly defined, measured, and made visible to the team for continuous improvement.
Selecting problem areas
The driving factor (fm) behind managing overall quality is the capability to pinpoint those areas that need improvement and providing visibility to the improvement progress from one cycle to the next.
One should be able to choose the areas that dominate the final outcome. The main point here is to know the observation density for each factor; you are not required to know their severity in terms of High/ Medium/Low. Agile methods are timeboxed activities. Therefore, for each sprint or timebox, record the observations and calculate the observation densities for each factor in the chosen area.
Each cycle may have N
number of user stories to develop. Organizational development (OD) for a factor in a particular cycle is:
To further simplify, we can represent them as a trend analysis graph. At the end of each sprint, the graph will display the total quality progress of the team and will provide appropriate indications for improvements in future cycles.
Given this approach, we chose to monitor the overall quality in our work in several areas. Two of the areas are illustrated through an example:
- Development process (A1)
- Testing process (A2)
By following common coding guidelines and design principles during development, a great impact is made on product maintenance in the long run. These standards are decided on and then reviewed. They influence both code maintenance and product performance. This was an important area that required high maintenance because team members, especially new ones, could easily introduce mistakes.
Testing was another area that required proactive and innovative ideas from testers. The idea was to not just test the work but to explore its surrounding. Regression problem, improvement suggestions, and alternatives were stressed in order to improve on the overall quality of the work.
The following table highlights the factors we chose to observe in two major process areas.
The table below cites an example of observation density of each factor in an individual area. The observations can be considered as indicative data for the sprints in one release cycle.
And the graphs below are the trend chart to provide quick view of team’s position in terms of quality concerns.
The approach discussed here is not about collecting data and producing various software matrices. Rather, it is to plot the observations collected on the work, grouping them in predefined categories to indicate where the team is not doing well, and where it needs to improve.
Striving for continuous improvement is one of the strongest essences of Lean adaptability. The team does not have to do any detailed causal analysis. Instead, the indications are passed to the team as feedback, and the team is empowered to take appropriate steps for improvement. This has been in accordance with Agile practices of self-managed and self-empowered teams. This approach can easily be embedded into the Agile development practice.