Technical debt is inevitable in applications development and many organizations and teams struggle to manage it – when to take it on, when to avoid it and when and how to pay it down.

1. Death by technical debt:
lessons learned to get unburied
QA & Developer Joint Forum Event

2. SERIES SPONSORS

3. JAMES SHORE
Consultant, Author
The Art of Agile
@jamesshore

4. Debt
Counseling
1800GOAGILE
by Becky James

5. #surelytheremustbeoneanswer

6. #managersbringconstraints,
#debtfreewithoutmanagers

7. #oldnews, #boldstatement
#noteamcohesion
#itsalltheirfault

8. #unempowered, #overthewallthinking
#lacksownership, #actualquotes
I shouldn't have
to spend any of
my resource
pool on technical
debt that the
Development
teams
introduced.
Product Owner
Surely, we
don’t need
that much
time to fully
test the
feature – let’s
cut that
estimate in
half.
Developer
What do you
mean my
feedback is too
late…I just got
pulled into the
project
yesterday.
QA Engineer

9. #completetransformation,
#declaredbankruptcy

10. #empowered,
#teamsownsdecisions

11. #selforganizingteams, #nobystanders
#deliberatedecisions, #ownership
I own quality
and I own
keeping our
technical debt
under control.
Product Owner
I own quality
and I own
keeping our
technical debt
under control.
Developer
QA Engineer
I own quality
and I own
keeping our
technical debt
under control.

12. #theybringdonuts

13. Technical Debt
Death by Technical Debt:
Lessons Learned to get you Unburied
Product Owner Point of View
Todd Whitaker, Product Owner
Tripwire, Inc.

14. What is technical debt?
• Technical work that should have been
completed, but for whatever reason was not
and thus it is being “carried” in the
product/codebase.
• Analogies:
14

15. Technical Debt – This PO’s POV
If you are a product owner you should care about
technical debt.
If you work with a product owner, you need to
help him/her know why they should care.
15

16. How does it happen?
•
•
•
•
“Startup mode”
Time to market pressure
Inexperience
A natural side-affect of an imperfect median
16

17. Technical Debt – Points to consider
• +1 for not incurring it in the first place
• If it is being incurred, make it visible!
• In reality it happens and should be tracked
– Tracking too much becomes ineffective
• Developers are usually the most aware
• Others are impacted in many ways:
– Dev teams, Support, Prof Services, etc. and
customers!
17

18. Motivating your PO
• Make the PO aware of tangible effects and
benefits of addressing assign $
• Help him/her understand and quantify ROI
–
–
–
–
–
–
Performance (speed/throughput)
Improved dev team velocity
Faster time to market
More features in the release
Increased sales
Benefit to Prof. Services and System Engineers (sales)
• Be willing to let go if you cannot justify it.
18

19. Questions?
19

20. ADP Dealer Services
Technical Debt
Discussion
November 2013

21. ADP Dealer Services
21
FOCUS

22. ADP Dealer Services
22
PRODUCTS
LEAD MANAGER
DESKING
F&I
STOCKING
CRM
CREDIT
MENU
MERCHANDISING
COMPLIANCE

23. ADP Dealer Services
23
PEOPLE
37 SPRINT TEAMS
250+ ASSOCIATES

24. ADP Dealer Services
24
PROCESS

25. ADP Dealer Services
25
OUR TECH DEBT
STORY…

26. ADP Dealer Services
26
FIRST, THE OLD…
My Top 5 Favorites

27. ADP Dealer Services
27
1. Our application tips over every Saturday
2. We need to plan a hot fix after every release
3. We are scared to change ‘X’
4. Slow Releases
5. We Had to Roll Back the Release Because of
xyz.dll

28. ADP Dealer Services
28
1. Our application tips over every Saturday
2. We need to plan a hot fix after every release
3. We are scared to change ‘X’
4. We Can’t Release That for Another 10 Days
5. We Had to Roll Back the Release Because of
xyz.dll

29. ADP Dealer Services
29
1. Our application tips over every Saturday
2. We need to plan a hot fix after every release
3. We are scared to change ‘X’
4. We Can’t Release That for Another 10 Days
5. We Had to Roll Back the Release Because of
xyz.dll

30. ADP Dealer Services
30
1. Our application tips over every Saturday
2. We need to plan a hot fix after every release
3. We are scared to change ‘X’
4. We Can’t Release That for Another 10 Days
5. We Had to Roll Back the Release Because of
xyz.dll

31. ADP Dealer Services
31
1. Our application tips over every Saturday
2. We need to plan a hot fix after every release
3. We are scared to change ‘X’
4. We Can’t Release That for Another 10 Days
5. We Had to Roll Back the Release Because of
xyz.dll

32. ADP Dealer Services
32
Now the
New…

33. Culture Change
33

34. End
34

35. Technical Debt
Management
TAO Panel Discussion
Date: November 7, 2013
Presenter: Mark Menger
© 2012 Portland General Electric. All rights reserved.

36. People, …
 15 application delivery teams
 1 large scale project team
 Experience ranging from months to
decades
11/13/13
36

37. …Process, …
 Scrum
 Kanban
 Waterfall
11/13/13
37

38. …and Technology …
 .Net & T-SQL
 Java / WebSphere
 Datapower
 DataStage
 Oracle Forms & PL/SQL
 And others
11/13/13
38

39. Technical Debt Challenges
 Unacknowledged technical debt
 Unmanaged technical debt
 Vendor technical debt
 Knowledge debt
11/13/13
39

40. The importance of language
 Unplanned and planned work
 Committed work
 Cone of uncertainty
11/13/13
40

41. First steps out of the pit
 Introduce the concept at all levels
 Common term used by IT senior
management
 Don’t create more technical debt
 ScrumMaster / Product Owner
partnership
 Occasional topic at business
sponsor groups
11/13/13
41

42. Next steps out of the pit
 Improve fluency with the concept
 Informally capture technical debt
backlogs
 Expand upon success of SM/PO
partnership
 Document project end technical
debt
 Additional process measures (e.g.
code coverage)
11/13/13
42

43. Tech Debt
The NWEA Product Engineering Perspective

44. Recommendations
1. Change the language
• “Technical Debt” is “Business Debt”
1.
2.
3.
4.
Create owner and advocate for technical debt
Make the cost transparent (Get your CFO’s partnership!)
Create both initiatives and pre-allocated capacity
Invest in good design early
• Good design early beats Great design late
1. Be proactive

45. NWEA
•
•
•
•
•
•
•
Mission - “Partnering to Help All Kids Learn”
$100 Million Revenue
500+ Employees
Serve 7+ Million kids World Wide
42+ Million Assessments per year
100+ Engineers
Based in Portland

46. Our Challenge
• Scaling Web Applications
• High Capacity, High Transaction Volume
• High Concurrency
• > 1,000 moving to > 100,000 Concurrent Users
• Moving from Product to Platform
• Moving from Single Product to Suite
• Wrong Architecture
• Both Hardware and Software
• Built for one purpose, deployed for a different one

47. Technical Debt Definition
• “A confusing combination of black magic, voodoo, and
artifacts generated in the daily activities of Software
Developers, Technical Architects, System Engineers and
Operations of Technology Platforms, which is not readily
apparent to, or valued by, customers and business partners.”
• The Evil Twin of product “Features”
• The “Buzz-Kill” of Product Managers customer focus groups
and initiative funding meetings
• The “Hard Sell”

48. Examples
• The Obvious
• Hardware and OS Infrastructure EOL
• Legacy or EOL Software Frameworks
• De-supported Software and Hardware Platforms
• The Non-Obvious
• Short-Cut and/or Wrong Architecture and Design Decisions
• Lowest Bid Technology Acquisition (a.k.a the cheapest route is the
most expensive long term solution)
• The Prototype gone wild (a.k.a “Fast is Good”)
• The “Tent City” – Bad Urban Planning in Technology Architecture

49. Strategies to Manage Technical
Debt
1. Create an Initiative
2. Hide Capacity
3. Pass it to your Successor

50. Create an Initiative
• The Good
•
•
•
•
Full Organization Sign-up and Support
Focus
Resources
Targets
• The Bad
•
•
•
•
Need strong executive sponsor
Usually driven by pain not typical positive drivers
Seen as “Necessary Evil”
Must compete with customer facing, revenue generating, projects

51. Hide Capacity
• The Good
•
•
•
•
No negotiation required
Give engineers license to do this work
Self Protection
Less likely to be caught “out”
• The Bad
• Tough to keep in the priority work
• Needs internal governance and oversight
• Requires discipline

52. Pass it to your Successor
• The Good
• No management required
• No architecture and design required
• No negotiation required
• The Bad
• Can’t predict the timing of “The Crisis Point”
• Your tenure has limited time horizon
• Your infrastructure will fail (i.e. What color is your parachute?)

53. Recommendations
1. Change the language
• “Technical Debt” is “Business Debt”
1.
2.
3.
4.
Create owner and advocate for technical debt
Make the cost transparent (Get your CFO’s partnership!)
Create both initiatives and pre-allocated capacity
Invest in good design early
• Good design early beats Great design late
1. Be proactive

54. Q&A

55. SERIES SPONSORS