Technical Debt Management as Transparent Communication Hub · 2019. 5. 10. · Technical debt management as transparent communication hub. 29. Takeaways • TD management is necessary

1Technical debt management as transparent communication hub

SATURN 2019

Technical debt management as transparent communication hub

Matthias Kittner


Who am I?

Matthias Kittner

• 8y Developer

• 5y Software architect

• 3y Enterprise architect

• Infrastructure architect

• Ask me …

Virtual prototyping software

Virtual Reality

Physics simulation


Journey through the talk

• Without technical debt management• Define the process• Explore the accumulated debt• Start to understand and communicate• Takeaways


SATURN 2019


I. Without technical debt management


Release planning, a typical conversation … Without technical debt management

We need some time to fix thearchitecture!We have really a lot of issues.

We don‘t have time for that.We have a target and needthe features!

Rawpixels.com @ pexels.com

Tim Gouw @ pexels.com


The other day … release planning II … Without technical debt management

This is too difficult …Because …But we will make it possible …

Why does it take so long?

We need feature X for thenext release.This is very important!

We found a solution, but wereally need to fix this later …

……

Rawpixels.com @ pexels.com

Tim Gouw @ pexels.com


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

Without technical debt management


SATURN 2019


II. 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

Define a process


• 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.

• Technical debt can realistically never be 0.

Defining the termsDefine a process

easy solutionshort-term goals

better approach that would take longerlong-term software quality requirements.

Unstable bridge: easy solution→ “old and aging technology”? or “taken up naively”?

Temporary bridge: easy (but intermediate) solution→ “by purpose”, “taken up strategically”

Technical debt

• 3 categories

DEZALB from Free Photos @ canva.com

https://bit.ly/2VmfBzE


• Taken up by purpose

• Taken up naively

• Happened by age

Defining the termsDefine a process

Unstable bridge: easy solution→ “old and aging technology”? or “taken up naively”?

Temporary bridge: easy (but intermediate) solution→ “by purpose”, “taken up strategically”

• 3 categories

DEZALB from Free Photos @ canva.com

https://bit.ly/2VmfBzE


VisibilityDefine a process

Features

Architecture

Bugs /Defects

TechnicalDebt

Positive value NegativeValue / Costs

Visible behaviour / appearance

Invisible basis / foundation


Cost

Repay costs:• effort to fix it (=base debt + growth)

Interest costs:• additional effort• inability to deliver certain features• more effort to find bugs• high risk to create regression

Interest on interest:• Increasing debt due to ongoing development• An exponential growth of the debt

Define a process

Complexity

Severity

Contagion


ProcessDefine a process

Manage technical debt tickets(maintain the registry)

Decide what to remove/fix(triage)

Remove technical debt(dev project)


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)

Define a process


SATURN 2019


III. Explore the accumulated debt


Exploration

• Fill the bucket

• Hesitation

Explore the accumulated debt

Photo by Alice Pasqual on Unsplash

https://unsplash.com/photos/Olki5QpHxts?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText

https://unsplash.com/search/photos/debt?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText


Exploration

• Fill the bucket

• Hesitation

• Balance

• Developers learning curve


Photo by Leio McLaren (@leiomclaren) on Unsplash

https://unsplash.com/photos/flEStjHTY14?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText




https://unsplash.com/search/photos/balance?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText


Exploration

• Fill the bucket

• Hesitation

• Balance

• Developers learning curve

• Quality


Open issues

Issues with missing fields


SATURN 2019


IV. Start to understand and communicate


PrioritizationTry to understand the full picture and communicate

Too much focus on low hanging fruits

Distribution of contagion, severity and complexity in Technical Debt ticketsopacity - # of tickets

Temptation of low hanging

fruits

Procrastinated big things


Now we have dataTry 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

Try to understand the full picture and communicate


The good, the bad and the nextTry 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




• Iteration created some friction

• Decreasing engagement after initial effort

• Importance of essential ticket fields was not fully understood




• 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



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, crowd knowledge and emails

database with weighted technical debt issues


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


Questions?


SATURN 2019


Thank you

Documents

Technical Debt Management as Transparent Communication Hub · 2019. 5. 10. · Technical debt management as transparent communication hub. 29. Takeaways • TD management is necessary