Managing Technical Debt - 2011 webinar

© 2011 BigVisible Solutions, Inc. All Rights Reserved

Mastering Technical Debt

John Ryan

Technical Agile Coach

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____

Click to edit Master text stylesSecond levelThird levelFourth levelFifth level

© 2011 BigVisible Solutions, Inc.. All Rights Reserved

2

Overview

• What is “Technical Debt”?

• How does it happen?

• What can we do?

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



3

What is Technical Debt?

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



4

Technical Debt is…

borrowing against our capacity of tomorrow

to make more progress today.

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



5

The Structure and Process of Waste

Technical Debt is an accumulation of defects:

• Intent Errors in the software (detected or not)

• Lack of clarity of requirements

• Poor design of the software

• Inappropriate design of the software (not matching the business’ needs)

• Thick-thumb a step in a process that could be automated

An Interest Payment is Time Wasted…

• …working around or fixing existing errors

• …reworking code once requirements are clarified

• …in the extra effort it takes to understand complex code

• …square-pegging new features

• …baby-sitting tasks that could be automated

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



6

How Do We Incur Technical Debt?

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



7

Mere Exposure Principle

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



8

Defaulting

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



9

Best of Intentions

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



10

The Vicious Cycle

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



11

What’s Really Going On Here?

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



12

Minimal Quality Control

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



13

Responsible Quality Control

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



14

Production vs. Production Capacity

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



15

How Do We Master Technical Debt?

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



16

Step 1: Identify The Root Cause

1. Start with the symptom (Interest Payment).

2. Then ask, “why did that happen?” or “what caused that?” (Technical Debt).

3. Keep asking “why?” until you get to the root cause. (Choice that led to creating Technical Debt)

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



17

Step 2: Address It

1. If it’s in your control, fix it!

2. If you have influence, connect it to a common goal.

3. If it’s out of your hands, communicate it’s impact.

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



18

Step 3: Profit!

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



19

Step 1: Identify The Root Cause

Wasted time reworking a feature

BA: thought was obvious

Dev: coded to the spec.

QA: tested code to spec.

Found missing requirement late in the game

Work is being “handed-off” instead of shared.

We’re working in “silos”

Address this…

…and you mitigate this.

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



20

Step 2: Address it

Reworked a feature

BA: thought was obvious

Dev: coded to the spec.

QA: tested code to spec.

Found missing requirement late in the game

Work is being “handed-off” instead of shared.

We’re working in “silos”Collapse the Organization

Trade-off some docs for conversation

Work stories together.

Requirements are questioned upfront.

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



21

Step 3: Profit!

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



22

For Product Owners

The Six Golden* Transformational Patterns to Cure Human Causes

1.Collapse the Org

2.Quality First

3.Active Product Ownership

4.Hire for Cross-Functional Teams

5.Encourage Communication

6.Avoid Arbitrary Mandates

* Jonathon Golden (see references at end of deck)

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



23

For Developers

Invest in your Professional Portfolio:

1.Build Quality In

2.Hone Your Design Chops

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



24

Developers: Build Quality In

Give Test-Driven Development (TDD) a serious college try.

Start with James Shore’s “Let’s Play TDD”: 1. Install Eclipse:

http://www.eclipse.org/downloads/packages/eclipse-ide-java-developers/heliossr2

2. Start the first video:http://www.youtube.com/watch?v=f3G7gu1IHws

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



25

Developers: Hone Your Design Chops

Pick-up a Chop-Sharpening Book:

1. Pragmatic Programmer

2. Refactoring

3. Head First Design Patterns

4. Managing Software Debt

Here’s the most up-to-date list:

http://tinyurl.com/422aco8

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



26

For Scrum Masters

Chris Sterling’s Technical Debt Mapping:

1.Draw major application components on a whiteboard.

2.Write down Technical Debt on Post-Its and put them on the board.

3.Express them as “Quality Improvement Stories” (INVEST) where the value is expressed in terms of ROI.

4.PO: Prioritize by balancing value, cost and immediacy.

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



27

The Journey of 1,000 Miles…

1. List three recent episodes of significant time wasted.• “It took me 2 days to code-up the cross-brand cart and two weeks to test it.”• “…and if we had known that was the real requirement, we would have done

it differently.”• “We almost had a good build, but there were a bunch of problems we had to

fix due to configuration differences between the developer sandbox and our test environment.”

• “I spent a whole day reviewing how we process messages before I could add an additional handler.”

2. Pick one you’re most familiar with: can you think of just one reason why that happened?• “… the message processor logic is overly complex; the architecture team

had planned to handle any kind of inbound message, but we’re really just using JSON and it’s almost always synchronous. Also, we don’t have very good test coverage.”

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



28

…begins with the first step.

3. Can you think of one thing you learned today that could help make a difference?• We could challenge the mandate from Architecture to maintain a generic

message processor. If we could simplify the implementation of this module, it would reduce how much time it takes to made modifications.

4. What’s the very next action step?• We could write a “Quality Improvement Story”:

“As a developer, I want the message processing module to be simplified so that it takes no more than half a day to add a new message handler. This includes writing a small suite of unit tests (happy path) to ensure confidence in this refactoring.”

It’s probably an 8 point story (which have been taking us between 4 to 7 days to complete: [assume $80k salary] worst-case $2,240); what took 12 hours should have taken 4, so the interest rate is currently 200% and this payment was ~$320. The ROI is about 7 message handlers.

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



29

Summary

What is Technical Debt?

•“Technical Debt” is the structural defects in our system

•“Interest Payments” are the symptoms we experience, caused by Technical Debt

•Technical Debt is caused by choices that we make.

How does it happen?

•A vicious cycle of degrading quality (push faster than what the team can handle).

•Non-trivial development without quality control risk of “getting cooked”

What can we do?

•The keys: Investing in quality control and managing complexity

•Paying Technical Debt: Dig to the root cause of it and mitigate that.

•Product Owners: understand and apply the Six Golden Transformation Patterns.

•Developers: invest in your professional portfolio and get better at your craft.

•Scrum Masters: guide the team to harvest “Quality Improvement Stories”

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



30

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



31

References

• Jonathon Golden’s Cutter IT Journal Article:“Transformation Patterns for Curing the Human Causes of Technical Debt”http://www.cutter.com/content/itjournal/fulltext/2010/10/itj1010f.html

• Ward Cunningham explains the origin of ”Technical Debt”http://www.youtube.com/watch?v=pqeJFYwnkjE

• Chris Sterling’s “An Exercise to Identify and Prioritize Software Debt”http://www.gettingagile.com/2010/08/13/an-exercise-to-identify-and-priofitize-software-debt/

• Sonar – Excellent Code Quality Diagnostic* Toolhttp://www.sonarsource.org/

• “Tempo: Timing Tacitics and Strategy in Narrative-Driven Decision-Making“, Venkatesh Rao

• “All Software Is Defective“http://www.njspin.org/present/200706_Rakitin_Steve_All_Software_Is_Defective.pdf

* “Diagnostic” meaning a way to sniff potential problems; don’t let metrics drive your thinking, just inform it.

Technology

Managing Technical Debt - 2011 webinar