Technical debt is a product development issue that is quite elusive because it’s created passively. It often creeps into the organization over time and flies under the radar. Keeping it at bay is a joint effort and it shouldn’t be a sole preoccupation of the Development Team.
Product Owners, in particular, are well-positioned and equipped to tackle this issue head-on. After all, they are tasked with maximizing available resources and facilitating various key processes.
The Risk of Cutting Corners
Technical debt is also known as code or design debt.
It’s a measure of costs that stem from additional rework. This type of problem tends to occur when organizations opt for easy solutions instead of better (albeit more demanding) ones. You can think of it as shortcuts you can get away with until it all eventually backfires.
Years of industry practice reveal that a certain amount of technical debt always exists. In a way, it’s a byproduct of accomplishing your business goals and higher agility over a long haul.
Just because you don’t feel the clear impact, doesn’t mean you’re in the clear.
In fact, things could easily spiral out of control, as the debt compounds and one quick fix builds on another. This can hamper your productivity, and stifle the development process. This situation makes it harder to focus on crafting those valuable features and maintain product quality.
Tools of the Trade
Product Owner is charged with managing the Product Backlog.
This artifact is precisely where one can detect and do away with debt. For instance, during Sprint Planning, Product Owner opens the discussion of Backlog Items that are supposed to forward Sprint Goals.
According to findings that surface in this event, the team selects the items or adds new ones. In case members decide to rework the Definition of Done, that warrants rework of previous increments. It’s at that point at which the technical debt may become self-evident.
Beyond this glaring example, there’s much Product Owner can do proactively in order to minimize technical debt.
One proven practice is to regularly gather feedback and insights from the development team. Its members are closest to the actual work process and bound to have some valuable info. Transparency, which is right at the core of Agile, helps you shed light on the issue of debt.
To be more precise, transparency must work hand in hand with two other pillars. We’re talking about collaboration and team self-organization. It’s their synergy that provides a system of checks and balances needed to smoothly deploy projects.
So, make the most of events such as the aforementioned Sprint Planning, as well as Sprint Reviews. Openly talk about further development steps, quality standards, and technical implications. All stakeholders should have direct insight into the state of the codebase and the application.
The Numbers Game
Furthermore, it’s of paramount importance to employ the right metrics to assess how bad the debt situation is.
First off, take into account the total costs of developing a product and put them against projected and current revenue. Large technical debt inflates the expenditure side, which should be seen as a red flag.
Likewise, investigate the amount of resources you may have to spend putting the finishing touches to the product. This usually takes place between the moment developers announce the completion and the moment release happens. Ideally, you quickly realize what went wrong with design/code and don’t have to invest much in fixing it.
Defects and faults refer to anything that makes the product less valuable to end-users. It can also be a deficiency that prevents the software from working as advertised.
Now, if you have significant technical debt, the stabilization period stretches on. In other words, the less efficient the fixing process is, the more debt you stockpiled. Sometimes, this menace can derail the whole project.
For Good Measure
There are also some purely technical means of evaluating technical debt within an organization.
Essentially, you need to determine what kind of calculation makes the most sense in your specific context. We would recommend focusing on consumer-oriented and code metrics. The latter come in the form of code coverage, SQALE-rating, rule violations, and cyclomatic complexity.
Whatever you choose to do, you should avoid having a tunnel vision. You’re better off following multiple metrics and never jumping to conclusions prematurely. Learn to interpret the empirical findings and do necessary course-correction based on them.
Notice it’s always a good idea to pay off the debt at regular intervals, which is to say in each sprint. An early warning system helps you with this task, as well as to smartly allocate a portion of team capacity to bug fixing and refactoring.
Prioritize long-term value over shiny new features that bring short-term avail. Make sure the order of Backlog items reflects this approach and don’t do Scrum “shadow accounting”. Align product vision with realities of day-to-day grind reconcile quality standard with the Definition of Done.
Finally, adapt your approach on the fly whenever practical insights call for such a thing. Never succumb to the temptation of taking the line of least resistance. It does more harm than good, as you sink deeper into the debt trap.