This blog is the second in a series on the topic of technical debt. The content of this blog is based on Chapter 8 of my book Essential Scrum: A Practical Guide to the Most Popular Agile Process.
In a previous blog I classified technical debt as naive, unavoidable, and strategic. In this blog I focus on three approaches to managing the accrual of technical debt:
- Use good technical practices
- Use a strong definition of done
- Properly understand technical debt economics
Let’s examine each.
Use Good Technical Practices
The first approach for managing the accrual of technical debt is to stop adding naive technical debt to products. Naive technical debt is a form of technical debt that accrues due to irresponsible behavior or immature practices on the part of the people involved. Using good technical practices is an excellent starting point for avoiding naive technical debt. Example good technical practices include:
- Test-driven development (TDD)
- Test automation
- Continuous integration
- Refactoring
- Pair programming
- And so…
Failing to understand or use these technical practices will likely result in poorly constructed solutions that are defect-ridden, prone to failure, and hard to maintain and extend.
Use a Strong Definition of Done
Another important approach to managing the accrual of technical debt is to have a strong definition of done. Conceptually the definition of done is a checklist of the types of work that the team is expected to successfully complete before it can declare its work to be completed (potentially shippable in Scrum). Work that we should have performed when a feature was built, but ended up deferring until a later time, is an important cause of technical debt.
The more technically encompassing we make our definition-of-done checklist, the less likely we are to accrue technical debt. The cost of paying back technical debt that slips past a weak definition of done is substantially greater than addressing it during the sprint (since early debt compounds). Operating without a strong definition of done is like granting a license to accrue technical debt.
Properly Understand Debt Economics
To use technical debt strategically and advantageously, we must properly understand how it affects the economics of our decisions. Sadly, most organizations don’t understand the implications of technical debt well enough to correctly quantify the economics of taking it on. As a result they wrongly conclude that accruing technical debt is the proper thing to do.
An argument for accruing technical debt might be: “If we take on the debt and accelerate the product into the marketplace we will increase lifecycle profits by $500k; the cost of paying back the debt would only be an incremental $100k.” If these numbers were accurate, then it would appear sensible to take on $100k of debt to generate $500k of revenue. However, my experience is that most organizations don’t consider all of the relevant variables to properly quantify the economics when they intentionally take on technical debt.
Here is a sample of what would be involved in quantifying the economics. First we would need to determine what the benefit is of taking on the technical debt. Most organizations that take on technical debt do so to accelerate a product into the marketplace. So the benefit of the accelerated delivery could be quantified by calculating the cost of delay of not accelerating the product into the marketplace. Meaning, what would be the impact on lifecycle profits if we did not take on the debt and accelerate the product into the marketplace? There are many variables that factor into a proper cost-of-delay calculation (a topic for a future blog posting).
We would then need to consider the cost of taking on the debt. When calculating the cost it is very easy to miss important variables. Obvious things to consider are:
- Additional work we will have to do in the future to payback the debt
- Interest payments we will make on the debt until it is repaid
- The cost of delaying the development of future products or the next release of the current product. Think of it this way, the time required to perform the extra work in the future to repay the accrued debt delays us from working on these other products and they each therefore suffer a cost of delay.
As you can imagine, there may be many other not-so-obvious costs associated with accruing technical debt.
Of course, if the economics in favor of taking on the debt are overwhelming and compelling—for example, we will go out of business if we don’t take on that debt and get the product into the marketplace with all of the must-have features, or we will miss being first to market and lose the lion’s share of the marketplace revenue—we don’t need to spend time considering less important cost factors because we already know it’s economically sensible to take on the debt.
More often, however, the decision isn’t so clear-cut. The choice of whether or not to assume the debt usually requires detailed analysis to discern which is the better option. When deciding, err on the side of not taking on the debt. In my experience, most organizations substantially underestimate the true cost of assuming technical debt and aren’t nearly as diligent as they think they will be at repaying it.
Closing
The purpose of this blog posting is to discuss managing the accrual of technical debt—one of three activities for managing technical debt. In the next two blog postings in this series I will discuss the other two activities: making technical debt visible and servicing (repaying) technical debt.