Working Your Way Out of Large Technical Debt in a Small Project

When you transition to agile with a small project and you have a reasonably sized codebase, chances are quite good that you’ve been working on the product for a while. You have legacy code. You might have legacy tests. You certainly have legacy ways of thinking about the code and the tests. How do you work yourself out of the technical debt you have accumulated over time?

Let’s assume that for some small set of features you can eat small pieces of debt. And you have so much debt that there are some areas of code you just do not want to touch because it would be wading into quicksand. You know you have to create more tests than you have time to create—that is, the size of the story is significantly smaller than the size of the debt, even with swarming.

So, what do you do?

You tell people. You tell the product owner. You tell your colleagues. I would probably write some tests for the code anyway, because I would want to know the next time I'm starting to wade into quicksand—but I have more experience now than I did when I was younger, so I make different choices about the product.

If I were a project manager for this project, I would want to know about the debt because I would want to manage the risk. In my experience, that much technical debt affects a team’s ability to produce features or do anything with the product.

It’s easy in hindsight to say, “Don’t get into that situation.” Well, duh. But organizations are in this situation, and they need help. I still think the best answer to paying off the technical debt is to work in small features and pay off the debt as you find it. That way you never pay off more than you need to, you never do more architecture work than you need to, and you never have this strange backlog issue.

On the other hand, some people don’t realize how much debt they have. Anything that helps them see what they have is useful. Maybe there is a better way.

To summarize:

1. Pay off technical debt when you implement a story, if you can.
2. Swarm to start and finish a story. This will help you avoid and pay off debt.
3. Write more tests to expose the debt so no one is surprised in the future.
4. Expose the debt by creating a debt backlog so the debt can be ranked in preparation for iteration planning.
5. When planning an iteration, take the top item off the debt backlog. Do pairwise comparison of that item with the top item on the feature backlog. Which item has more value? Put that item on the iteration backlog. Continue until the team says, “Stop, we cannot do more in this iteration.”
6. Your very last solution is rearchitecting because it prevents your making progress in the project. Rewriting the code takes awhile, and time is valuable.

Always make sure the technical debt is visible. That is key to managing it.

• Login or Join to add your comment