11 Strategies for Dealing With Technical Debt

I was recently asked how is technical debt addressed in Disciplined Agile Delivery (DAD), a very important question.  Because DAD promotes a full, explicit delivery lifecycle there are many opportunities to first avoid creating new technical debt in the first place and second to address existing technical debt appropriately.

Here are some of the strategies that DAD promotes when it pertains to technical debt:

  1. Do a bit of up front thinking.  One of the process goals of DAD is Identify an Initial Technical Strategy.  By thinking through critical technical issues before you implement your solution you have the opportunity to avoid a technical strategy which needs to be reworked at a future date.  The most effective way to deal with technical debt is to avoid it in the first place.
  2. Have an explicit architecture owner.  The Architecture Owner (AO) on a disciplined agile team is responsible for guiding the team through technical decisions, particularly those at the architecture level.  AOs often mentor other team members in design skills, skills that should help them to avoid injecting new technical debt into the environment.  They should also be on the lookout for existing technical debt and where appropriate motivate the team to address that technical debt when appropriate.
  3. Be enterprise aware.  Disciplined agile teams are enterprise aware, realizing that what they do should leverage and enhance the overall organizational ecosystem.  They will work close with your enterprise architecture and reuse/asset teams, if you have such, so that they can take advantage of existing assets.   Assets could include code, patterns, services, templates, guidelines, or anything else worthy of being reused.
    An important strategy for avoiding technical debt is to reuse existing assets and not rebuild or rebuy something that you already have.
  4. Refactor technical debt away.  DAD provides guidance for when to apply several forms of refactoring, including code refactoring, database refactoring, and user interface (UI) refactoring.  Refactorings are typically very small, such as renaming an operation or splitting a database column, so should just be part of everyday development.  Rework, on the other hand, is more substantive and should be explicitly planned.  The Architecture owner will often negotiate rework-oriented work items with the Product Owner (the person on the team who is responsible for prioritizing the work).
  5. Regression test continuously.  One of the easiest ways to find problems in your work is to have a comprehensive regression test suite that is run regularly.  This test suite will help you detect when defects are injected into your code, enabling you to fix them, or back out the changes, right away.
  6. Automate code/schema analysis.  There are many tools available for assessing the quality of your code and even your database schema.  Disciplined agile teams will include the use of these tools in their continuous integration (CI) strategy.  Knowing where your technical debt exists is the first step in removing it.
  7. Measure technical debt.  Organizations that are serious about technical debt measure it, something that code/schema analysis tools help with, and more importantly keep an eye on the trends (which should be going down over time).  You may choose to track code quality metrics, data quality metrics, usability metrics, time to address defects, time to add features, and many other things.
  8. Explicitly govern technical debt.  Several of the previous strategies require investment that some organizations wouldn’t normally consider to be part of the mandate of a delivery team.  For your organization to succeed at reducing technical debt it must be governed, albeit in an agile fashion.  This means it needs to be understood by senior management, measured (see previous point), and funded.  The DA toolkit includes explicit guidance around how to govern agile teams effectively.
  9. Reducing technical debt should be part of your culture.  Technical debt isn’t going to fix itself, and worse yet will accrue “interest” over time in the form of slower and more expensive evolution of your existing assets.
  10. Address technical debt before handing over an asset.  Passing systems with high technical debt to other teams, such as a sustainment team or maintenance group is generally a bad practice. It should be ingrained in your culture that each team is responsible for keeping the quality of their solutions high. It is reasonable to expect maintenance groups to resist accepting systems that have high technical debt.
  11. Accept some technical debt.  Sometimes you will decide to explicitly accept some short term technical debt for tactical reasons.  Perhaps you need to get something developed quickly because you are running a market experiment (a la Lean Startup).  Perhaps there is a new component or framework about to be delivered by another group in your organization, so you’re writing a small portion of what you need for now until you can replace it with the more robust asset.  Regardless of the reason, part of the decision to accept technical debt is to also accept the need to pay it down at some point in the future.  Having good regression testing assets in place assures that refactoring accepted technical debt in the future can be done with low risk.

There are many good online resources regarding technical debt, and the best single one that we have found is Israel Gat’s blog.   Technical debt is real and you need a viable strategy to manage it.  Otherwise you run the risk of slowly choking the life out of your organization’s IT infrastructure.  The DA toolkit can help you to understand how the strategies described above fit into your overall agile delivery process.

Have any Question or Comment?

12 comments on “11 Strategies for Dealing With Technical Debt

If the features are needed on specific dates, the other approach is schedule margin.


Glen, yes, schedule constraints can be one reason to accept technical debt.

Valentin Tudor Mocanu

Some similar toughs:

Prevention_Versus_Correction – we should focus continuously on quality by adopting “built-in” versus “inspected-in” quality. In fact “test&fix” approach will give a temporary quality and will hide the debt. Finally it is pretty naive to address quality only by test&fix.

Levels_of_Design_Versus_Debt – Because TD is related to software design, it is also related to the Levels_of_Design, where each level could introduce – more or less – its own part of technical debt. Here are some levels (others could also be taken into consideration):
– Coding style
– Clean code rules
– Design decisions in context
– Architecture decisions

No_trade_for_basic_levels – “Bad code is always imprudent.” says Robert C. Martin

Methodology_Induced_Debt – use context-proper iterative approach, that mean the right design strategy in the context.
Agile techniques: Clean Code (“prefactoring”), Refactoring, TDD (pay the debt early)
Risks-driven techniques: Architecture-driven approach.

Avoid_Mega_Debts – the cost of a such debt could be exponentially higher then of the normal debt. Examples: refactoring nightmare by interfering debts (such unsearchable names + “duplicate” code); Envious_Monster – mega components that present “”feature envy” for many other components; Big_Design_Elements

Register_the_debt – in order to manage and pay the debt , you should know and register the debt

Manage_Mega_Debts_First – big, important and messy – that is an explosive problem.

Define_and_Use_Thresholds – beyond applying metrics, should be associated some risks thresholds to significant metrics.

Search_Usual_Suspects – feature envy, big size, no separation of concerns; that could offer a quick assessment and reaction

Use_Separation_Of_Concerns – that is the design principle with biggest impact on debt management.

Long_Term_Steadiness – see Software Craftsmanship Manifesto

Honest_development – clearly define the responsibility of managing TD
(More details – article Know and Manage the Technical Debt)


Great article.

I would highlight the (probably obvious) need to create awareness about the damage and the money wasted because of accumulaiting technical debt. This is common to the drivers of introducing quality, agility or measurements in the organization.

When you face the tyranny of deadlines and bad managers, unfortunately you must start by “quantifying common sense”.



For completeness, this list of 11 Technical Debt Strategy points needs to be an even dozen:

12. The practice of Technical Debt fosters permissible and persistent neglect and needs to be discontinued and eliminated.


Thank you Scott for this. Here’s my baker’s dozen on advice for tech debt sufferes: Some 13 concrete things you can do today about your tech debt: http://wp.me/pAj86-aO


We should just book a % of each project to address this, for example, given the product typical lifecycle of a continuous product having releases into the market.


Leave a Reply

Your email address will not be published. Required fields are marked *