What is technical debt in Agile – definition, examples & how to deal with it

Examples of technical debt

1. A small business website during a growth stage

This is probably the most common way to accumulate tech debt. Small businesses have tight website budgets. If they rely on the online presence, this can quickly catch up with them during the growth stage.

It’s especially common during periods of insane growth that require you to add features on top of the old solution. The first, budget website is something companies get before they really know what they need. As such, it might be full of features built on a hunch and places where developers had to cut corners to fit within the budget.

Building on these shaky foundations when time is of the essence leads to cutting even more corners. Growth can’t just wait until you’ve fixed the old issues – the new features need to be done, almost at all cost, and that’s how technical debt typically starts.

2. After changing the agency

Quality of the code is another reason technical debt might creep up. It can feel a bit discouraging, especially when you make a step up to a developer or an agency that have higher standards. Why?

Most of the time, with higher standards comes higher price. Technical debt amassed by the previous contractor could appear very costly to pay off and you might decide to ignore it. But we know from the first example that this can spiral out of control.

3. Insufficient testing

We’ve all been there. A change makes it to the live site and something is broken. Nobody likes this, but it happens. Some code changes are so vast that it’s hard to catch everything. We employ both manual & automated checks to test that, but things slip by every now and then.

Especially when the site already struggles with some technical debt. But even in a debt-free scenario, you can launch a feature with a bug that will go completely unnoticed. The next time you build something on top of it, this will escalate like in the first example once again.

What causes technical debt in agile

Development teams encounter technical debt for several reasons, both internal and external:

• Fixed deadlines
• Lack of planning
• Lack of communication and alignment
• Lack of skills: developers without domain knowledge, insufficient automation, lack of QA and testing (i.e. test-driven development), etc.
• Neglecting quality: cutting corners on code reviews, letting bad code into production (e.g., “it works on my machine”), lack of automated tests or other forms of verification/validation (e.g., static analysis).
• Poorly defined requirements: vague descriptions in user stories with no acceptance criteria, feature branches that are never merged because they’re not ready yet, unclear acceptance criteria for MVPs, incorrect assumptions about the architecture needed to support new features, etc.

In short, technical debt is any component that detracts from the value proposition delivered by an agile software project—and there are plenty out there!

How to deal with technical debt in scrum

Everything we do affects technical debt and we should be aware of the impact. Throughout every sprint, we need to know how much refactoring has been done and how much more is necessary. This can be measured by tracking hours spent on refactoring and the size of user stories in the backlog compared to the agile team’s velocity.

We need to plan for paying off technical debt in every sprint. It’s impossible to know the exact consequences of each change until it’s implemented. You still have an idea of what needs to happen down the road. This ensures that when problems arise, they don’t derail your team’s progress.

Ultimately, everything comes down to transparency. If the development team is honest about technical debt and acknowledges it, you will naturally incorporate tech debt into the sprint backlog. Bonus points if you can communicate and prioritise technical debt during sprint reviews!

Technical debt can be a good thing…

While technical debt is a useful tool, it must be managed carefully. If left to grow unchecked, it can have a negative impact on the team, product and business.

Technical debt can be managed by paying it down with refactoring. By doing this, you’ll improve the codebase while reducing technical debt at the same time!

In conclusion, technical debt can have its merits as it may save a lot of time. It can help land a critical customer when the product is released early or achieve cost savings that can be invested elsewhere. – as long as we keep its existence in the back of our heads and allocate time to deal with it in the (near) future!

Have you encountered technical debts at the businesses you’ve worked for? Tell me all about it in the comments.