There are two kinds of debt in the average software project that an agile team will worry about. The first is technical debt and the second is logistical debt.
Technical debt refers to the concept of work required to make a change which is not directly related to the change being made. Another way to view it is by counting work not done now as technical debt for later. This is generally in the form of choosing an easier but more limited solution to make a change now which makes altering the functionality later take longer than if a more complex solution was implemented.
Logistical debt, as I’m using it, is the number of items requested over time, the documentation around the product, process enhancement ideas, and any metrics that have been collected over time. These might appear as a large backlog, large pdfs, or charts that go back more years than the team has been in its current form.
Just because we’re talking about debt doesn’t mean it’s all bad. As with many choices in a project, there are benefits and risks on both sides of the equation. Preventing debt generally requires longer lead times at the outset which can slow a product’s time to market. Taking on some debt may be necessary to get moving on a new product. However, letting this debt grow unchecked can result in a product which it doesn’t make sense to improve in the future, resulting in lost customer confidence when the product is replaced instead of enhanced.
Technical debt isn’t a new concept. It slows a team down over time. The more that accumulates, the more it slows the team down. In extreme cases, which are more common than we like to admit, it becomes so difficult to make changes dropping everything, and starting over is actually easier and faster. Except it’s never easy to drop everything and start over. Between sunk cost fallacies and the elusive solution just around the corner realizing a product has reached this point is extremely difficult.
Preventing technical debt is not a completely solved problem, but there are ways to limit it. From automated testing to rigorous standards for implementation it isn’t impossible to make things easier to change later. In software projects specifically creating functionality as components that can be independently tested and validated through automation means making a change will result in fewer hidden consequences. Any problems will immediately show up in failed tests and tracing them back to a root cause should be much easier than tracing a random bug.
Logistical debt is something I have not heard a lot of people spend much time on. This is interesting to me because the concept of backlog bankruptcy, one great tool for dealing with it, is not new. Logistical debt isn’t only about a huge backlog though. If updating a feature includes months of revising documentation there could be a problem. When senior leadership pulls out a velocity graph going back five years and has questions, there definitely is a problem.
Backlog bankruptcy is the concept of deleting a backlog, or a large portion of it, without exception. It is generally done when a team or organization realizes and accepts that the backlog is larger than they will finish in any reasonable amount of time or that there are many items on it that are no longer relevant. While one may argue it will likely just grow that large again, in practice things that really weren’t that important don’t make their way back onto the backlog and people in charge of the backlog tend to become more protective of what is allowed onto it after this experience. Even if it grows again, the cognitive relief and long lead time before it grows again are generally worth it.
Other types of logistical debt can be dealt with in similar ways. If documentation has gotten out of hand, try splitting it into smaller pieces or, even better, simplifying it greatly. (Perhaps it’s a sign your solution has also gotten too complex?) Limit metric tracking and reporting to relevant time frames, and make sure people understand what the metrics they’re tapping into mean.
Regardless of what kind of debt is weighing your project down, declaring bankruptcy on it and moving forward fresh is an option with considering.
If your team or organization is struggling I can help. Contact me now to set up a free initial consult. We’ll discuss what the symptoms are and come up with a plan of attack for me to help diagnose the true problem and devise a solution.
The term bankruptcy has a bad reputation in the business world. This is not surprising considering one definition of it: utter failure or impoverishment. Another definition centers around an inability to repay debt, and that’s the one we want to focus on here.
