How To Reduce An Existing Technical Debt

As a product manager, delivering as many features as possible on time, under pressure from its users (or sponsors/co-steering member) can often come first, sometimes deprioritizing the code structure. But you are committed to maintaining the quality of your product at a high level, directly influencing your ability to achieve your strategic and business objectives.

In the middle of it all, there is: technical debt.

How to limit the creation of technical debt?

As mentioned above, each software development leads to the production (more or less important) of bugs, choices of architectures and code structures that may generate technical debt.

How does technical debt arise?

The traditional cycle of development of a product source of technical debt

When designing software, the traditional method is an approach based on the phases of feature development:

• First of all, there is the availability of the alpha (often a functional prototype not free from bugs).
• Then that of the beta (approaching a usable version).
• Then the final version (stable version delivered in production).

Each release begins with a phase of building new features, and “ideally” residual issues left over from the latest release are addressed. The ” alpha ” development cycle is reached when each feature is implemented and ready to be tested. The beta appears when enough bugs have been fixed to allow users (often early adopters or internals) to provide feedback.

If you’re working with legacy (Legacy) code, chances are you’ve inherited technical debt. The following points will help you reduce existing debt and allow your team to focus on more challenging tasks. You can also get in touch with Free Debt Advice In London.

1. Prioritize debt

When setting up the Backlog, it is essential not to separate the debt-related tasks (auto tests, bugs, etc.) from the rest of the tasks that provide value (US, epic, etc.).

Prioritize technical debt in sprint planning, as with regular feature development.

We focus here on the part of the table “Reimbursement of the technical debt”:

In general, the PO starts with the tech wins with a high impact but having little complexity, before tackling the part corresponding to the high complexity tasks.
Sometimes, some prefer a mix of the two in order not to demoralize the teams who would not support having sprints with high technical complexity to manage.

2. Establish a quality process

You can then set up a Workflow for correcting major bugs. For example, make a maintenance branch for bugs to be solved in production or put validation steps for bug resolution through a Kanban.

Create automated tests! Nothing protects against bugs better than automated testing and continuous integration. When a new bug is identified, create a new test to reproduce it, then fix it. If this bug reappears later, the automated test set up will detect it. It is a method which allows to keep the quality and the maintenance of the development over the product.

An implementation of tech KPIs (code coverage, duplication, vulnerability, etc.) to be taken into account and challenged by the developer team or the architect in order to measure the quality of the code and have a view of the evolution of the technical debt.

3. Attack the debt

As a Product Owner you must combine debt control and development of new features. You know that the time invested in an architecture and clean code will save time later. You must also adopt this state of mind to your team. So that it corrects precise and defined perimeters by iteration rather than a whole sprint of refactoring.

On existing debt, I tend to categorize my product backlog for more visibility, it allows to identify the state of health of my product (a backlog with 85% of technical story grouping debt and bugs of all kinds  is never a good sign, it also impacts the morale of the teams) .

With two priority issues:

• Remotivate the teams.
• Re-add value to the product and cut the endless cycle of refacto.

To start attacking this one I started on sprints with 40% new features and 60% debt reduction. It can be a good compromise, on the one hand to motivate the teams again. On the other hand to bring a beginning of social peace with stakeholders by providing features with high added value.
We continue with the iterations with the objective of reversing the trends: 60% new features and 40% debt to be processed. This will be a strong signal announcing a gradual improvement in the state of health of your product.

4. Educate your teams as well as decision-makers

Not defining a Key Performance Indicator  means having no argument to put forward to decision-makers when setting up processes that can reduce the debt, or even no visibility on the debt in question.

To address this, educate the product manager on the true cost of technical debt and the need to resolve it:

• The implementation of visual management to highlight the risks associated with the product and square the “voluntary” debt so as not to forget it.
• Achieve synchronization points on the evolution of the debt.

Technical debt quadrant

In short, anything that brings visibility on the technical debt is a welcome source and will make it possible to anticipate the next actions to be taken.

As for the teams, the bulk of the game is played during recruitment, favor Craftsman profiles oriented towards continuous improvement and having a good command of agile methods (Pair programming, Moob programming, eXtreme Quotation, etc.).

Managing technical debt is part of responsible long-term investing. You won’t be able to completely avoid it, but there are many solutions to reduce it and set up a sustainable ecosystem. The most important thing will therefore be to anticipate by keeping an eye on it and educating your team so that it doesn’t go into an endless spiral.

The main thing to remember:

The PO must keep an eye on the technical debt and be the guarantor of the quality of his product.

To limit the debt:

• He must set up processes guaranteeing this quality ( definition of done, bug correction workflow ).
• Have the possibility to validate or not the delivery of his product.

On existing technical debt:

• Prioritize your technical debt before attacking it and gradually reducing it .
• Don’t spend an entire sprint on debt reduction .
• Thinking about a high-performance team through Craftsman profiles .
• Make this debt visible through visual management and KPIs .