2. • Why should I care?
• What is Technical Debt?
• Is there ever a case for Technical Debt?
• What are the business consequences?
• Why isn’t this just an IT problem?
• How Might You Get Started Addressing Technical Debt?
AGENDA
2
https://xkcd.com/2030/
6. • Speed matters more than ever.
• Technical debt slows you down.
• You can address technical debt to increase speed.
• Partnership by everyone in the value-delivery chain is critical.
And if it is too hard getting things done technically at your company, talented
people won’t want to work there
WHY THIS PRESENTATION?
6
16. • Not following clean coding principles
• Not having coding standards
• General lack of automation everywhere: tests, security, deployment, monitoring
• Bad design
• Bad User Stories
• Perennially broken builds, or failing tests
• Lack of code craftsmanship
OTHER EXAMPLES
16
17. TIME TO DELIVER A NEW FEATURE
Effort to Add
or Change a
Feature
Time
As system size or complexity increases, so does the
time it takes to deliver a new feature
17
18. CONSEQUENCES OF TECHNICAL DEBT
Impact of Technical Debt
Effort to Add
or Change a
Feature
A much steeper curve – the time to add a new feature
increases more rapidly with Technical Debt
Time
18
Eventually the time it takes to implement the feature, test it,
integrate into the code base and fix broken builds exceeds the
time-box of the Sprint.
At this point quality and predictability rapidly deteriorate.
19. 19
HIRING
• The talent you want to hire has
options
• If you want to attract and retain
good people, you must be
competitively technically
21. A POSSIBLE CONSEQUENCE: REWRITE TREADMILL
Our systems are too
hard to modify
We build a
replacement
Business pressure
leads to technical
shortcuts
Our systems acquire
technical debt
21
22. IS THERE EVER A
JUSTIFICATION FOR
TAKING ON DEBT?
YES, BUT YOU HAVE TO PAY IT BACK
22
23. 23
AN EXAMPLE OF USEFUL DEBT
Take on debt to
increase speed
Test in the
marketplace
Recode for
quality
Discard the
code
Desired
outcome
This works if you have the
discipline to pay back the debt
25. HOLDING COSTS AND TRANSACTION COSTS
Holding Costs
How much does it cost to not ship software?
• Cost of capital
• Lost opportunities (new sales, increased customer
satisfaction, market share)
• Obsolescence
Transaction
Costs
How much does it cost to ship software?
• Testing
• Release Management
• Fixed Training Costs
Reinertsen, Donald G. (2012-03-29). The Principles of Product Development Flow: Second Generation Lean Product Development (p.
122). Celeritas Publishing. Kindle Edition.
25
26. EXAMPLE OF HIGH TRANSACTION COSTS
Two Days
Coding
One Day
Testing
Two Person-Months
Regression Testing
Two Days
Release Management
26
27. EXAMPLE OF HIGH HOLDING COST
If we release this feature
into production in the
next two weeks we can
close a $1M deal!!!
27
28. OPTIMIZING BATCH SIZE
• Improved practices can help you lower
transaction costs
• Lower transaction costs give you the
freedom to release more often
• Enabling faster learning cycles and
improved economic outcomes
28
31. 31
We came up with a
proposal for automated
unit tests. We were told
just to focus on features.
We didn’t have time for
improvement.
32. AT THE TEAM LEVEL
32
• The Product Owner is responsible
for the Product Backlog
• The Product Backlog can include
items to reduce technical debt
• The Product Owner has to choose to
reduce debt, and keep it from
growing
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
33. IMPROVING INITIALLY SLOWS YOU DOWN
Team decision to decrease Technical Debt
Effort to Add
or Change a
Feature
Team investment in test automation, code improvement and
elimination of manual work initially slows progress
Time
33
34. 34
PRODUCT OWNER SUPPORT IS ESSENTIAL
I support the team’s technical
practices. I’m willing to spend
more time to get a story done
today so that we have the quality
and adaptability we need in the
future.
Product Owner
35. 35
HOW MUCH SHOULD SHOULD YOU INVEST?
We will actively manage this technical debt by
ensuring that we invest at least 20% of all
Development and Operations cycles on
refactoring, investing in automation work and
architecture and non-functional requirements
… such as maintainability, manageability,
scalability, reliability, testability, deployability,
and security. 1
1. Kim, Gene,Humble, Jez,Debois, Patrick,Willis, John. The DevOps Handbook: How to Create World-Class
Agility, Reliability, and Security in Technology Organizations (Kindle Locations 1669-1672). IT Revolution
Press. Kindle Edition.
36. ROADMAP EXAMPLE
Show potential add-on products
for what the customer is viewing
Ready for Validation
Jan Feb Mar Apr May Jun
Now
Enable customers to
post video product
reviews
In Process
Create new “Account” service
Ready for Work
Ju
Decreasing Certainty
Additional frequent buy
bonuses for credit car
holders
Waitingfor Approva
ec
Enable future growth
36
38. 38
CORE APPROACH
Where does it make
economic sense to
invest?
Where are the main
issues?
How do we address
them?
Assess the impact of
technical debt on outcomes:
• Lost sales
• Poor quality or reputation
• Difficulty attracting or
retaining technical talent
• Loss of market share
• Customer defections
Map the Value Stream:
• Visualize the end-to-end
process
• Identify the critical speed
and quality issues
Execution model
• Backlog?
• Product Owner?
• Team?
• Scrum or Kanban?
39. If you had $100,000 to
improve your house, would
you spread it evenly across
the entire house? Parquet
the garage floor?
39
40. MANAGING TECHNICAL DEBT IS AN ECONOMIC DECISION
Malakooti, B. (2013). Operations and Production Systems with Multiple Objectives. John Wiley & Sons.
Where might you
invest more heavily
in improvement?
Why?
40
41. 41
USE VALUE-STEAM MAPPING TO DRIVE IMPROVEMENT
Understand where you have delays and issues with end-to-end
value delivery. Use this to improve speed and quality.
42. • Where would reducing technical debt produce the most impact?
• How can we add to our definition to done to stop technical debt from increasing?
• Do we have a budget for reducing debt? A percent of our capacity every Sprint?
• Are there roadmap items – enablers – that will would help us as a team? How
do we advocate for those?
• How do we put our ideas into action?
TALK AS A GROUP ABOUT WHAT TO DO
42
Photo provided DAS PSB under Attribution 2.0 Generic (CC BY 2.0)
In extreme circumstances rewriting may be the best economical
alternative including using the strangler pattern to move parts of
the functionality methodically to new services.
Notas do Editor
Please note: The orange underline bar needs to extend just beyond the presentation title and should be manually adjusted.
He knew the characteristics of his plane so well, he could respond to random situations successfully
you want your opponent responding to you, not you responding to them.
How do we achieve this?
Observation: the collection of data
Orientation: the analysis and synthesis of data to form one's current mental perspective or model
Decision: the determination of a course of action based on that current mental model
Action: the implementation of the decisions
Time is a critical parameter. The organization who goes through the cycle in the shortest time comes out ahead because their opponent is caught responding to situations that have already changed. And may no longer be relevant.
Amazon and CVS / Walgreens have similar products with their Pill Packs; but Amazon will always outmaneuver the competition. Amazon will do something, and three months later CVS will roll out their 'me-too'. But by then, Amazon will have moved on and done more than the 'me-too', The competition will be responding to a situation that has already progressed by at least as long as it takes them to actually roll out their response.
A term you often hear used around static analysis is Technical Debt. SonarQube will tell you how many man-hours or man-years of technical debt it detects. You can configure this to only inspect those attributes of your code you find value in. The debt is then the amount of time it estimates it would take to correct each of the issues it detects.
But like our National Debt, this is an abstract concept, and most people don't get it. They ignore it. I prefer to use the term coined by Timothy Reaves, called 'Development Tax'. Instead of an overall single figure, this is expressed as a ratio. How much work must a developer perform on a story, before the actual business value is addressed. This can be easier to explain to business. I've seen this as high as 70%. This means that if a story takes 10 man-days to complete, fully seven of those days were spent not producing a single bit of business value.
So paying attention to static analysis is crucial to the overall efficiency of the organization.
- if you have to work in code with a lot of debt, and you go in there, how quickly can you find what you need, make the change, and get out?
- If you go in under pressure, you can't figure it out, you end up making your change. But that's just added anther knot
The ideal is having an environment that changes state versus moving code from environment to environment
Architectures of application
Architectures of build & release
These concerns do not just apply to Traditional organizations
AirBnB is a startup. So did they face these issues? Absolutely. You can't start off with writing micro-services; you first have to understand where micro-services are needed, and what they should do. So they had to write that monolith before they could rearchitect.
Architecture can prevent you from responding in a fast-enough timeframe
Most organizations have a boat anchor release process. Now your innovations are being tied to that anchor
How many have gone through multiple rewrites of a core system? You rewrite for some glorious future. And find you end up rewriting it again.
learning can be more valuable then technical excellence
companies involved in innovation will often have teams that code quickly, test hypothesis, and then hand off successful tests to more formal teams to fully & correctly implement
Be careful; at the majority of organizations, there is no such thing as a temporary solution.
companies that want to be fast have to drive down transaction cost
For companies to be successful, they can no longer think of tech debt as an IT problem.
Removing this debt requires investment.
That investment comes from business.
What effect does this have on employees?
If they can't do what they need to, to be successful, they can't succeed
For employees, they do not want to work in these environments.
And they don’t have to.
We have to invest in a systemic approach to controlling this.
Some investments will be local, and can be done by the team
Others are at the program level : training, design
Yet others at the Enterprise level : mindset, involvement, commitment
Some investments will be local, and can be done by the team
Others are at the program level : training, design
Yet others at the Enterprise level : mindset, involvement, commitment
The answer is “no”, you’d invest in two areas – those that are important to you and those that improve the resale value of the house.
It is the same with technical practices. There are certain places you would invest the most money and some place where you might not invest at all – say on a system that was going to be decommissioned.
In fact, if you just invest without a strategy, you won’t get better.
Release Manager story “Continuous Delivery Everywhere”. Is that really a goal