Technical Debt is a crisis in the IT profession. As a consultant, nearly every client I work with has a pile of accumulated issues to address. It’s like building a house of cards – eventually, something will give, and the whole thing will collapse.
So, how should Scrum Teams dig out of their Technical Debt? Let me share a few ways that may work for you:
Recognize that it Exists
The first step in tackling a problem is to recognize that it exists. If you don’t acknowledge you have an issue, you’re likely to ignore it until it becomes a giant fire to put out. It’s much better to tackle the pile of Technical Debt while you have some control over it versus waiting for the inevitable explosion.
Make it Visible
One of the primary tenants of agile is transparency – make all your issues visible. Honesty is the best policy regarding problems, past and present. Some organizations try to hide that they have Technical Debt, which is a bad practice. Like anything else in agile, make sure you recognize and label all items that represent Technical Debt.
Rate for Severity
If you haven’t taken the time to analyze the items in your pile of Technical Debt, you must. Evaluate each issue to determine how severe it is. Categorize the problems by how risky and valuable they are – follow this quadrant (credit to Mike Cohn) to decide which items to do first and which to postpone or not do.
Create a Plan
Once you have sorted your problems for severity, risk, and value, work with your team to create a plan to tackle the most critical items. You don’t want to fill up a full Sprint with nothing but Technical Debt – your customers won’t be pleased with this. You need to balance the delivery of new valuable products with resolving issues.
Allocate a Percentage of Capacity for each Sprint
One good way to pay down Technical Debt is to allocate a set percentage of capacity for this in each Sprint. Like financial debt, unless you make regular payments, interest will continue to accrue, and your balance will grow, not shrink. So, determine how much capacity you’re willing to spend and dedicate the time.
Build Refactoring into new User Stories
Another way to deal with Technical Debt is to tie it to developing new User Stories. If there is an issue that’s in some way related to new functionality, include the refactoring required to address the problem as part of the Acceptance Criteria for the new story. By doing this, you’re still delivering new value and resolving existing issues.
Only take on new Technical Debt intentionally
Sometimes, Technical Debt happens without any conscious decision – it could be due to technical incompetence, laziness, the need for speed, or many other factors. Regardless of how it originally came to be, if you must add additional Technical Debt, only do it with intention. If you do add to your Debt, ensure you make a plan to address it as soon as possible.
You’ll pay eventually
If you don’t deal with Technical Debt, it’s not if but when it will come back to bite you. That proverbial house of cards will fall, and the cost when this happens is much higher than had you proactively dealt with it. Like with financial debt, if you have more than you can deal with, it will bankrupt you.
Avoid accumulating Tech Debt in the Future
Whenever possible, avoid adding any more Technical Debt to your pile. Do that peer review, comment your code, don’t skip steps, and always instill quality. In most cases, it’s better to take the extra time to do things right than to cut corners.
Final Thoughts
Technical Debt is often neglected to the detriment of any product or organization that carries it. Rather than hiding or ignoring it, deal with Tech Debt head-on and transparently. Tackle the most important things first; over time, you can reduce your pile of problems to a minimal size. If you do add new debt, only do it intentionally, and try to avoid it whenever possible.
How about you and your organization? Do you have to deal with Technical Debt? Have you seen huge problems resulting from not handling it? If so, what happened? I’d love to hear your stories, so please share them in the comments below!