Technical debt refers to work that must be reworked in the future due to poor quality or lack of testing. It slows teams down over time. Scrum assumes engineering practices are not perfect and technical debt will occur. Teams must define "Done" to prevent increasing technical debt and focus on quality. Key practices like test-driven development, refactoring, and continuous integration help reduce technical debt. Teams and managers must understand technical debt to set proper incentives and pace.

1. SCRUM & TECHNICAL DEBT
CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010
1

2. Joe Little
• Agile Coach & Trainer
• 20+ years in senior level consulting to well-known firms in New York, London and
Charlotte
• Focus on delivery of Business Value; interest in Lean
• CST, CSP, CSM; MBA
• Was Senior Manager in Big 6 consulting
• Head of Kitty Hawk Consulting, Inc. since 1991
• Head of LeanAgileTraining.com
• Started trying to do [Agile] before reading The Mythical Man-Month
– http://agileconsortium.blogspot.com
– jhlittle@kittyhawkconsulting.com
© Joe Little 2010
2

3. Customers want a quality
product quickly.
© Joe Little 2010
3

4. What is technical debt
How would you notice it?
A velocity that is based on a weak definition of
done is just a lie!!!
"Scrum made me go too fast!" NO!!!
The bad news does not get better with age
How do we explain technical debt to the
product owner?
How do we explain technical debt to the
managers?
© Joe Little 2010
4

5. The importance of a definition of done in
Scrum
The importance of professionalism in Scrum
The importance of strong engineering
practices in Scrum
Scrum assumes your engineering practices are
not "perfect"
Why is Scrum only a framework?
Some key engineering practices (mostly from
XP)
Incentives
© Joe Little 2010
5

6. Scrum Dynamic Model
Daily
Meeting
Sprint
I
R M D
P
E E O
A D N
D I E
M
Value Y E Velocity
N
T
S
CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010
6

7. Technical Debt is bad. Period.
Very bad!
© Joe Little 2010
7

8. What is Technical Debt?
And why is it bad? (Very bad.)
© Joe Little 2010
8

9. A velocity that allows technical
debt to be built is a lie!
A velocity that is built on a
weak definition of done is a lie!
© Joe Little 2010
9

10. “Scrum made us go too fast!”
No!
© Joe Little 2010
10

11. Definition of Done
needed to split stories Default Definition of Done
• Automated tests, built & run
Default Definition of Done • No bugs
• Acceptance tested
• Releasable • Release notes written
• Releasable
• No increased technical debt
Default Definition of Done
• Unit/Integration tested
• Accepted by PO
• Ready for acceptance test
• Deployed on demo server = I haven’t made
the codebase hard to
change
What’s NOT included in DoD?
- Example: ”customer acceptance test + user documentation”?
Why not? Who does it? When? What happens if a problem turns up?
Source: Henrik Kniberg CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010
11

12. Topic: Velocity & technical debt
Queue
theory
Chaos theory Principles
e arch
Res Agile Lean Game theory
History Philosophy More theory...
m
Scru XP
Practices
Implementation
Company
Company B Company
A Company
C
Source: Henrik Kniberg C
CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010
12

13. Clean & simple
Dog.java v1.1
Dog.java v0 Dog.java v1.0 Big & hairy
Quick & dirty import java.sql.Connection;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class Dog {
public class Dog { private Executor executor = Executors.newFixedThreadPool(18);
private int CACHE_SIZE = 50;
public static void main(String[] args) {
System.out.println("WOOF 1!"); public Dog()
{
System.out.println("WOOF 2!"); try
{
} Class.forName("oracle.jdbc.ThinDriver");
connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin",
} "beefhead");
statement = connection.prepareStatement("insert into Dog values (?, ?, ?)");
} catch (ClassNotFoundException e) {}
new Thread().start();
}
public void woof(Person woofCaller) {
Connection connection = null;
PreparedStatement statement = null;
try {
connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin",
Dog.java v1.2 "beefhead");
statement = connection.prepareStatement("insert into Dog values (?, ?, ?)");
statement.setLong(1, System.currentTimeMillis());
Clean & simple statement.setString(2, person.getName());
statement.setString(3, person.getPhoneNumber().getNumber());
statement.executeUpdate();
}
}
}
public class Dog { } Connection a = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin",
private final String name; Simple code: "beefhead");
b = a.prepareStatement("select * from Dog where name = '" + name + "'");
c = b.executeQuery();
private int woofCount = 0;
1.Passes all tests if (c.next()) {
String foundName = c.getString("name");
PhoneNumber phoneNumber = new PhoneNumber(c.getString(“woofCount"));
public Dog(String name) { 2.No duplication Person person = new Person(foundName, phoneNumber);
return person;
this.name = name; } else {
} 3.Readable }
return new Person("", null);
public void woof() {
4.Minimal } catch (SQLException e) {
return null;
} catch (IllegalArgumentException x) {
throw x;
++woofCount; }
}
}
} Simple is hard! public List<Person> getAll() {
connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin",
"beefhead");
statement = connection.prepareStatement("insert into Dog values (?, ?, ?)");
statement.setLong(1, System.currentTimeMillis());
}
if (statement != null) {
if (c.next()) {
Henrik Kniberg String foundName = c.getString("name");
CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010
PhoneNumber phoneNumber = new PhoneNumber(c.getString(“woofCount"));
Person person = new Person(foundName, phoneNumber);
return person;
} else {
13

14. Velocity calibration
Estimated Actual
Velocity Velocity Estimated Actual
40 30 40 30
30 28 40 30
30 31 40 30
30 30
Estimated Actual Estimated Actual
40 30 30 40 35
50 30 25 35 30
60 30 20 30 25
Source: Henrik Kniberg CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010
14

15. Technical debt & release planning
Remaining
story points
400
We’ll be
done by
300 sprint 10!
Sorry, we’re late!
We should definitely
200 by done by sprint 12! Um... we’re done
when we’re done!
100
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Sprint
Source: Henrik Kniberg CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010
15

16. 3 roles
• Product owner
• Scrum master
Definition of Done • Team
Technical debt • .... bla bla .... 3 artifacts
• Product backlog
• No increased technical debt • Sprint backlog
Code duplication • Sprint burndown
Test coverage
4 activities
• Sprint planning
• Daily scrum
Code readability • Sprint review
• Retrospective
Vmax Vmax
Vactual
Vactual
Sustainable pace!
velocity
velocity
time time
Source: Henrik Kniberg CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010
16

17. 3 roles
• Product owner
• Scrum master
• Team
Dealing with technical debt 3 artifacts
• Product backlog
• Sprint backlog
• Sprint burndown
4 activities
• Sprint planning
• Daily scrum
Definition of Done Definition of Done • Sprint review
• Retrospective
Vmax • .... bla bla .... • .... bla bla ....
• No increased technical debt • Technical debt decreased
Vactua
l Ro
ad
to
velocity
he
ll
pa ce!
a sing
Sustainable pace Incre
Second step
First step (optional)
Slow down Slow down even more
Stop accumulating debt Start repaying debt
time
Source: Henrik Kniberg CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010
17

18. Knowledge decays fast
Don’t let any bugs escape the Sprint
CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010
18

19. Time cost of&defects for you?
Itera&ve
Incremental
Relative Cost of defects if fixed later
50
45
40
35
30
25
20
15
10
5
0
10 minutes 1 hour Same Day Next Day 1 Week 2 weeks 1 month 2 months

20. The bad news does not get better with age!!!
We have to go slow to go fast.
© Joe Little 2010
20

21. How do we explain Technical
Debt to the Product Owner?
How do we explain Technical
Debt to the manager?
© Joe Little 2010
21

22. The importance of a definition
of done.
We recommend a detailed
Definition of Done, that is clear
about how we will not build
technical debt.

23. Technical debt & Scrum.
Engineering practices
Improvements
Framework

24. Key Engineering Practices
Which ones??

25. Key Engineering Practices
...pair programming
...TDD
...continuous integration
...refactoring, refactoring, refactoring
...10 minute build
...automatic unit tests
...automated functional tests (other names)
...automated other testing (regression
especially)

26. How do we give the team the
proper incentives?
(Or avoid the wrong
incentives??)

27. What do we measure to assure
proper incentives?

28. * We focus on speed and low
work-in-process.
* We see the impediments
better.
* We fix the root causes.
* Over time, this enables
everything: cheaper, higher
quality, faster, more what they
want.

29. The End
Please send me your comments and
suggestions. This is an important topic. If
it were easy, we as an industry would not
have this problem. So, I appreciate your
feedback.
jhlittle@kittyhawkconsulting.com
http://leanagiletraining.com