I've worked with many agile teams which have an ever increasing tech debt backlog, where very little effort is ever actually expended to reduce the tech debt backlog. This is why I think that tech debt is actively harmful for a lot of teams, while it's a valid concept how you approach it is crucial to success.

If it feels like your tech debt backlog is ever growing, or that tech debt is never prioritised, or that you have continual repeated production issues, or your developers have low motivation, then you probably have a problem. But most importantly:

If it's not helping your team improve, then it's time to change.

The Problem With Tech Debt

I think tech debt is problematic for a number of reasons. I'm not saying that some of these traits are wide spread, but I've run into most of them in one team or another. More often than not they come from a poor understanding of what tech debt actually is, most people over use this term with little understanding of it's actual definition.

Disagreement On What Is Tech Debt

A team rarely agrees on what tech debt is. Every developer in the team comes with their own experiences and view points and it's often difficult to get consensus on what is actually a problem and what is not. All too often it's simply: I didn't write this code and don't like how it does something. A tech team which cannot agree on whether something is actually an issue, often cast it onto the tech debt pile to avoid dealing with the conflict.

Sowing Division Between Product And Tech

It's sows division between product and tech, by labeling something as being tech specific, when in reality the whole team should be focusing on the same goals. It's not uncommon for tech debt to be dismissed simply because it never came from the product team. Typically the value is only explained in the tech domain, this masks the actual value of the work from the product team.

This us and them labeling often fuels disenfranchisement between the team, when tech feel their issues are never prioritised by product. Further it reinforces that tech do not need to think about the value of their effort and time, if they dislike something.

Delaying And Escalating The Inevitable

Adding stuff to the tech debt pile typically only delays the inevitable and tends to leave small problems to escalate. Invoking the proverbial tunring a mole hill into a mountain. It's very easy to add stuff to the tech debt backlog. Leading to issues that are poorly described and often forgotten by time they are discussed again.

Worse, at extremes this tends to lead of fire fighting, where a team is expending most of their effort just keeping things working rather than actually moving forward, this is often an exceptionally difficult cycle to break out of.

Often The Wrong Solution To The Wrong Problem

Tech debt is regularly used to provide a convenient excuse to both product and tech cutting corners, this is a highly unsustainable pattern to get into. Should you need to deliver features quickly, the team should be having an open and honest discussion on how to go about that, not what corners can be cut now and deferred to later (if ever). A good team will discuss how the scope can be reduced, sliced and phased to deliver high quality features quickly without creating problems for tomorrow.

What Can We Do Instead

Over the years I've tried out a few techniques which can easily be implemented and experimented with. Some of these can be implemented just by the tech team for situations where product and tech are divided. In general they don't require changing your processes, simply reacting to them differently.

The Good Scout Rule

One technique I find that helps teams struggling with a mountain of tech debt is slow and steady improvements. Every time you are working on a feature your goal is to improve the code around what you are working on. The good scout leaves somewhere better than they found it. You will be surprised how fast you can improve and tidy up a system when people take responsibility and get on with it, bit by bit, with small and simple improvements happening consistently. It's better to be part of the solution than the problem.

Clearly there is balance here. I'm not saying that your developers should be spending so much time improving things that it takes 50% longer to build a feature. However there are many times when coding that you can implement a quick refactor which radically improves things. Often it takes little effort to make these changes when you are already in the context and thinking about the code around your feature.

I often hear people counter this approach with: but you should make the smallest change required. Which of course has value, but engineering is about tradeoffs, you need to find the balance between all the constraints which works for your team. A small change does not reduce risk or reduce the testing and deployment efforts. You are also not required to think about the feature in isolation, it might be easier to implement a feature one way now but will make another feature more complex in two weeks time.

This approach can be very powerful, not only can it improve you code base quickly, but also improve your team culture. You are empowering you tech team to take ownership and responsibility for their code base.

Raise Better Tickets

Typically tech debt tickets only explain the problem, solution and value in the tech domain, resulting in the product team being unable to understand the value and reasoning. So rather than raising tech focused tech debt tickets, raise tickets in your normal product format (be it INVEST or Jobs To Be Done, etc). This will force you tech team to explain what needs to be done and what value there is in doing the work. This might seem hard to start with, but with a little practice it gets easier.

This approach will help your tech team to think about the cost and benefit of what they consider to be tech debt. For example switching Javascript framework, just because your not a fan of it, will require some genuine thinking to explain the benefits.

This approach will also help you as a team split down tech debt tickets, just like you would with any other tickets. All to often tech insist these kind of improvements can only be delivered in one go, which is rarely actually true. I'm a big believer that all tech improvements can be delivered incrementally, something it's just takes thought to work out how to go about it. Just because it's tech debt, doesn't mean your teams processes should be skipped.

Agree On What Constitutes Tech Debt

It's important for a team to be able to sit down and have the open conversation between all members about what constitutes tech debt.

This should be run by a tech lead or senior developer who can steer the discussion and reach agreement between the team on what should be considered genuine tech debt. I'd also suggest having your non-tech team members part of the discussion and especially that they understand what the agreement is.

An key outcome should be a set of examples which are tech debt and which are not tech debt, these can be used as benchmarks for the future.