Technical debt is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”. Technical debt can be compared to monetary debt in that if it is not repaid, it can accumulate ‘interest’, making it harder to implement changes later on. Important questions to ask are “How common is it for agile teams to run into technical debt in practice?” and “When they do run into technical debt, are they paying it down?”
The following diagram summarizes responses to our question from our 2016 Agility at Scale study around technical complexity. As you can see 84% of agile teams are working with legacy functionality and 51% with legacy data sources (so yes, the vast majority of teams are working in environments that are likely to have some form of technical debt). More importantly, 38% of teams are actively paying down functional technical debt and 32% are paying down data technical debt (48% are paying down one or the other).
- The spilled juice analogy for technical debt
- 11 strategies for dealing with technical debt
- Recorded webinar: Crushed by Technical Debt?
- Can you outsource and still be agile?
- Do agile teams take on hard problems?
- Do agile teams face regulatory compliance?
- How “whole” are agile teams in practice?
- How geographically distributed are agile teams in practice?
- How large are agile teams in practice?