Technical debt

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

Transcript of Technical debt

CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010

SCRUM & TECHNICAL DEBT

1

© Joe Little 2010

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

[email protected]

2

© Joe Little 2010

Customers want a quality product quickly.

3

© Joe Little 2010

What is technical debtHow 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?

4

© Joe Little 20105

The importance of a definition of done in ScrumThe importance of professionalism in ScrumThe importance of strong engineering practices in ScrumScrum assumes your engineering practices are not "perfect"

Why is Scrum only a framework?

Some key engineering practices (mostly from XP)

Incentives

CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010

Scrum Dynamic Model

Value Velocity

Daily Meeting

READY

DONE

IMPEDIMENTS

Sprint

6

© Joe Little 2010

Technical Debt is bad. Period. Very bad!

7

© Joe Little 2010

What is Technical Debt?

And why is it bad? (Very bad.)

8

© Joe Little 2010

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!

9

© Joe Little 201010

“Scrum made us go too fast!”

No!

CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010

Definition of Done needed to split stories Default Definition of Done

• Automated tests, built & run• No bugs• Acceptance tested• 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

Default Definition of Done• Releasable

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 Kniberg11

CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010

XP

CompanyC

LeanAgile

Scrum

CompanyB Company

C

CompanyA

Queue theory

Game theory

History

Research

Philosophy

Topic: Velocity & technical debt

Chaos theory Principles

Practices

Implementation

More theory...

Source: Henrik Kniberg

12

CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010

Clean & simple

Henrik Kniberg

public class Dog { private final String name; private int woofCount = 0;

public Dog(String name) { this.name = name; }

public void woof() { ++woofCount; }}

import java.sql.Connection;import java.util.concurrent.ExecutorService;import java.util.concurrent.Executors;

public class Dog {private Executor executor = Executors.newFixedThreadPool(18);private int CACHE_SIZE = 50;

public Dog() {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", "beefhead"); statement = connection.prepareStatement("insert into Dog values (?, ?, ?)"); statement.setLong(1, System.currentTimeMillis()); statement.setString(2, person.getName()); statement.setString(3, person.getPhoneNumber().getNumber()); statement.executeUpdate(); } }}} Connection a = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead");b = a.prepareStatement("select * from Dog where name = '" + name + "'"); c = b.executeQuery();if (c.next()) {String foundName = c.getString("name"); PhoneNumber phoneNumber = new PhoneNumber(c.getString(“woofCount")); Person person = new Person(foundName, phoneNumber);return person;} else { return new Person("", null);}

} catch (SQLException e) { return null;} catch (IllegalArgumentException x) { throw x; }}

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()) {String foundName = c.getString("name"); PhoneNumber phoneNumber = new PhoneNumber(c.getString(“woofCount")); Person person = new Person(foundName, phoneNumber);return person;} else {

Dog.java v0Dog.java v1.1Big & hairy

Dog.java v1.2Clean & simple

public class Dog { public static void main(String[] args) { System.out.println("WOOF 1!"); System.out.println("WOOF 2!"); }}

Dog.java v1.0Quick & dirty

Simple code:1.Passes all tests2.No duplication3.Readable4.Minimal

Simple is hard!

13

CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010

Velocity calibration

Source: Henrik Kniberg

EstimatedVelocity

ActualVelocity

40 30

30 28

30 31

30 30

Estimated Actual

40 30

40 30

40 30

Estimated Actual

40 30

50 30

60 30

Estimated Actual

40 35

35 30

30 25

30

25

20

14

CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010

Technical debt & release planning

1

Remainingstory points

Sprint2 3 4 5 6 7 8 9 10 11 12 13 14 15

100

200

300

400

Um... we’re donewhen we’re done!

We’ll be done by sprint 10!

Sorry, we’re late!We should definitely by done by sprint 12!

Source: Henrik Kniberg

15

3 roles• Product owner• Scrum master• Team

3 artifacts• Product backlog• Sprint backlog• Sprint burndown

4 activities• Sprint planning• Daily scrum• Sprint review• Retrospective

CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010

Technical debt

Vmax

Vactual

velo

city

time

Vmax

velo

city

time

VactualSustainable pace!

Definition of Done• .... bla bla ....• No increased technical debtCode duplication

Test coverageCode readability

Source: Henrik Kniberg

16

Definition of Done• .... bla bla ....• Technical debt decreased

CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010

3 roles• Product owner• Scrum master• Team

3 artifacts• Product backlog• Sprint backlog• Sprint burndown

4 activities• Sprint planning• Daily scrum• Sprint review• Retrospective

Dealing with technical debt

Vmax

Vactua

l

velo

city

time

Road to hell

First stepSlow downStop accumulating debt

Second step(optional)Slow down even moreStart repaying debt

Sustainable pace Increasing pace!

Definition of Done• .... bla bla ....• No increased technical debt

Source: Henrik Kniberg

17

CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010

Knowledge decays fast

Don’t let any bugs escape the Sprint

18

Itera&ve  &  Incremental  Time cost of defects for you?

0

5

10

15

20

25

30

35

40

45

50

10 minutes 1 hour Same Day Next Day 1 Week 2 weeks 1 month 2 months

Relative Cost of defects if fixed later

© Joe Little 2010

The bad news does not get better with age!!!

We have to go slow to go fast.

20

© Joe Little 2010

How do we explain Technical Debt to the Product Owner?

How do we explain Technical Debt to the manager?

21

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.

Technical debt & Scrum. Engineering practicesImprovementsFramework

Key Engineering Practices

Which ones??

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)

How do we give the team the proper incentives?

(Or avoid the wrong incentives??)

What do we measure to assure proper incentives?

* 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.

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.

[email protected]://leanagiletraining.com