Project Management

11 Strategies for Dealing With Technical Debt

From the Disciplined Agile Blog
by , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog


View Posts By:

Tatsiana Balshakova
Mark Lines
Mike Griffiths
Curtis Hibbs
James Trott
Bjorn Gustafsson
Scott Ambler

Past Contributors:

Joshua Barnes
Michael Richardson
Daniel Gagnon
Valentin Tudor Mocanu
Kashmir Birk
Glen Little
Klaus Boedker

Recent Posts

DA 5.6 is released

Disciplined Agile 5.5 Released

Choose Your WoW! Second Edition Is Now Available

Requisite Agility applied in Project Management

Disciplined Agile and PMBoK Guide 7th Edition


#ChoiceIsGood, #ChooseYourWoW, #ConsumableSolution, #ContinuousImprovement, #CoreAgilePractices, #experiment, #Experimentation, #GuidedContinuousImprovement, #Kaizen, #LifeCycles, #ProcessImprovement, #TealOrganizations, Adoption, agile, agile adoption, Agile Alliance, Agile Business Analyst, Agile certification, agile data, agile governance, agile lifecycle, agile metrics, agile principles, agile transformation, Agile2018, Agile2019, Agile20Reflect, AgileData, Analogy, announcement, Architecture, architecture, architecture owner, Articles and publications, Asset Management, Atari, Backlog, Barclays, being agile, benefits, bi, blades, book, Branching strategies, Browser, Business Agility, business intelligence, business operations, capex, Case Study, Certification, certification, charity, Choose your WoW, CMMI, cmmi, Coaching, Collaboration, Communication, Compliance, Compliancy, Conference, Construction, Construction phase, Context, Continuous Improvement, coordination, COVID-19, Culture, culture, Cutter, DA, DAD, DAD Book, DAD discussions, DAD press, DAD roles, DAD supporters, DAD webcast, DADay2019, Data Management, database, dependencies, Deployment, Development Strategies, DevOps, disaster, Discipline, discipline, Disciplined Agile, disciplined agile delivery, disciplined agile delivery blog, Disciplined Agile Enterprise, disciplined devops, Documentation, Domain complexity, dw, DW/BI, Energy Healing, Enterprise Agile, Enterprise Architecture, Enterprise Awareness, enterprise awareness, Essence, estimation, Evolving DA, Executive, Experiment, facilitation, FailureBow, feedback-cycle, finance, Financial, FLEX, Flow, foundation layer, Funding, GCI, GDD, Geographic Distribution, gladwell, global development, Goal-Driven, goal-driven, goals, Governance, GQM, Guideline, Hybrid, Improvement, inception, Inception phase, India, information technology, infosec, Introduction, iterations, Kanban, large teams, layer, lean, Lean Startup, learning, Legal Project Management, LeSS, Lifecycle, lifecycle, Manifesto, mark lines, marketing, MBI, Metaphor, Metrics, metrics, mindset, Miscellaneous, MVP, News, News and events, Non-Functional Requirements, non-functional requirements, Non-solo development, offshoring, Operations, opex, Organization, Outsourcing, outsourcing, paired programming, pairing, paper, People, People Management, phases, Philosophies, Planning, PMBoK, PMI, PMI and DA, PMI Chapter, Portfolio Management, post-format-quote, Practices, practices, Principle, Process, process improvement, process tailoring, Product Management, product owner, Product Owners, productivity, Program Management, Project Management, project-initiation, Promise, Quality, quality, rational unified process, Refactoring, Reiki, Release Management, release management, Remote Training, Remote Work, repeatability, requirements, Requirements Management, research&development, responsibilities, retrospectives, Reuse, Reuse Engineering, ride for heart, rights, Risk, Risk Management, Risk management, Roles, RUP, SAFe, sales, Scaling, scaling, scaling agile, Scheduled Workshops, SCM, scorecard, Scrum, ScrumMaster, SDLC, Security, security, self-organization, SEMAT, serial, skill, solutions software consumable shippable, Stakeholder, strategy, Support, Surveys, Teal organizations, team development, Team Lead, team lead, Teams, Technical Debt, Teleconferencing, Terminology, terraforming, test strategy, testing, time tracking, Tool kit, Toolkit, tools, traditional, Transformation, Transition iteration, transition phase, Uncategorized, Upmentors, Using PMI Standards, value stream, velocity, vendor management, Virtual Training, Workflow, workflow, workspaces


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 Architecture 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 tool kit 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 too lkit can help you to understand how the strategies described above fit into your overall agile delivery process.


Related Resources


Posted by Scott Ambler on: November 10, 2013 12:59 PM | Permalink

Comments (1)

Please login or join to subscribe to this item
Jelili Odunayo Kazeem Co-Founder| Convosync Solutions Limited Enugu, En, Nigeria
Interesting insights. Thanks for sharing.

Please Login/Register to leave a comment.


"Stop that! It's silly."

- Graham Chapman, Monty Python's Flying Circus