The document discusses technical debt in software development. It defines technical debt as deferred work that accumulates when high quality standards are not enforced or corners are cut to achieve velocity targets. This debt makes code complex and hard to change, reducing a team's ability to meet business needs. The document recommends practices like continuous integration, test-driven development, and refactoring to avoid debt. It also discusses strategies for identifying and paying off existing debt over time.

1. TECHNICAL DEBT
... And What to Do About It!

2. THE SPEAKER
Kane Mar,
Scrumology.com
OutSofting.com
Scrum Training
Scrum Coaching
Scrumology.com

3. DO YOU KNOW THESE
PROBLEMS?
Your team cannot change the system quick enough to
meet changing business needs
Your code is so complex only a few people in the
company are allowed to make changes
Your spend more time fixing defects introduced by
new functionality
You have recently re-platformed to newer technology
Scrumology.com

4. WHY SHOULD YOU
CARE?
Be able to meet
changing business
needs
Reduce Total Cost of
Ownership
Build higher quality
products
Keep customers happy
Scrumology.com

6. 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
Scrumology.com

7. 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
Scrumology.com

8. HOW DOES TECHNICAL
DEBT HAPPEN?
By not enforcing high
quality standards
Cutting corners to
achieve a higher
velocity to meet
timelines
As the velocity of
system goes down, even
more corners are cut
Scrumology.com

9. COST OF MAINTENANCE
Product Burndown
100
90
80
Product Backlog
70
60
50
40
30
20
10
0
0 1 2 3 4 5 6 7 8 9
Iteration
Scrumology.com

10. COST OF MAINTENANCE
Cost of Maintenance
Maintenance Cost
0 1 2 3 4 5 6 7 8 9
Release
Scrumology.com

12. 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 ... the legacy system is not in a
know state
There is highly compartmentalized knowledge
regarding the core/legacy system, and it may be
supported by only one or two people in the company
(over specialization)
Scrumology.com

13. SIGNS OF TECHNICAL
DEBT
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
Scrumology.com

15. 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”
Scrumology.com

16. AVOID TECHNICAL DEBT
Implement the Agile
Technical practices:
Continuous
Integration
Test Driven
Development
Refactoring
Pair Programming
Scrumology.com

17. STRATEGIES FOR PAYING
TECHNICAL DEBT
Two strategies to
consider:
Highest interest rate
first approach
Lowest balance first
approach
Scrumology.com

18. PAYING OFF TECHNICAL
DEBT
Described by Michael Feathers in “Working
Effectively with Legacy code”
Start by introducing Continuous Integration
Write Automated Tests around customer reported
defects
Over a period of time a testing framework will be
built up around the most brittle code
Scrumology.com

20. AND AVOID THIS ANTI-
PATTERN
There is a temptation to try and write a
comprehensive testing framework around the entire
product, but:
This does not address the defects that the customer
views as most important
You may run out of money before you complete
the framework, and
You are not delivering new business value
Scrumology.com

21. IN CLOSING ...
By focusing on reducing technical debt, we can:
Better meet changing business needs
reduce Total Cost of Ownership
Build higher quality products
Keep our customers happy
Scrumology.com

22. THANK YOU!

23. REFERENCES
http://www.infoq.com/presentations/agile-quality-canary-
coalmine
http://martinfowler.com/articles/continuousIntegration.html
“Working Effectively with Legacy code,” by Michael
Feathers
“Test Driven Development: By Example”, by Kent
Beck
Scrumology.com

24. PHOTOS CREDITS
http://www.flicker.com/photos/yujin_it
http://www.flickr.com/photos/majamom/
http://www.flickr.com/photos/slayer23/
http://www.flickr.com/photos/44442915@N00/ http://www.flickr.com/photos/eivindw/
http://www.flickr.com/photos/library_of_congress/
http://www.flickr.com/photos/walkn/ http://www.flickr.com/photos/29143375@N05/ http://www.flicker.com/photos/vernhart/
Scrumology.com