SATURN 2019 Technical debt management as transparent communication hub Matthias Kittner Technical debt management as transparent communication hub 1
Who am I? Matthias Kittner • 8y Developer • 5y Software architect • 3y Enterprise architect Virtual prototyping software • Infrastructure architect Virtual Reality • Ask me … Physics simulation Technical debt management as transparent communication hub 2
Journey through the talk • Without technical debt management • Define the process • Explore the accumulated debt • Start to understand and communicate • Takeaways Technical debt management as transparent communication hub 3
SATURN 2019 Technical debt management as transparent communication hub I. Without technical debt management Technical debt management as transparent communication hub 4
Without technical debt management Release planning, a typical conversation … We need some time to fix the architecture! We have really a lot of issues. Rawpixels.com @ pexels.com We don‘t have time for that. We have a target and need the features! Tim Gouw @ pexels.com Technical debt management as transparent communication hub 5
Without technical debt management The other day … release planning II … We need feature X for the next release. This is very important! This is too difficult … Because … Rawpixels.com @ pexels.com But we will make it possible … …… We found a solution, but we really need to fix this later … Why does it take so long? Tim Gouw @ pexels.com Technical debt management as transparent communication hub 6
Without technical debt management Situation: misalignment & increasing debt • Frustrated developers – bad code and architecture • Frustrated product and project managers – bad surprises and slow development • Only diffuse information • Uncontrolled taking up of TD for short term goals • Big fear about the word Technical Debt Technical debt management as transparent communication hub 7
SATURN 2019 Technical debt management as transparent communication hub II. Define a process Technical debt management as transparent communication hub 8
Define a process Why do we need a technical debt management process • Because of our situation: misalignment & increasing debt • Financial or technical debt → it needs to be tracked • Transparency about our products/codes → we can act on it • Taking up technical debt • by accident → must not happen • by purpose → needs to be tracked • Ability to decide to remove on correct priorities Technical debt management as transparent communication hub 9
Define a process Defining the terms Unstable bridge: easy solution → “old and aging technology”? or “taken up naively”? • Technical debt reflects to the accumulated liability (=costs of additional rework and high code complexity) caused by choosing an easy solution over a better approach that would take longer. easy solution DEZALB from Free Photos @ canva.com Technical debt short-term goals better approach that would take longer long-term software quality requirements . • Technical debt can realistically never be 0 . • 3 categories https://bit.ly/2VmfBzE Temporary bridge: easy (but intermediate) solution → “by purpose”, “taken up strategically” Technical debt management as transparent communication hub 10
Define a process Defining the terms Unstable bridge: easy solution → “old and aging technology”? or “taken up naively”? • 3 categories • Taken up by purpose • Taken up naively DEZALB from Free Photos @ canva.com • Happened by age https://bit.ly/2VmfBzE Temporary bridge: easy (but intermediate) solution → “by purpose”, “taken up strategically” Technical debt management as transparent communication hub 11
Define a process Visibility Positive value Negative Value / Costs Bugs / Features Visible behaviour / appearance Defects Technical Invisible basis / foundation Architecture Debt Technical debt management as transparent communication hub 12
Define a process Cost Complexity Repay costs : • effort to fix it (=base debt + growth) Severity Interest costs : • additional effort • inability to deliver certain features • more effort to find bugs • high risk to create regression Contagion Interest on interest: • Increasing debt due to ongoing development • An exponential growth of the debt Technical debt management as transparent communication hub 13
Define a process Process Manage technical debt Decide what to tickets remove/fix (maintain the registry) (triage) Remove technical debt (dev project) Technical debt management as transparent communication hub 14
Define a process Rules & guidelines how to document TD • Use your ticket system • Describe the problem , not a task • Describe the implication of the problem separately • Justify , if technical debt is added by purpose • Propose a solution • Give the ticket the proper metrics ( severity, complexity, contagion ) Technical debt management as transparent communication hub 15
SATURN 2019 Technical debt management as transparent communication hub III. Explore the accumulated debt Technical debt management as transparent communication hub 16
Explore the accumulated debt Exploration • Fill the bucket • Hesitation Photo by Alice Pasqual on Unsplash Technical debt management as transparent communication hub 17
Explore the accumulated debt Exploration • Fill the bucket • Hesitation • Balance • Developers learning curve Photo by Leio McLaren (@leiomclaren) on Unsplash Technical debt management as transparent communication hub 18
Explore the accumulated debt Exploration Open issues • Fill the bucket • Hesitation • Balance • Developers learning curve • Quality Issues with missing fields Technical debt management as transparent communication hub 19
SATURN 2019 Technical debt management as transparent communication hub IV. Start to understand and communicate Technical debt management as transparent communication hub 20
Try to understand the full picture and communicate Prioritization Procrastinated big things Too much focus on low hanging fruits Temptation of low hanging fruits Distribution of contagion, severity and complexity in Technical Debt tickets opacity - # of tickets Technical debt management as transparent communication hub 21
Try to understand the full picture and communicate Now we have data Technical debt management as transparent communication hub 22
Try to understand the full picture and communicate Findings • Enterprise level debt → Who owns that? • How to communicate in the right way • Challenge of different ticket systems • Clear and simple metrics Technical debt management as transparent communication hub 23
Try to understand the full picture and communicate The good, the bad and the next Technical debt management as transparent communication hub 24
Try to understand the full picture and communicate The good, the bad and the next • Main codes covered, all teams adopted the process • After some iterations streamlined process • Teams stepped back to have a look at their legacy • Adoption and recognition, increased communication • Active part of release planning Technical debt management as transparent communication hub 25
Try to understand the full picture and communicate The good, the bad and the next • Iteration created some friction • Decreasing engagement after initial effort • Importance of essential ticket fields was not fully understood Technical debt management as transparent communication hub 26
Try to understand the full picture and communicate The good, the bad and the next • Establish the management process after initial effort • Ensure discipline in documenting TD taken up by purpose • Prevention and monitoring • Finally: Discuss, balance and decide what to fix and how Technical debt management as transparent communication hub 27
Summary • Misalignment & increasing debt • Process: Manage, decide, pay back • Fill the bucket • The full picture to decide and pay back • Establish the process sticky notes, various lists, database with weighted crowd knowledge and emails technical debt issues Technical debt management as transparent communication hub 28
Takeaways • TD management is necessary for transparency and to be able to communicate • A common understanding is fundamental for the process to function • The quality of the description and augmentation is essential for any prioritization or selection • Prioritization is important to not get overwhelmed with too many small things • The hard stuff is yet to come → refactor and fixing the issues Technical debt management as transparent communication hub 29
Questions? Technical debt management as transparent communication hub 30
SATURN 2019 Technical debt management as transparent communication hub Thank you Technical debt management as transparent communication hub 31
Recommend
More recommend
