“We know it’s broken…but we don’t have time to fix it.” “Yes, we know it could be better…but we’ll fix it when we get farther ahead.” “Yeah, it’s not great…but there’s other things we need to deal with, first”.
If you write code then you’ve probably encountered codebases that have been described just like those phrases. In fact, it’s such a common occurrence that there’s even a term for it: “Technical Debt”. Technical Debt is used to describe code that is so hard to work with or so difficult to maintain that it slows down the overall progress of the team.
But, debt doesn’t just happen to your code…it can also happen to your process. Ever had to track your time spent…across 3 different systems? Or, have you ever had to create excruciating detailed documentation for a feature after it was written just to satisfy an arcane reporting requirement of your organization? In either case, your organization was likely very aware of the waste that was incurred by the practice and probably even knew how to fix it. Maybe they knew that it wouldn’t take much effort at all to write a simple integration for those 3 separate time tracking system that would let you track your time once and publish it to the other 2 systems. Or, maybe they suspected that a feature’s test plan could perfectly fulfill that documentation requirement…if someone would only have the necessary conversation with the compliance team.
In fact, debt can even happen to your skills. Have you ever performed a routine task for the 100th time but couldn’t shake the feeling that there’s probably a better way to do it…if you could only had the time to try?
Whatever the reason, if you’ve ever found yourself or your organization performing at a lower level than you should be…simply because you can’t find the time to invest in improving…then you’ve experienced Capability Debt.
Capability Debt can be thought of as any point of friction in your team’s software development flow that ultimately slows down the delivery of great software. This could be redundancy within your organization’s process that the team must adhere to, regulatory overhead that the impedes the development process, or something that occurs in the act of creating software that everyone knows isn’t as good as it could be…but no one can find the time to fix.
Whatever the reason, the result is the same…wasted time and wasted effort in your team’s approach to delivering software to the market. But, just like Technical Debt, the answer is always the same whenever someone suggests addressing the problem…”we just don’t have time to fix that.”
In fact, often the situation is even worse than Technical Debt. Since Capability Debt is often inextricably wound into the DNA of the organization itself, many teams assume that the there’s simply no way to address the friction that’s occurring so they don’t even try.
But, luckily there is a way to address Capability Debt, and if you’ve ever addressed Technical Debt, then the approach should sound pretty familiar.
What’s the Problem?
First, you need to identify the problem and it’s downstream result. What is happening in the organization that’s slowing the team down and what effect is it having the broader organization?
In the case of the team tracking their time across 3 different systems, how much time is the team spending to do this? Is there an hourly burn rate for that team that can can put a dollar value on this debt or is there lost opportunity in the sense of work that the team simply doesn’t have time to tackle due to the time lost? However you measure it, there will be a cost involved with this effort. Find out what it is.
Where Did It Come From?
Next, you need to determine how you got here. More often than not, Capability Debt is the outgrowth of some process that had a historical basis within the organization in the past, but is no longer applicable to how the organization currently functions. Understanding the origin of a specific piece of debt can be very helpful in understanding how difficult it will be to address and who can can help you do so.
Pay It Back
Finally, once you understand what the debt is and how it arose you can build a plan to remove it. Maybe this will be a specific plan that addresses the debt once and for and all, or maybe this is just an experiment to try to solve the underlying issue that may or may not be successful. Either way, just like with Technical Debt, once you can put a specific number on how much the debt is costing your organization then you’ll be more prepared to invest in a specific plan to remove it.
Though Capability Debt arises from an organization’s overall process, it’s really no different than Technical Debt. While there are often perfectly justifiable reasons why the debt exists, if it’s not dealt with swiftly then its effects will continue to eat away at your team’s productivity. Investing in solving Capability Debt will keep your team performing at their top potential so they can keep delivering great software to market.
Want to learn more about solving common problems with delivery flow in your organization? Check out my course, Agile in the Real World, for tips and techniques for solving the most common impediments that you team may face.
Don’t have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.