Fighting technical debt in an Agile team

Technical debt — design decisions that save time now but make future work take more time — creates a vicious cycle. You’re hurrying to make a deadline, decide it’s worth it to cut corners for now, but you’re bothered by an uneasy feeling that you’re going to regret it. You make the deadline, but next time around you have to face the problem you created, thus taking up more time, putting you in more of a hurry, tempting you to cut corners again.

(This essay was originally published on medium)

If you’re using Agile Methodology, there’s a Product Owner who sets priorities. There’s sometimes tension between feature work the Product Owner wants and paydown of technical debt that the development team wants. To a certain extent there’s always tension among priorities. But I don’t think this has to translate into tension among people. Everybody wants the same thing: the long-term effectiveness of the team. Removing this tension is a simple matter of basic communication on the part of the development team. Not necessarily the scrum master. Anybody can do it.

During sprint planning

When the pressure’s on to aggressively take on a deadline, assume the best of your product owner. Assume there’s a good business reason. Say, “It sounds like this deadline is really important. It may be worth it to take on some technical debt.” You can say those exact words. Your Product Owner probably knows what technical debt is, but if they don’t, it doesn’t matter. They get from the context that it’s a cost. They’re going to ask for details. In all likelihood they care about the speed of future development. Give them the information they need to make a good decision.

During the sprint

Find or create tech debt tickets. Whenever your work is affected by tech debt, link the ticket you’re working on to the relevant tech debt ticket. You’ll use this information later. Get your work done. Your word will carry more authority later if you get things done.

During sprint review

“I got this done, but I think we can do future work like this faster if we address some technical debt.” Product Owners are interested in seeing feature work done faster. They’ll ask for technical debt to be addressed.

Later

“I got this done faster because we addressed technical debt.” The don’t-repeat-yourself principle does not apply to human communication. Spaced repetition helps reinforce a point.

What if my product owner is stupid?

Probably they aren’t. It’s possible they’re ignorant, but if so that’s your fault. You don’t need to be a professional speaker to convey the value of addressing technical debt. It’s also possible that it’s hard for them to listen to you because they pick up on your disrespectful attitude. Try assuming the best of people. If you do, your time and effort won’t be wasted even in the unlikely event that they are stupid, because you’ll be making yourself into a better person.

What if fixing tech debt doesn’t speed development?

In that case you probably aren’t really looking at technical debt. You’re looking at something that’s a matter of personal preference. Prioritize it accordingly.