Technical & Product �Debt Management

50 %
50 %
Information about Technical & Product �Debt Management

Published on June 14, 2016

Author: ssunduko

Source: slideshare.net

1. Technical & Product Debt Management By Dr. Sergey Sundukovskiy

2. Introduction Sergey Sundukovskiy, Ph.D. Head of Engineering - Technology Innovation at Capital One Current: Capital One, Google, 500 Startups Previous: Launchpad LA, PushPoint, LivnGiv

3. “… A design or construction approach that is expedient in the short term but that creates a technical context in which the same work will cost more to do later than it would cost to do now (including increased cost over time).” 3 Debt

4. Everything You Want to Do “Later” Is DEBT • Let’s Document Later • Let’s Test Later • Let’s Architect Later • Let’s Refactor Later 4 Debt

5. Technical Debt Results Product Debt Things SLOW DOWN

6. • All Debt Is Bad • No Debt Is Great • Taking On Debt Always Gets You There Faster 6 Debt Misconceptions

7. Technical Debt Story I Have Not Seen Organs Like These

8. CEOs Tale • We were very productive • We kicked ass • We became complacent • I fired them all • I hired a new team • They are not productive either • Must have chosen wrong • I fired them all • SAVE ME 8 Common Story

9. CTOs Tale • We were very productive through debt accumulation • We kicked ass but burned out • We slowed down due to increasing debt support • We got fired • New team got hired • It does not know where skeletons are buried • We got fired as well • I have Not Seen Organs Like These 9 Common Story

10. Support Cost is a Euphemism for Debt Support (15%) Innovation (85%) Support (50%) Innovation (50%) Support (85%) Innovation (15%) Year 1 Year 2 Year 3 Support to Innovation Ratio

11. Leveraging Debt Continued

12. • Time to Market – If taking on debt gets you to market disproportionately faster • Time to Contact – If strategic contract is at stake debt might be worth it • Time to Funding – If funding is at stake debt might be worth it • Time to Survival – Debt is irrelevant if there is no tomorrow Leveraging Debt

13. • Non-Leveragable Debt • Debt Due to Ignorance • Debt Due to Laziness Unacceptable Debt

14. Technical Debt Survey

15. Technical Debt Elements • Lack of Architectural Blueprint • Lack of Unit Testing • Lack of Integration Testing • Lack of Code Reviews • Lack of Starter Platform • Lack of Starter Framework • Lack of Technical Design • Lack of Development Recipes

16. How Did We Let It Happen? One Logical Step at a Time

17. Broken Window Theory One Broken Window Leads to Ruin

18. Broken Window Theory Do Sweat the Small Stuff Small Vandalism Urban Decay CRIME

19. Debt Tipping Point Product Death Year 2 Year 1 Tipping Point

20. Debt Creeps Up on You Yup, It is Kind of Like That No Turning Back Now! The Snowball Effect SPLAT!

21. Debt Management Regular, Slow and Steady Does It

22. Technical Debt Management Technology Debt Management and Debt Avoidance • Build on Top of IaaS/PaaS • Build on Top of Starter Product/Starter Framework • Implement Unit/Integration/Functional Testing • Conduct Code Review • Implement CI/CD/CD • Establish Short Sprints (Agile) or No Sprints (Kanban) • Non-Monolithic Design

23. Product Debt Yup, That’s Feature Creep

24. Featuritis Curve Number of Features UserHappiness Happy User Peak “I rule!” “Cool!” “I’m so glad they added this.” “Nice, but I wish I could do more…” “Guess I better look at the manual…” “Hey, where the f*** did they put that?!” “Now I can’t even do the ONE SIMPLE THING I bought this for…” “I suck!”

25. Features Usage

26. What is Product Debt? Product Debt = Product Complexity = User Confusion

27. Multiplicative Complexity N(N-1)/2 – Undirected Graph N(N-1) – Directed Graph

28. Ease of Use Main Feature = Easy to Use

29. Irreducible Complexity Simplest Mousetrap

30. Product Feature Attributes Intelligent Design and Evolutionary Concepts • Aim For Adjacent Possible Irreducible Complexity • Can’t Take Anything Away • Can’t Be Simpler Simplest for What It Does • Simple Path to Intent

31. 31 Path to Intent Straightforward Path to Intent

32. Feature Payments Feature Currency • Confusion “Payment” for Features What Do They Mean? • “This Is Confusing” Ideal Feature • Minimal Confusion • Minimal Multiplicative Complexity

33. 33 Features Confusion Ideal Balance Realistic Balance Feature Payments

34. • Do Not Complicate Things • Do Not Make Users Think • Do Not Make Users Work • Do Not Defy User’s Expectations • Do Not Confuse Yourself With Users • Do Not Assume You Know Everything 34 Product Debt Don’ts

35. 35 Always Be Testing

36. 36 Painted Door Painted Door vs. Real Door

37. Product Debt Management and Debt Avoidance • 30% of the Sprint Should Be Devoted to Feature Removal • Test Before You Implement • Collect User Feedback • Measure and Correlate Churn • Assess Complexity and Confusion 37 Product Debt Management

38. Not The Same Thing Management Mitigation

39. 39 Selling Debt Mitigation

40. Debt Mitigation Is Very Hard To Sell • Cause and effect is not immediately apparent • ROI is very difficult to quantify • Definition of done is hard to come up with • Perpetual projects are not crowd pleasers • Users are not even aware that backend of apps even exists. UX/UI in user’s mind is the app itself 40 Debt Mitigation Advice

41. If You Can Help It, Do Not Sell It • Schedule feature holidays (every 5th release) • Refactor as you go • Make debt mitigation as part of the process • Give estimates considering debt mitigation • Invite outside experts If You Must Sell It • Tell CEO/CTO story • Use aircraft maintenance strategy 41 Debt Mitigation Advice Continued

Add a comment