Chances are your agile development team struggles with addressing technical debt. That is unless you work for a ground-floor startup with a cloud-native microservices architecture engineered during the past few years. The rest of us have technical debt embedded in our applications, services, databases, and infrastructure that ranges in size, risk, complexity, and business impact.
Technical debt impedes teams from developing new features, enhancing customer experiences, addressing security issues, improving reliability, increasing performance, automating workflows, and addressing other business priorities.
What is technical debt?
The definitions and significance of technical debt vary. On the lower end, it can be a small area of code that requires refactoring, libraries that need upgrading, or unit testing that needs fixing. On the higher end, technical debt includes reengineering complex monolithic applications, porting outdated web service protocols, consolidating multiple platforms to one standard, cleansing data debt issues, modernizing infrastructure, introducing observability practices, or automating a backlog of manual test cases. The worst type of technical debt is burning platforms with recurring outages and incidents that impact the business.
My simple definition of technical debt is when technologies running in production require fixing, refactoring, modernizing, upgrading, reengineering, or replacing before or as part of implementing the strategic business requirements.
How technical debt impacts agile development teams
Here’s the conundrum facing agile and scrum teams that want to address technical debt. Although there are many approaches to how organizations adopt agile, most agile methodologies require assigning a product owner the responsibility to prioritize the backlog based on customer and stakeholder needs.
In the best scenario, product owners will listen, learn, question, and partner with their technology teams to address technical debt. Ensuring technical debt is prioritized requires product management groups (including product managers and owners) to consider technologists as delivery partners and also as stakeholders on what work ranks higher in the backlog.
Many product managers and owners are under tremendous pressure from customers, business leaders, and demanding stakeholders to prioritize features and business capabilities. They may be reluctant to focus on technical improvements consistently because they seek faster ways to deliver business outcomes, improve customer satisfaction, and appease tough business stakeholders. In my experience, another challenge is that some product owners don’t collaborate enough with their technology teams; they are often the worst offenders of underinvesting in addressing technical debt.
What should agile teams and devops organizations do to create a collaborative partnership with agile product managers and owners around technical debt? I asked three experienced product owners for their insights and recommendations.
Align technical improvements to business outcomes
Soumeya Benghanem, product management leader at VMware, hosts The Week in Product on Clubhouse on product management and discusses product managers’ tough decisions around defining priorities, aligning with customer needs, and improving technical capabilities. We cohosted a discussion on technical debt, and she shared these insights.
Benghanem says, “I think about business impact by looking at my prioritized outcomes and all the factors that matter. More often than not, there is tech debt that aligns with those outcomes. A better approach for product owners is to partner closely enough with their technology teams, understand technical design implications, and prioritize tech debt efforts. Addressing technical debt can result in better business outcomes, higher velocity, improved team morale, increased team retention, and alignment with values.”
If teams are only thinking about releasing capabilities and improving features, it’s hard to be concerned with technical debt. When agile teams target business outcomes, it leads to discussions on whether new features, reliability upgrades, security enhancements, new automations, additional testing, or other improvements align to strategy.
Define agile principles and metrics to promote improvement
It’s not just business outcomes that are important, and agile teams must also debate and disclose their principles. Benghanem suggests principles such as improving team morale and increasing velocity.
Suppose there are poorly supported code modules, manual deployment processes, or error-prone data services. In these cases, the added toil and stress of working in these tech areas should help justify prioritizing fixes based on agreed-upon principles.
Benghanem also warns against only targeting the big technical debt boulders that stand in the way of building features or improving experiences. “There is a perception that only ‘blocker’ tech debt is worth working on, and that, in my opinion, is an unhealthy attitude, especially in the early days of a tech solution,” she says.
Teams should define agile principles and related metrics that help justify and prioritize areas that need maintenance and improvements. Otherwise, small and decaying regions of the technology’s foundation can lead to longer-term structural issues. Increasing test coverage, addressing data quality, documenting architectures, and increasing observability are examples of non-blocking improvements that require ongoing enhancements.
Mark Albert, a New York-based director of product and associate partner at McKinsey & Company, reminds development teams to explain ongoing enhancements in business terms. Specifically, he says, “Overindexing on the technical upside and rationale can sometimes understate the importance, so instead focus on the business implications of not addressing tech debt. Framing the discussion around how the user experience, client delivery, product economics, or even the overarching value proposition can benefit from the investment now rather than later can be a more effective way to influence prioritization.”
Establish trust and debate trade-offs
Unfortunately, aligning to business outcomes and agile principles only goes so far in framing technical debt priorities. Sometimes, it takes several fixes over an extended period to achieve a business outcome. Other times product managers may lose patience investing in incremental technical enhancements.
Steve Chiou, group product manager at Box, says that product managers and their teams must develop trust and discuss trade-offs. His bottom line is, “As a product manager, do you trust when your technical lead says this tech debt is required? If your answer is no, then there is a fundamental issue within the team. Great product teams involve trust between the product manager, engineering, and the designer. If you don’t have that, then it is up to each of you to figure out why and to fix it. It should be a partnership with a give and take in every situation.”
Trust means that technical leads and development teams must take on a responsibility that product managers understand well. Technical teams must address their technical debt. Going to a product manager with a mile-long backlog of technical debt problems is just as bad as working with a demanding stakeholder with dozens of must-have feature priorities.
When product managers see technical teams prioritize, define their issues in business terms, and create meaningful agile principles, they are more likely to support improvements that address technical debt.