My last post this year will be about technical debt and how to visualise it using Cost of Delay.

Technical debt can be results of your own decisions: shortcuts taken consciously with good intention, customer focus and a clear plan to “go back and fix that later” in mind.

But technical debt can also be much more complex and difficult to pay back. Having to “clean-up” from someone else’s poor implementation is much harder from a motivation perspective.

We inherited a technical platform that does not meet our current requirements, which consequently has caused a mountain of technical debt. And since dealing with the debt would require a large effort it would often get lower priority than smaller features with clear business value.

We tried to take a Cost of Delay approach to get numbers that would be easier to communicate and discuss. The semantic fits well since solving technical debt usually won’t result in a direct value for the customer. Solving technical debt would save money and we could in many cases quantify how much savings per month, and therefore give a clear cost of delay.

We also identified two different cost of delays for technical debt:

Direct: the cost for keeping existing platforms with regards to licenses, hosting and maintenance. These are good since they are easy to communicate. Like “using platform X that we don’t need costs us Y every month”.

Indirect: but then we have the indirect costs of delay for technical debt and this is more difficult to visualise. Indirect costs are:

• Extra time and effort needed to develop new features that depend on the technical debt, that is the negative effect on lead time. This can be quantified with a factor describing how much longer time to market is for related stories. Like “every story in area N depends on technical debt D and will therefore take M times longer”.
• Team frustration from having to maintain poor-quality codebases and lack of motivation to spend time with non-value-creating tasks caused by monolithic enterprise platform architectures instead of being able to just write value-producing code and ship it immediately.

In our case the indirect costs are the true drivers. However, by quantifying the direct cost of delay we get the well needed sense of urgency.