FUBAR inside. About visualising and attacking Technical Debt

What is Technical Debt?

Technical debt reflects the cost of additional rework caused by choosing a quicker or easier solution instead of using a better approach that would take longer. In many cases caused by business pressure and/or insufficient up-front definition. See Wikipedia for all the common causes.

Why is Technical Debt a problem?

Technical Debt leads to increasing Cost of Change and decreasing Customer Responsiveness (graph source: DASA)

Companies already need to be fast in order to deal with their competition and with rapidly changing customer needs. And they will need an unprecedented acceleration in the coming decade. While many companies have already exhausted much of their software manoeuvring possibilities. Their need for speed will be blocked by FUBAR’s.

What is FUBAR?

FUBAR is an acronym that originated in the military to stand for the words "F***ed Up Beyond All Repair.” And that is exactly what will raise its ugly head if a company ignores technical debt for too long: FUBAR software parts. Or even worse, a FUBAR core.

The Software Decay Spectrum (graph source: IfSQ), shows why you reach the FUBAR stage sooner than you expect: software deterioration follows a hockey stick curve.

But why are companies moving towards uncontrolled upheaval? The main reason is that increasing Technical Debt is considered a normal part of the software game. And the second reason is that there was not a way to visualise decision-making related to technical debt.

Visualising problems helps. And Technical Debt is no exception 

Brian Teunissen published his ‘Producing Milk or Shoveling dirt’ article initially in 2014. He introduced the 5 colour backlog, which I have been showing a lot at management level to convince those in charge that it is not a blue (features) and yellow (defects) world only. You have to add red (reducing technical debt) and green (improving processes) to reach a structurally sustainable situation. 

SAFe 4.6 was launched in fall 2018 and contains 4 Lean Budget Guardrails describing budgetary, governance and spending policies and practices for the lean budgets allocated to a specific portfolio. Guardrail 2 is about 'Optimising Value and Solution Integrity with Capacity Allocation’. It provides the ideal opportunity to devote resources and hours to deal with Technical Debt and Maintenance structurally. Graph source: Scaled Agile.

In November 2018 Mik Kersten published his brilliant book ‘Project to Product’. In his foreword, Gene Kim compares the switch towards the Flow Framework to the transition from Copernican to Newtonian physics. Mik Kersten introduces 4 Flow Items: Features (green), Defects (red), Risks (orange) and Debts (blue). And the term Flow Distribution that is defined as “the proportion of each flow item within a value stream, adjusted depending on the needs of each stream to maximise business value”. The Flow Distribution Timeline shows how Flow Distribution is varying over time, like taking down some technical debt at the start of a release to accelerate feature flow toward the end of it. See https://projecttoproduct.org for additional information. Graph source: Tasktop.

3 statements

I would like to conclude with 3 statements. 

1. It is impossible to keep delivering features without simultaneously dealing with Technical Debt. Digital transformation can only be successful while reducing Technical Debt at the same time.

2. Technical Debt is not something you can choose to work on. You HAVE to work on it. To avoid FUBAR’s, to get rid of FUBAR’s that you already have created and to detect FUBAR’s that you never expected to have.

3. In the IT world, Technical Debt is the most important, financially most uncertain, yet hidden problem.

Jan de Vries works as a consultant at IT Management Group