My presentation to the Brisbane Scrum Users group on 25th February, 2009.

1. Technical Debt and What to
do about it.
Kane Mar
Certified Scrum Trainer and
Coach (CST and CSC)
http://KaneMar.com
Kane.Mar@gmail.com

2. About Me, About You

3. What is Technical Debt
The concept of software complexity as debt was
originally coined by Ward Cunningham in an
experience report for OOPSLA ‘92 (*)
Reference: http://c2.com/doc/oopsla92.html

4. What is Technical Debt
During the planning or execution of a software
project, decisions are made to defer necessary work:
It's too late in the LifeCycle? to upgrade to the new release of the
compiler. We'll do it next time around.
We're not completely conforming to the UserInterface guidelines.
We'll get to it next time.
We don't have time to uncruft (refactor, see RefactorMercilessly)
the hyper-widget code. Punt until next time.

5. What is Technical Debt
A big pile of deferred work can gum up a project, yet
many of the items on the list don't appear on a
project team's radar, especially if the focus is
primarily on new product features. Yet removing
accumulated sludge needs to be accounted for in
planning!
Therefore: Make the debt visible. Keep an explicit list
Technical Debt

6. Quality and Velocity
Correlation between declining quality and velocity
50.0
37.5 % Maintenance
Velocity of New Development (PBI/$100k)
25.0
12.5
0
1 2 3 4 5 6
Category Title
New Requirements Capability
2000
1500
Requirements
1000
500
0
1 2 3 4 5 6
Category Title

7. The story of a burger ...

8. How does “Technical Debt”
occur?
By not enforcing high quality standards in the
definition of “done.”
Cutting corners to achieve a higher velocity and meet
impossible timelines leads to build up of low quality,
unmaintainable code.
Death spiral: As the maximum velocity of system goes
down, even more corners are cut to compensate until
the velocity approaches zero.

9. Signs of Technical Debt
The code is considered part of a core or legacy
system
There is either no testing, or minimal testing
surrounding the code
There is highly compartmentized knowledge regarding
the core/legacy system, and it may be supported by
only one or two people in the company (over
specialization)

10. Signs of Technical Debt
The legacy system is not in a know state
It takes as long to fix defects caused be adding new
functionality, as it does to add the new functionality
Re-platforming ... and then repeat the mistakes of the
past

11. What to do about Technical
Debt
Avoid accumulating technical debt
Pay it off over time (mortgage)
“Working with legacy code” by Michael Feathers
An anti-pattern worth mentioning

12. Avoid Technical Debt
Development teams must curb over-optimism in
assessing availability and capacity
Management redirects attention from applying
pressure to removing organizational impediments to
progress
Product Owners understand the iron triangle,
ownership of risks, and impact of cutting quality
ScrumMaster must prevent demonstration of any work
that is not “done”

13. Paying off Technical Debt
Described by Michael Feathers in “Working Effectively
with Legacy code”
Start by introducing Continuous Integration
Write Tests around customer reported defects
Over a period of time a testing framework will be
built up around the most brittle code

14. And Avoid this anti-pattern
There is a temptation to try and write a
comprehensive testing framework around the entire
product
Does not address the defects that the customer views as most
important
May run out of money before you complete the framework

15. Thank you!