Managing technical debt in an agile environment

Ah, technical debt: the topic that always needs to be addressed, but never seems to make it into the roadmap. Whether it’s inadequate testing, a bug fix that has somehow become a permanent fixture, or infrastructure that requires version upgrades, we all know the presence of technical debt can significantly affect project timelines, quality, and team morale.

When a company grows, a lot of these technical debt items can really come to light. For (a real life) example, you may skip server side pagination at the outset to save time so you can get a proof of concept out and into the hands of customers for beta feedback. Well, they like what you built and begin to use it. A lot. And all of a sudden you’re attempting to load thousands of something on page load. Which… as you can imagine, is painful for customers to wait and painful for the engineering team to see.

Ignoring technical debt can lead to missed deadlines and a decline in product quality. Additionally, technical debt can demotivate your team, as they may feel they are constantly dealing with old problems instead of building new features. I realize I’m preaching to the choir here (I don’t think I need to convince engineers of the issues technical debt brings), so if you’re in Product Management, consider this section for you. :)

So how exactly do we balance technical debt with feature development? One of the biggest challenges in managing technical debt is balancing it with the need to develop new features. To prioritize effectively, teams need methods for assessing the urgency and impact of technical debt. I actually wrote about this topic in a previous newsletter, explaining how to reframe technical debt to prove customer value as a way of getting it incorporated into the roadmap. Aside from the reframing conversation, the other part of this conversation is how to break up technical debt to schedule it into an agile-like environment.