What is Tech Debt?
Technical debt is a set of decisions that were made in the past, that you want to change now. These decisions can be related to architecture, software design, infrastructure or even some of the code you wrote.
You may have made them intentionally deciding to deal with consequences later. We've all been in a situation when we need to get something out of the door quickly but then come back later to fix it. Or it may have happened unintentionally, for example out of lack of knowledge in a new area or lack of experience with a specific subject.
One of the aspects of scaling is that companies sometimes run into technical debt. When companies grow, in addition to organisational challenges they face technical ones too. Technical challenges come in different shapes and forms, like issues with scalability, ageing infrastructure, and stuff like that.
Accumulating technical debt is very dangerous, because over time it tends to have negative effect on a team - slower change cycles, harder to make changes, fragile areas of the code, etc. This leads to the situation that the estimates are being gradually increased and noticeably fewer tasks are performed during the sprint.
How to pay off technical debt?
There are two different ways to pay off technical debt:
Regular Roadmap work
When working on MVP of Order Management System we've decided to cut some corners. As soon as you plan to work on tech debt items you incorporate this work as part of the upcoming areas or milestones of work. But then come back later when doing the next chunk of work related to this area.
If you see there's an area of the code that developers are trying to avoid to touch or afraid to change at all - to me that's a big red sign of tech debt. However, even if there's no item on the roadmap associated to that area it may still be well worth the investment to improve that piece. So that it's easy to make the change when you need it. And you don't have developers that are afraid to touch it.
In either case, technical debt items must be logged into the backlog, reviewed and prioritized just like any other ticket, of course with input from the dev team!
Tech Debt reduction must be part of your process. Remember that your resources are limited. Accumulation of technical debt needs to be under your control so that it does not become an obstacle for your team in the future delaying releases and causing a "tribal knowledge" effect.