We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byNicholas Roach
Modified about 1 year ago
Michael Hall Three Beacons Managing Technical Debt Using Agile
Premise 2 © Three Beacons LLC, 2011 “All known compound objects decay and become more complex with the passage of time. Software is no exception.”
What is Technical Debt? 3 © Three Beacons LLC, 2011 “Technical Debt” term coined by Ward Cunningham in 1992 Also called “design debt” Choosing a design or construction approach that is expedient But increases complexity and is costlier in the long term
The Debt Metaphor 4 © Three Beacons LLC, 2011 Use a credit card to obtain something now Pay for it later - financial debt Plus interest (short term) (future payment due) (the cost of being able to do this)
Technical Debt 5 The consequences of: slapdash architecture poor design hasty coding (versus rapid) lack of quality focus others? The danger occurs when the debt is not repaid quickly. Every minute spent on not-quite-right code results in interest on that debt.interest © Three Beacons LLC, 2011
Technical Debt 6 T or F: all technical debt is bad and should be avoided at all costs. © Three Beacons LLC, 2011
Types of Technical Debt 7 © Three Beacons LLC, 2011 An outline to use when discussing technical debt 1.Unintentional 2.Intentional A.Short-term B.Long-term
Types of Technical Debt 8 © Three Beacons LLC, 2011
Technical debt quadrant 9 © Three Beacons LLC, 2011 INTENTIONAL UNINTENTIONAL RECKLESS PRUDENT “We don’t have time to mess with coding standards.” “There is a standard way of doing this?” “We will ship on time and revise the quick fix as our top priority in the next release.” “We now know what to avoid.” *
Technical debt quadrant 10 © Three Beacons LLC, 2011 * Short-term: Only if the commitment is there to schedule, prioritize, and fix soon (e.g. in the next sprint). Long-term: Only if the commitment is there to sponsor projects to resolve the debt. If you must take on technical debt for valid reasons, then “respect the asterisk”.
Cost of Technical Debt © Three Beacons LLC,
Technical Debt - impact 12 “The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.” - Jeff Atwood, Programming and Human Factorswww.codinghorror.com © Three Beacons LLC, 2011 CASE STUDY
Person Team Business Technical Debt – impacts 13 © Three Beacons LLC, CASE STUDY
Techniques for PREVENTING Technical Debt © Three Beacons LLC,
1. Draw the Line 15 © Three Beacons LLC, 2011 Culture shift: From this day forward … We no longer allow technical debt! Only exception: tactical or strategic business justification Even then, we “respect the asterisk” *
2. Strong “Definition of Done” Things to consider: Coding standards adherence Code reviews Static analysis Dynamic purification Complexity analysis Written unit tests 0 known bugs 100% test cases pass Test cases automated Etc. Visible for User Story Sprint Release © Three Beacons LLC,
3. Test-Driven Development TDD: write test, fail the test, then write code to pass the test. Refactor when needed. Develop higher quality streamlined code! © Three Beacons LLC,
4. Collaborative Designs Whiteboard sessions on design topics Leverage collective experience of the team Wisdom of the crowd User Design Studio Less reliance on subject-matter experts Etc. Increase the chance of an optimal design! © Three Beacons LLC,
Recap Draw the line! Strong definition of done TDD Collaborative designs © Three Beacons LLC, Use these agile techniques to help prevent technical debt
Techniques for Managing NEW Technical Debt © Three Beacons LLC,
1. Debt Backlog 21 © Three Beacons LLC, 2011 Used when technical debt is business justified Tracks debt by name Lists work tasks associated with each debt Includes an estimate Tracks the commitment to fix schedule Form: product backlog entries, separate Excel spreadsheet, special designation in defect DB, tool entry, sticky notes, etc. Helps to keep the debt service level visible! Track the debt as you go!
Debt Backlog - example 22 © Three Beacons LLC, 2011
2. Automatic Payment Plan 23 © Three Beacons LLC, 2011 Pay as you go Slow team’s velocity down to service the debt as it is incurred Include technical debt items in upcoming sprints As quickly as feasible In line with fulfilling commitment made when debt was justified Service the debt as you go! Keep it as close to $0 as possible.
3. Makeup Stories 24 “Makeup”: a story that apologizes to the code base And promises to fix it! Placeholder indicating non-user story work For when you incur technical debt For any reason you circumvented quality Use a different color card (red or pink is good) Add it to the product backlog Prioritize into next sprint (if possible) Good way to track technical debt. © Three Beacons LLC, 2011
Makeup Stories - example 25 © Three Beacons LLC, 2011
4. Adopt a Debt! 26 User Story Makeup Story © Three Beacons LLC, 2011 Good way to insure that makeup stories get worked. “Adopt” approach If a user story leverages the debt area, “adopt” the debt card as part of the user story effort Add the makeup story estimate into the user story
5. Dedicated Sprint to Service Debt 27 © Three Beacons LLC, 2011 Similar to a “bugfix sprint” Do this only if really needed Preponderance of business debt occurring during project Team concerned about debt growth Upcoming features rely on code that has debt Or, combine for a bugfix/debt sprint Periodically pay down your debt throughout the project!
Recap Debt backlog Service the debt commitment Makeup stories Adoption Dedicated debt sprint © Three Beacons LLC, Use these agile techniques to manage new technical debt
Techniques for Managing LEGACY Technical Debt © Three Beacons LLC,
1. Re-Do Project 30 © Three Beacons LLC, 2011 Business decides on a total re-design and re-write Happens rarely, hard to justify Hard for execs to see the value Often timed with new technology introduction How to insure that the new system is really better? Rigorous quality plan Strong Definition of Done Iterative development Feedback loops Inspect & adapt Watchful eyes Not an answer: “better people”
2. “Small Chunks” Approach Smaller chunks of effort In conjunction with normal dev flow Can work well across an API abstraction Often requires an architectural assessment Can require code changes to other parts of legacy base (risky) Happens more often than Re-Do projects Must insure end result is worth the effort! © Three Beacons LLC,
3. 70/30 Rule 32 70% - new user stories 30% - paying down the debt of a legacy system Rule can also be used to manage new technical debt Helps to have a PO with history of the legacy system Socialize that legacy improvements are part of this project! Ask for commitment Ask to be held accountable Do your part Ask others to continue the tradition © Three Beacons LLC, 2011
4. “While There” Rule While adding a new feature Any legacy function modified for the feature must be rewritten according to quality plan Variable names Coding guidelines Braces alignment Etc. Works well for support team also (while fixing bugs) CAUTION: may introduce bugs Final thought on case study: We improved almost 50% of the 4M LOC Significant drop in critical defects reported from customers But, we introduced at least 10 new bugs on existing functionality Each time – required additional justification to continue the effort © Three Beacons LLC,
Recap Re-Do project Small chunks approach 70/30 rule “While there” rule © Three Beacons LLC, Use these agile techniques to manage legacy technical debt
Conclusion © Three Beacons LLC,
36 © Three Beacons LLC, 2011 “Developers know their code has technical debt, but they feel powerless to stop adding to it.” – David Rooney, “Technical Debt: Challenging the Metaphor” A Sobering Thought There is hope – using Agile.
37 © Three Beacons LLC, 2011 “Take my advice: go well, not fast. Care about your code. Take the time to do things right. In software, slow and steady wins the race; and speed kills. – Robert C. Martin (Uncle Bob), president of Object Mentor and agile methods author Managing Technical Debt - conclusion
Good References 38 © Three Beacons LLC, 2011
Questions? Hemant Elhence, Agile Software Product Development Partner 39 Short/Long term Agile coaching Facilitated improvement Agile Methods training: Scrum Team Training Agile / Scrum User Stories – Requirements w/ Agility Product Owner Role ScrumMaster Role Etc. All courses can be delivered onsite at your location Michael Hall, © Three Beacons LLC, 2011
Confidential Synerzip in a Nut-shell 1. Software product development partner for small/mid- sized technology companies Exclusive focus on small/mid-sized technology companies, typically venture-backed companies in growth phase By definition, all Synerzip work is the IP of its respective clients Deep experience in full SDLC – design, dev, QA/testing, deployment 2. Dedicated team of high caliber software professionals for each client Seamlessly extends client’s local team, offering full transparency Stable teams with very low turn-over NOT just “staff augmentation”, but provide full mgmt support 3. Actually reduces risk of development/delivery Experienced team - uses appropriate level of engineering discipline Practices Agile development – responsive, yet disciplined 4. Reduces cost – dual-shore team, 50% cost advantage 5. Offers long term flexibility – allows (facilitates) taking offshore team captive – aka “BOT” option © Three Beacons LLC, 2011
Confidential Synerzip Clients © Three Beacons LLC, 2011
Thank You! Michael Hall Hemant Elhence Agile Software Product Development Partner Call Us for a Free Consultation! 42 © Three Beacons LLC, 2011
Architecture in an Agile Organization Managing our Software as a Valuable Asset while Delivering Incrementally Chris Sterling Principal Consultant, Certified.
Software Development QA Best Practices May 20, 2010 Suzette Hackl, CSM Senior Project Manager Skyline Technologies, Inc.
An HML white paper: Agile IT A value-driven approach to IT delivery.
Tactical Product Ownership day 1: product scope and planning Jeff Patton AgileProductDesign.com
Project Management Dr. Anbang Qi Prof. of International Business School of Nankai University.
The right tools for the job How to choose a web / bespoke development company.
Extreme Programming > an agile methodology < Mark Kilby / SAIC Steve Raulerson & Matt Weber / CONVERGYS June 2002.
1 GREY BOX TESTING Web Apps & Networking Session 10 Boris Grinberg
Neil B. Harrison Utah Valley University. Who Who And a bit of history What we are doing What we are doing Creating a pattern language of Scrum A few words.
Chapter:4 Principles That Guide Practice Unit II.
Extreme Programming Patrick Mattis Alana Trafford Akarsh Sakalaspur.
Knowledge in implementing/managing the IS/IT project CASE-The Brose Group Implements Page
MFG Assessment Application: Assessment Criteria and Metrics 1 Performance assessment criteria and metrics may be used as the basis for determining the.
Insert Local Authority Transformation Strategy Workshop Insert date This document is part of the personalisation toolkit
Berling Associates, Inc. 1 T.E.A.M. EFFORT A Primer on Process Management (A View From The Improvements Team Perspective)
Introduction to knowledge management. What is knowledge management Knowledge management can be difficult to define, because it encompasses a wide range.
A Publication of Bridgemark Solutions Six Keys to Generating More Sales Leads AND WINNING MORE MARKET RESEARCH PROJECTS.
Basic SDLC Models. Agenda SDLC definition Waterfall SDLC V-Shape SDLC Spiral SDLC RUP SDLC Agile methods.
ICAA5151B GATHER DATA TO IDENTIFY BUSINESS REQUIREMENTS.
Introduction to Project Management session 1. Project management Over the course we will look at: Projects and their features. The project Life Cycle,
Quality Tools and Techniques in the School and Classroom.
Test Driven Development What Works & What Doesnt November 5, 2008.
Notes accompany this presentation. Please select Notes Page view. These materials can be reproduced only with written approval from Gartner. Such approvals.
1 Film Project Management Olga A. Burukina, PhD Associate Professor Project Management Department NRU HSE Moscow, March 2014.
ATMAN HB summary seminar # Challenges 2 ATMAN project 9/17/2010.
Introduction New Form Stage 1 Stage 2 Stage 3 Feedback Conversation Career Development SMART Goals Competency Framework Documents There are also links.
Unit-V -SOFTWARE QUALITY. To develop and deliver robust system, we need a high level of confidence that Each component will behave correctly Collective.
CSE 6324: Advanced Topics in Software Engineering Paper Presentation on An Overview of Security Practices in Agile Software Development - Naieem Khan.
9/4/20141 Iterative Project Management Chapter 2 – How Do Iterative Projects Function? Iterative Project Management / 01 - Iterative and Incremental Development.
© 2016 SlidePlayer.com Inc. All rights reserved.