Product Managers and Product Owners face a constant challenge of balancing priorities.  New features or technical debt elimination?  Or both?  There are dozens of answers and strategies to address this challenge.  Google only lists 26,100,000 results to help you out.

The priorities between feature creation and technical debt elimination change as a product moves through its’ evolution.  When you are building your Minimum Viable Product (MVP) feature velocity is the top priority.  Avoiding adding more technical debt is a nice to have.  When you are approaching market parity technical debt takes on a slightly more important priority.  When you are focusing on implementing true points of difference (the features that are important to your prospects and not available from your competitors) once again feature velocity takes precedence over technical debt.  FYI check out Chris Goward’s excellent post “Use these 3 points to create an awesome value proposition” to understand the difference between points of parity, points of difference, and points of irrelevancy.

Once your solution has reached a state of relative maturity, like being in the latter stages of the early majority phase of the technology adoption life cycle or even the early late majority, your priorities regarding technical debt need to shift.  Unfortunately what often happens is that a major production outage occurs that brings the technical debt crisis to a head.  One time in my career I was pressed into the position of being the acting head of network operations while I was also running a large customer service organization.  Our next generation solution, which had been launched about a year earlier, suffered a major outage.  We managed to shutdown production at several automobile assembly plants among other things.  It was a painful process to rectify the outage and we took a major hit in the marketplace and in customer satisfaction.  Fortunately my organization recognized the root causes that contributed to this and other outages.  They took proactive steps to bring in new leadership and make significant investments to eliminate single points of failure in our operations that included hardware, software, and people.

You should work on your technical debt mitigation plan before you suffer a catastrophic outage.  Christiaan Verwijs wrote an excellent piece on How to deal with Technical Debt in Scrum.  You should definitely read the entire post.  I will extract some key points below:

Some strategies and tactics to consider include:

Use powerful metaphors

‘Technical debt’ is a powerful metaphor. Use it as such. The consequences of writing hacks & workarounds to ‘help us now, but hurt us later’ are very abstract and incomprehensible for people who are not developers themselves.  The following chart is an excellent metaphor for managing technical debt:

Take responsibility as Developers

Some Development Teams feel victim to the way that ‘the business’ keeps prioritizing new features over improving the codebase, while on the other hand holding them responsible for bugs, broken code and the results of technical debt. The Development Team can do no right.

An important step is to stop acting like a victim. Take responsibility for (maintaining or improving) code quality as a team. This is not coincidentally heavily emphasized by the Scrum Guide.

Use Code Metrics to quantify Technical Debt

Metrics offer a wonderful opportunity to make something subjective and abstract more objective and tangible. It also gives you a measurable goal to improve towards.  SonarQube is one tool you can use to help with technical debt metrics.

Make Technical Debt transparent on the Product Backlog

Finally, but most importantly, make technical debt transparent. Don’t hide it from the Product Owner or the broader organization. Identify specific improvements, estimate them and suggest them for inclusion on the Product Backlog. Treat them as a regular item for the Product Backlog; break down large items as needed and prioritize them with the Product Owner. This helps the Product Owner make a conscious decision about how to deal with technical debt.

Summary

Technical debt is like an iceberg – most people only see what is above the water.  What is below the water can kill your team’s productivity and effectiveness.  Martin Folwer is considered to be the king of technical debt.  His technical debt quadrant was the seminal piece of work on the topic.  You can check it out here.