This post is Part 2 in a two-part series on technical debt. If you haven’t done so, read my first post, Prioritizing Tech Debt in Your Agile Planning Process.
It’s all well and good to prevent incurring technical debt in the first place, but many times the ship has already sailed on prevention. We often find ourselves on a team haunted by the decisions of engineers past or with a new product person who didn’t participate in the original agreement to balance debt pay-down with implementing new features. We then find ourselves in the release planning process having difficult discussions on how to balance repaying tech debt with the delivery of new features.
To solve the predicament, put the situation in terms that matter to your audience. What matters to your product person (and the folks he or she answers to) is the value of the work.
Clean code is not a sufficient business justification to pay down tech debt. Why?
Clean code is not simply about an environment that is pleasant for developers. It’s also about an environment that can be maintained with reduced cost and risk for the business.
So if you have a tech debt mess and you need to make a case to refactor it, do a little homework to frame it in the terms that matter most to your business. Remember: one of the core tenants of product management is the business value of the team’s work. If you give your product person the tools they need to justify the business value of reducing tech debt, it will make the prospect of getting that investment more likely to happen.
Before I knew how to ask better questions about tech debt, engineers would come to me with requests focused so much on the “what” and so little on the “why” I didn’t know what I was saying “yes” or “no” to. That’s ok to the extent that we need to trust the engineers to be the experts on engineering.
However, the product person’s role is to make priority and trade-off decisions, essentially, the high-level understanding of what the team is investing in and why. During my time as a product manager, I’ve identified a four-step framework for developing this understanding, which helps make the case to pay down technical debt and helps with work prioritization overall.
1. Define a current state.
“We’re two major versions behind” is a good start, but giving more quantitative information about what that means for the product is better. Questions to ask include:
- Are there defects that can be resolved if we upgraded versions?
- Is that version is going to be sunsetted in several months?
- Are there security vulnerabilities introduced by being on the older version?
When you are more specific about the current state of the product you are supporting, your case to address the issue is more meaningful.
2. Explain the value of doing this work now and the risk of not doing it now.
This can be one of the more critical questions for an engineer to ask themselves. Once you begin considering the actual costs of delaying tech debt work, you start considering your options in a way that can break them down meaningfully.
“Ideally, we would upgrade this library now to gain access to the newly released features, but as long as we upgrade before the end of the year when they end support of this version, we’ll be ok.”
3. Break down the investment request from the expected return for that investment.
This is a little more nuanced than simply estimating what it will take to do all the work. Especially in the case of inherited tech debt, you are sometimes starting from a place in which the scope of the problem is not entirely transparent.
To maintain trust, it becomes super important to avoid making promises you can’t keep with your product people. You might say, for example, “We want to invest in an x-sized spike story to test how a portion of our code behaves with the new library. From that, we expect to identify any major compatibility issues involved in upgrading altogether.”
4. Last, break down the knowns and unknowns about what you are proposing.
If you know exactly what needs to be refactored, why, and its impacts, this step is unnecessary. However, depending on things like how long the debt has been accumulating and how much knowledge there is about how it originated, you may not know enough to estimate what it will take to eliminate it all reliably.
It’s crucial to explicitly call out what you do or do not know about the debt. If you aren’t clear on your “knowns” and “unknowns,” it will be tough to make a case for additional investment if, once you dig in, you find that there is more work to be done.
Start Talking About Tech Debt in Practical Terms
Product people will often choose new features over paying down tech debt. It’s true. This is at least partly because new features have a value presented to them in clear and evident terms.
If you follow the above steps, you will provide more context to the value of reducing tech debt to your product team. It will also keep you honest about what tech debt investments you can justify. With more transparency about managing tech debt in the product you support, you can build the trust needed to leverage tech debt in a healthy way.
Read my first post on this topic to learn more about Prioritizing Tech Debt in Your Agile Planning Process.
For more about agile and Clarity and Rally Software, visit ValueOps on the Broadcom Enterprise Software Academy.
