In this case study, I want to share a few of the strategies we use to help companies pay down technical debt.

The overall concern is that if a customer has dozens of developers, it quickly becomes impossible to pay down technical debt via a single team. The amount of tech debt accumulated and accrued weekly can easily pass the amount of tech debt repaid by a smaller group.

Firstly, accumulating and paying down debt have asymmetrical costs. In many cases, teams accumulate debt as shortcuts to work faster when they are pressured. Repaying that debt means doing things by the book, and this takes more time than adding.

Secondly, technical debt has a compound interest. As more layers of debt are added over layers of debt, it becomes exponentially harder to pay back -- to the point that sometimes it's better to dump everything and rewrite.

For this reason, the first important lesson in repaying tech debt is to enable and train the teams to pay it back themselves, not do it for them.

Lower the cost of fixing something

Making work cycles faster -- for example, by having multifunctional teams that can deliver continuously -- lowers the cost of refactoring and bug fixing. It allows well-meaning developers to make small incremental "drive-by" improvements and push them quickly to production. This trickle of debt repayment might not sound like much, but it makes a big difference over the weeks, months, and years.

Make tech debt visible

It is widespread for tech debt to become a "skeleton in the closet" for the teams. The weird uncle Bob that no one mentions at family meetings. If we want to help Bob, we need to talk about them. There needs to be a space where it's safe and expected to speak bluntly about code issues so that the company feels free to talk about these topics. Creating a Refactoring guild is an excellent way to promote this kind of place.

Keep track of debt

Talking about tech debt enables us to find it, but how do we expand this knowledge's visibility to the rest of the department? An easy way is to create tech debt lists, make them available to everyone and most importantly make them evident.

One way we've done this in the past is by having a bot report on GitHub or slack the current status of tech debt, showing progress over months, and creating lists where people could "book off" items to solved and be recognized for it.

It might sound cheesy to do so, but in reality, the message we want to convey is that it's expected for everyone to fix the debt and that the contribution is not only allowed and expected but also valued.

We promote tech debt repayment as a positive activity.

Cooperate with Product Owners

The first reaction of POs to having to pay down technical debt is, invariably, one of worry for the team's overall velocity. In reality, it's useful to talk about refactoring with them, and a large part of this impression is not, in fact, based on reality.

First of all, repaying tech debt is part of development. It is, in other words, a routine activity that teams do. It should be clear that taking shortcuts is not the correct and expected way to write software. In Product Owner terms, the velocity a team could have by doing that is not the team's velocity at all because they are borrowing velocity from the next sprints.

Secondly, the effect of paying down debt, and its primary motivator, is to make teams faster and not slower. Product Owners complain that teams cannot pay down debt because they are not delivering? We should calmly explain to them that the reason they are underperforming in the first place is usually the technical debt they are not willing to pay down!

Of course, this is not to say that we should drop all that we are doing and fail sprints all over the place because of paying down tech debt. There must be a compromise between technical debt stories and product stories that will keep us on track. On the other hand, all product backlog items -- as a matter of definition of done -- must make enough effort not to leave any debt behind by taking shortcuts.

Does this work?

Let me present the case of about 12 months of this approach and its results, applied to one of our customers.

• Total number of projects: -58%
• Number of solutions: -81%
• Total Lines of code: -29%
• Master pages (a part that had a lot of code duplication which we aimed to fix): -36%

‍