Managing Technical Debt

Avoid the high interest costs of technical debt!
Avoid the high interest costs of technical debt!

Tl;dr:

  • Make Technical Debt Visible
  • Repay Technical Debt Incrementally
  • Repay the High-Interest Technical Debt First
  • Repay Technical Debt While Performing Customer-Valuable Work
  • The Product Owner has the final decision to service the debt.

What is technical debt?

“Technical Debt includes those internal things that you choose not to do now, but which will impede future development if left undone. This includes deferred refactoring.

Technical Debt doesn’t include deferred functionality, except possibly in edge cases where delivered functionality is “good enough” for the customer, but doesn’t satisfy some standard (e.g., a UI element that isn’t fully compliant with some UI standard).” Ward Cunningham, 1992

When technical debt arises in software development – which it always does – it is important to classify and understand why debt exists, recognize the consequences of it, and how to manage it.  SCRUM delivery teams often find it challenging to address this debt, and over time, it can become very costly and become the death of a product.

Technical debt can be generally classified into three types. Unintentional, intentional, and unavoidable. Unintentional technical debt refers to debt that can arise from building against unclear requirements, general inexperience, development process maturity, or quality issues.

Some examples of unintentional technical debt include:

  • Team/team member or business immaturity;
  • Process deficiencies that lead to sloppy design;
  • Poor engineering practices;
  • Lack of testing.

Unavoidable technical debt tends to be unpredictable, and is often unpreventable. It can arise from technology design changes over time (on-premise vs. cloud-based). An example of unavoidable technical debt generally involve integrations with 3rd party components that are no longer supported (predictable, but unpreventable) and/or have an unpredictable roadmap.

Intentional debt arises when technical shortcuts are taken to achieve immediate, short-term business goals and address rapid market changes to meet an urgent deadline.

Consequences of technical debt

Regardless of the cause of the technical debt, it can have serious consequences. It could have the following impacts to a team or organization if not properly addressed:

  • Increased time to delivery;
  • Significant number of defects;
  • Rising development and support costs;
  • Decreased predictability;
  • Underperformance;
  • Frustration;
  • Decreased customer satisfaction

Ultimately, technical debt causes uncertainty by slowing down velocity, creating more issues in the long run due to workarounds, breaking processes, and creating instability in releases.

Manage the technical debt

In order to mitigate against the risk and consequences of technical debt, it is critical that teams manage technical debt.

Three approaches to managing technical debt include:

  • Manage the accrual of new technical debt;
  • Make technical debt visible;
  • Service the technical debt.

Manage the accrual

Use Good Technical Practices
Employ practices such as simple design, test-driven development, continuous integration, automated testing, refactoring, etc. Proactively develop practices that will prevent adding new forms of technical debt to their products.

Use a Strong Definition of Ready and Definition of Done
Having a strong definition of ready and definition of done will help guide the team to a low- or no-debt solution at the end of each sprint. A clear definition of ready and the more technically encompassing we make our definition of done, the less likely we are to accrue technical debt.

Make technical debt visible

Make it Visible at the Business and Technical Level
Provide partners with visibility into the product’s technical debt by logging it as defects or user stories into Rally. This makes technical debt visible in the Product backlog and a transparent view of ALL the work, including technical debt, defects, and user stories/Features.

Service the technical debt

Not All Technical Debt Should Be Repaid
Some technical debt is not worth the investment (“the juice isn’t worth the squeeze”). Examples of when not to repay technical debt include when:

  • A feature or component is nearing end of life/close to decommission;
  • It is throwaway prototype work;
  • The feature or component was intentionally built for a short life

A helpful matrix than can be used as a guide for when to service the debt can be found here.

“Always leave the campground cleaner than you found it.” – Boy Scout rule.

During release and sprint planning, as team members are working with the Product Owner to select customer-valuable items from the backlog to work on in the next release or sprint, they should consider user stories from the technical debt Feature to see if the work intersects. If the Product Owner agrees, the user story should be placed within the sprint as work for this sprint.

Guidelines:

  1. Commit to high-quality work that won’t add new unintentional debt;
  2. Apply the Boy Scout rule and clean up technical debt when it can be reasonably accomplished with a given allocation in an iteration;
  3. Repay targeted technical debt from the product backlog to be serviced during the sprint.
  4. The Product Owner ultimately decides what will bring the most value to the team and has the final say on what gets pulled into a sprint.

References: