How To Pay Down Technical Debt

Posted by Dan Puckett on Dec 06, 2010

Sections

Process & Practices

Topics

Delivering Quality ,

Technical Debt ,

Quality ,

Agile Techniques ,

Software Craftsmanship ,

Scrum ,

Agile

Share |

RELATED Research

Paul Tevis is on a team that is four months into a Scrum transition. The project has a significant amount of technical debt, and he is wrestling with the problem of how to track and pay down that technical debt. Tevis writes:

My concerns are (1) as soon as we start tracking non-story tasks we'll lose focus on delivering customer value, And (2) if we don't make these sorts of tasks visible, we won't make progress on them at the rate we need to. What are good patterns you've seen for dealing with technical tasks that aren't directly attached to a story (or that cut across multiple stories)?

What is technical debt? Ward Cunningham coined the term "technical debt" to refer to an obligation that an organization takes on when it decreases the quality of its code base in order to meet short-term goals. Bringing code quality back up invariably costs more to do later on than it would have if quality had been addressed immediately. This extra cost represents the "interest" on the technical debt.

Malcolm Anderson makes a case for taking on technical debt under certain circumstances:

There are a lot of reasons for taking on short term technical debt. I use the analogy of the credit card with a 36% interest rate. You do not want to use that card. But there are times when it makes great business sense to use that card in a short term situation.

But Adam Sroka objects:

If you were going to make that business decision you would at least want to know:

1. How much am I spending?
2. How much interest will I incur? Over what period of time?
3. Will I have enough revenue to pay it back?

When teams voluntarily take on technical debt they rarely (if ever) know the answer to even one of these questions.

Whether or not it was a good idea to do so, in Tevis' case the debt has already been incurred. So how can we best go about reducing existing technical debt in our projects?

Roy Morien offers two possible solutions to the problem of how to pay down technical debt:

Do you really have such a difficult choice to make? I would think that if your 'technical' development requirements are so important and so big, or so many, isn't it a practical thing to do to call a timeout on user-facing development, and get those technical matters squared away and off the table?

Or, is it possible to reassign some developers to get these technical matters done, while the rest of the team continues on the user-oriented stuff? This may affect team velocity, but so what?

Ron Jeffries disagrees with these two approaches, however:

Working on the "technical matters" works best when it is driven by stories. The code base is probably in need of work everywhere, but the payoff will be received only where the code is going to be worked on for user-facing reasons. If no stories are going to pass through some crufty area, working on it is largely wasted.

Therefore, I prefer the approach of taking stories as usual (but probably fewer of them), and following the "boy scout rule" of leaving the campground better than you found it. In other words, wherever the stories lead us, let's write more tests, let's refactor more aggressively.

This approach has at least these advantages:

• maintains "best sensible" flow of stories;
• provides help from all team talent;
• provides for whole team to learn how to keep code clean;
• focuses improvement exactly where it is needed;
• does not waste improvement that "may" be needed;

... and probably more.

And "banshee858" offers this suggestion (with original credit to Tobias Mayer) that dovetails nicely with Jeffries' approach:

List all the technical debt stuff on little post-it notes Adjacent to the Task Board. When a Product Backlog item (PBI) is selected for a Sprint, look at the technical debt pieces and find the pieces that make sense to finish while working on the PBI. Add those to the scope of work for the PBI and estimate how long it will take to complete the feature and the technical debt pieces.

That way you make the technical debt work visible, you can prioritize it and link it to real value.

RelatedVendorContent

Five Key Practices to Agile ALM

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Agile Maturity Model Applied to Building and Releasing Software

Agile assessments for your team

Agile workshops and training

Related Sponsor

Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.

1. Back to top

   Make it a PO issue

   by Stefan Norberg

   Technical debt issues should be approached as any other task. I find it helpful to track it in each retrospective using the planning poker cards. Each team member votes on the percieved debt. Track this KPI.
   If velocity drops and debt rise, then a good PO will prioritize it.

   Reply

2. Back to top

   Trust

   by Iyigun Cevik

   Here's my view of the topic: goo.gl/zYWiP

   Reply

3. Back to top

   Tachnical Debt and Business Value

   by Chris Matts

   If you cannot express why Technical Debt affects Business Value, then you really have some missing skills/experience on the team.
   
   Business Investors easily understand the impact of technical debt on business value. You just need someone who can talk to them in their language. Hire a business analyst. we don't do much, but the bits we do do make it worth your while. ;-)

   Reply

4. Back to top

   I agree with Ron

   by Jerome St-Pierre

   It is useless to refactor and clean up code that works and doesn't need to change for a delivery. The best is to continually clean up and improve the design of the code that stays in the scope of our daily tasks to deliver new features, fix bugs or embrace change. This is simply the YAGNI principle, we should only refactor and clean up when we actually need to.
   
   Using this approach also minimize the risk of breaking working features that won't always be validated by developers or the QA that can't always run complete system-wide-real-scale-regression-testing when making changes that are related to a sub set of the system features.

   Reply