Downloaded 20 times
Uploaded byagilemaine
Technical debt is a business problem - Bob Fischer
This document discusses technical debt as a business problem rather than just an IT problem. It defines technical debt as shortcuts taken that make future development slower or more difficult. Taking on technical debt can speed up delivery in the short term but it must be paid back over time. The business consequences of technical debt include slower time to market for new features, lower quality, higher costs, and difficulty attracting technical talent. The document provides examples of technical debt and recommends assessing where debt most impacts business outcomes in order to prioritize where to invest in reducing it. It emphasizes that managing technical debt is an economic decision and suggests using value stream mapping to identify critical speed and quality issues to address.
More Related Content
Similar to Technical debt is a business problem - Bob Fischer
Technical debt is a business problem - Bob Fischer
- 1. www.eliassen.com | 800.354.2773 WHYTECHNICAL DEBT IS A BUSINESS PROBLEM Bob Fischer REVISION: 1.3
- 2. • Why shouldI 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/
- 3. WHY SHOULD YOU CARE? HOWIS THIS RELEVANT TO BUSINESS CONCERNS 3
- 4. 4 FORTY SECOND BOYD Boydwould start with his competitor behind him In forty seconds Boyd would have the advantage
- 5. 5 BOYD’S OODA LOOP Observe OrientDecide ActBoydasserted that having a shorter cycle through the loop meant your competitor was forced to respond to you.
- 6. • Speed mattersmore 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
- 7. WHAT IS TECHNICAL DEBT? ANDHOW DOES IT COME ABOUT? 7
- 8. THE GOAL We wantto deliver value rapidly today while retaining the ability to deliver value rapidly in the future. Alan Shalloway 8
- 9. “Borrowing against our capacityto quickly respond tomorrow for the ability to make progress today” John Ryan Technical Debt 9
- 10. 10 HOW DOES TECHNICALDEBT ARISE? Shortcuts Poor Quality Longer time to Respond Pressure to Accomplish
- 11. WHAT ARE EXAMPLESOF TECHNICAL DEBT? Code that is difficult to understand or modify 11
- 12. WHAT ARE EXAMPLESOF TECHNICAL DEBT? Lack of automated tests 12
- 13. 13 WHY IS AUTOMATEDTESTING IMPORTANT? You need to confirm you didn’t break existing features When you add a new feature
- 14. WHAT ARE EXAMPLESOF TECHNICAL DEBT? Manual movement of software between environments 14
- 15. 15 ARCHITECTURES THAT IMPEDEENHANCEMENTS
- 16. • Not followingclean 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 DELIVERA 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 TECHNICALDEBT 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 talentyou want to hire has options • If you want to attract and retain good people, you must be competitively technically
- 20. AT SOME POINTIT IS TOO LATE FOR A COAT OF PAINT 20
- 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 EVERA JUSTIFICATION FOR TAKING ON DEBT? YES, BUT YOU HAVE TO PAY IT BACK 22
- 23. 23 AN EXAMPLE OFUSEFUL 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
- 24. WHAT ARE THE BUSINESS CONSEQUENCES? SLOWERTIME TO MARKET, WORSE QUALITY 24
- 25. HOLDING COSTS ANDTRANSACTION 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 HIGHTRANSACTION COSTS Two Days Coding One Day Testing Two Person-Months Regression Testing Two Days Release Management 26
- 27. EXAMPLE OF HIGHHOLDING 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
- 29. ISN’T THIS A TECNOLOGYPROBLEM? WHY DO YOU SAY THIS IS A BUSINESS PROBLEM? 29
- 30. ISN’T THIS JUSTA PROBLEM FOR IT? 30
- 31. 31 We came upwith a proposal for automated unit tests. We were told just to focus on features. We didn’t have time for improvement.
- 32. AT THE TEAMLEVEL 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 SLOWSYOU 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 SUPPORTIS 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 SHOULDSHOULD 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 potentialadd-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
- 37. WHERE DO YOUSTART? 37
- 38. 38 CORE APPROACH Where doesit 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 DEBTIS 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 MAPPINGTO DRIVE IMPROVEMENT Understand where you have delays and issues with end-to-end value delivery. Use this to improve speed and quality.
- 42. • Where wouldreducing 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.
Editor's Notes
- #2 Please note: The orange underline bar needs to extend just beyond the presentation title and should be manually adjusted.
- #5 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?
- #6 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.
- #10 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.
- #12 - 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
- #15 The ideal is having an environment that changes state versus moving code from environment to environment
- #16 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
- #22 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.
- #24 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.
- #26 companies that want to be fast have to drive down transaction cost
- #31 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.
- #32 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.
- #35 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
- #36 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
- #40 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.
- #41 Release Manager story “Continuous Delivery Everywhere”. Is that really a goal