It is a rare a product that does not carry some technical debt. Trade-offs and compromises are made - to meet deadlines or work within other constraints. Some of those decisions have consequences that do not age well over time, and that is technical debt - the implied cost of additional work caused by choosing an easy or limited solution (instead of the more desired approach that would take longer / cost more / use additional resources.) It is similar to financial debt - you take it on because the value of having the item now is more important than saving up to purchase it when you can afford it. Eventually the debt must be paid down, and similar to financial debt, sometimes that comes with interest owed.
Not all technical debt is bad. Product teams must balance the business goals and outcomes with technical solutioning and implementation decisions. The key is to take on the debt responsibly. Part of doing that is identifying when you are making a decision that is not ideal. Thinking through - or at least acknowledging - a future fix at the time it is implemented can be valuable.
Additionally, categorizing your debt can be a helpful exercise, to better understand the trade-offs on your product and to help in the debt remediation phases.
Some categories of technical debt are:
Secure Coding - issues or vulnerabilities discovered within the code, through audits such as OWASP Top 10
Accessibility - issues addressing digital accessibility, at a minimum meeting compliance with WCAG 2.1 level AA or AAA
Code Efficiency - Maintainability, testability, performance, and scalability of code
Architectural Integrity - Best practices for code, security, data, and architecture
Business Risk - Documentation, audit controls, SOX compliance, etc.
Up-to-Date Technology - Ensuring the latest versions of IDEs, frameworks, libraries, servers, databases
Automated Testing - Increase coverage, resolution, alignment, and optimization of automated testing framework
The best approaches to technical debt focus on thoughtful decisions about when to take on the debt, and careful tracking and planned remediation.
STAND-UP EXERCISE
As a product team, identify the categories of technical debt that your product does/could encounter. Is there a way to track these categories on your tickets / incidents? Discuss how the team could systematically remediate technical debt. Is it best to focus a percentage of every sprint’s points toward one or more of these categories? Is it better to use one or two sprints a quarter to completely dedicate toward eliminating debt? Is there a way to coordinate with other teams, if you have reliance or dependencies with them? Create a plan for your team, and revisit it - as well as your tracked metrics - on a regular basis as your team and product evolves.
