What Is Technical Debt in Agile?
As Bob Fischer points out in a recent blog post, Technical Debt is a Business Problem, “technical debt is rarely understood by non-technical business people.” So the question is: How do you go about having a productive conversation that enables non-technical people to appreciate the need to actively and continually keep technical debt low?
My solution is simple: keep it visual.
We begin by assuming that we have a set of similarly-sized features represented as small blocks laid out horizontally. Next, we add a timeline under the blocks to illustrate that reading the blocks from left to right represents delivery over time. In situations where no technical debt is being incurred, there is consistent delivery, with no variability in the length of time it takes to implement each feature.
However, things shift dramatically when technical debt is being accumulated. What does the following diagram tell us?
In practice, using this diagram has provided me all the key talking points on the impact of technical debt that I’ve ever needed.
Technical Debt and Agile: Why It Matters
Agile is all about rapidly adapting to change, however, the presence of technical debt constrains our ability to quickly adapt a software product (or system). Consequently, the blocks start to stretch out as time moves on, which represents that it is taking longer and longer to implement what should be equally-sized features.
As technical debt increases, my experience is that the ability to adapt decreases exponentially, which is why the line representing “Product Adaptability” arcs downward. Conversely, as the level of difficulty to add features increases, it becomes costlier to do so, so we add a “Product Cost” line arcing up to represent the exponential increase in costs. The place where the two lines cross indicates the point at which it becomes prohibitively expensive to add new features, and ROI is directly impacted. No one wants to hear what can – and does – happen if too much technical debt piles up: developers will declare, “We can’t add any more features to this system, it needs a complete re-write!”
The last point about technical debt that this diagram helps to illustrate is that early on, the effects are less pronounced, and it’s easy to dismiss technical debt as a mild concern. There will be subtle clues that it is present, like defects beginning to pop up as new features are added, and those features beginning to take a little longer to implement. But these issues are typically viewed as being easily overcome, and with a little extra effort, they are… at least for a while.
To sum it up, there will always be a desire for the faster delivery of business features. But when it comes to running your business on IT, there needs to be an informed and constructive dialog between the business and IT. As the ninth principle of the Agile Manifesto states, “continuous attention to technical excellence and good design enhances agility.”(1) If software design starts lagging behind feature implementation, it will make features more difficult and costly to implement in the future, and this diagram proves it to those non-technical folks unable to see it.
Are you ready to reframe your technical debt? Assess your progress with our Devops Maturity Matrix Tool, and learn more about how we can help you with DevOps.
1. "Principles behind the Agile Manifesto." Agile Manifesto, http://agilemanifesto.org/principles.html. Accessed 17 May 2018.
