In the last post, I introduced you to the concept of Quality Debt as an alternate way to think about Technical Debt from the perspective of the discipline of Software Quality Assurance. Through the application of three simple but powerful quality metrics, I proposed the use of four tangible and actionable objects as deliverables, relative to the processes from where those metrics are collected: the defect log, new requirements or new backlog items, augmented test ware and the quality effort gap report.
As the creation of software is today (but perhaps not for much longer, see Chat GPT and Github’s Copilot) a very human-dependent process, Technical and Quality debts may not entirely be avoided. Nevertheless, there are still things that teams can do to help reduce the acquisition of such debt.
In his 2020 post Luca Rossi reflected on the matter of reducing Technical Debt from the perspective of a software developer. In this post, I’m going to board the issue from the perspective of the whole team, stakeholders included.
Balance your books
As with any type of debt, it must first be recognized and accounted for; to do so, perhaps the first and most crucial step is to formally define and implement within your team the four actionable items described in the last post: The defect Log, the new requirements or backlog items, the augmented testware and the quality effort gap report. You should have little or no problem at all as they are very well-defined concepts in the Software Engineering discipline for any SDLC type you find yourself into.
The next step is to use those items to estimate your actual debt either in team effort (man hours) or cost (financial resources). For example, you can calculate the “delta” (difference) between your original backlog versus latest items plus the number of critical defects (from the Defect log) that need immediate fixing and how much time and personnel it will need. You can also account for the execution of any additional test, its conversion into automated scripts (augmented testware) and even the time needed to execute (totally or partially) the skipped tests (that’s the quality effort gap)
Make your payment plan
Once estimated you can incorporate your quality debt into your current project plan as a way of “refinancing” it, and thus re-estimating your project. You could also decide to “defer its payment” and consequently paying a compound interest on it through time. This method is the most quantitative, but there are other ways to reduce the incursion into Quality Debt, I will mention three of the most common:
- Involve all your team: Switching to a quality centric and holistic approach to software development is an effective way to get all roles involved (Devs, QAs, Scrum Masters, Product Owners, Business Analysts, DevOps, DataOps, so on and so forth) to embrace quality as an intrinsic part of the project’s culture. For example, Shift Left Testing (test early and often) enforces the notion that all the team is responsible for the quality of any outcome of the project (not just code, but documentation, user experience, performance, etc.) and it makes them aware of its implications all the way from the inception, architecture design to its deployment in production (regardless the SDLC being waterfall, agile or a hybrid).
- Empower your QAs: Give your Quality Engineers the confidence to speak out their minds, question everything and communicate horizontally. Respect their effort estimation for testing (as much as you respect other stages such as design, development and UX) and allow them to craft they wizardly tricks (i.e., as risk-based testing techniques, the creation of test ware related artifacts and metrics, perform exploratory testing sessions and automate test data management or increase automation coverage). When this effort is properly applied it will prove worth the awkwardness and apparently “unproductive” nature of such tasks.
- Formalize and evangelize your quality approach: If you don’t have a well-defined quality process that is intrinsically assumed by your team It may be hard or even absurd to ask others to embrace it. Once a team is riding a holistic quality-centric “wave”, they’ll advocate for it, and others will see how “cool” (as in useful, transparent, beneficial, and awesome) it is and they will follow. Some quality processes that can serve as key communication topics, which may be appealing for others, are in-sprint defect budget, prioritizing the increment of test automation coverage, and periodic meetings for reprioritizing issues.
Thinking about software technical debt from the perspective of software quality gives teams a more tangible way to understand it, measure it and grasp its implications over various aspects of the project and it helps everyone involved (not just the developers or QAs) to team up over a common ground and find creative ways to overcome it.
In the text post I will dig a little deeper into the defect log, introducing some defect-related metrics and introduce some ways to manage it and even proactively dealing with it.
