Scrum Hates Technical Debt

SCRUM HATES TECHNICAL DEBT CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010 1 Joe Little• Agile Coach & Trainer• 20+ years in senior level consulting to well-known ﬁrms 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

Customers want a quality product quickly. Is this a problem? © Joe Little 2010 3What is technical debt? It helps to have a fairly common definition. © Joe Little 2010 4

AgendaWhat is technical debt - done?How would you notice it?"Scrum made me go too fast!" NO!!!The bad news does not get better with ageWhy Scrum hates Technical DebtThe importance of a definition of done inScrumA velocity that is based on a weak definition ofdone is just a lie!!!How do we explain technical debt to theproduct owner? © Joe Little 2010 5How do we explain technical debt to themanagers?The importance of professionalism in ScrumWhy is Scrum only a framework?Scrum assumes your engineering practices arenot "perfect"Some engineering practices (mostly from XP)IncentivesDid I mention? Scrum hates Technical Debt! © Joe Little 2010 6

How do you notice Technical Debt? © Joe Little 2010 7Is Technical Debt bad? © Joe Little 2010 8

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 9 My opinion: Technical Debt is bad. Period. Very bad! © Joe Little 2010 10

“Scrum made us go too fast!”No! © Joe Little 2010 11A velocity that allows technicaldebt to be built is a lie!A velocity that is built on aweak definition of done is a lie! © Joe Little 2010 12

Definition of Done needed to split stories Default Definition of Done • Automated tests, built & runDefault 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 13 The bad news does not get better with age. CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010 14

Time cost of defects for you? !"#$%&#()(!*+$#,#*"%-( 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 monthsWe have to slow downto go fast. CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010 16

Knowledge decays fast Don’t let any bugs escape the Sprint CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010 17Why Scrum hates Technical Debt It’s a bad life for you Hateful work Bad reputation You know it’s sinful! The customers hate it (ultimately, at least) The business guys go nuts! It seems to make Scrum look bad (not really true, but appearances sometimes count) CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010 18

Topic: Explaining to Product Owner Queue th e o ry ch Chaos theory Principles ear 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 19 Clean & simple Dog.java v1.1Dog.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 { 20

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 21 Technical debt & release planningRemainingstory 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 22

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 • RetrospectiveVmax VmaxVactual Vactual Sustainable pace! velocity velocity time time Source: Henrik Kniberg CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010 23 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 • RetrospectiveVmax • .... bla bla .... • .... bla bla .... • No increased technical debt • Technical debt decreasedVactua l Ro ad to velocity he ll ce! g pa asin 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 24

The bad news does not get better with age!!! We have to go slow to go fast. © Joe Little 2010 25To the Product Owner Was that enough? What would you add? © Joe Little 2010 26

How do we explain Technical Debt to the manager? © Joe Little 2010 27Manager Protection from magical-thinking managers: Velocity! Explaining Sustainable Pace © Joe Little 2010 28

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.The importance of professionalism Scrum is not an excuse to be un-professional. Quite the contrary. Why is Scrum only a framework? CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2010 30

Coaching: Technical debt & Scrum. Engineering practices Improvements IncentivesKey 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 assureproper incentives?* We focus on speed and lowwork-in-process.* We see the impedimentsbetter.* We fix the root causes.* Over time, this enableseverything: cheaper, higherquality, faster, more what theywant.

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

Scrum Hates Technical Debt

by LeanAgileTraining / Kitty Hawk Consulting, Inc. on May 14, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

Scrum Hates Technical Debt — Document Transcript