Technical Debt, Product Value, and Risk Management
There are many lessons that we will learn from the Equifax data breach, ranging from legal and regulatory ones, to ethical ones, to matters of privacy and identity. As an agile software developer who thinks about the relationship between technical issues and product value, there is a particular lesson to consider. Reports that the breach took advantage of a known issue in Apache Struts set the stage for a conversation about technical debt, product value, and risk management.
On a Scrum team, items on the backlog that seem focused on technical issues are often hard to prioritize. As software developers, we may see value in a new feature or a bug fix that a new release promises. Without further information, product stakeholders may see risk without product value. Product owners are responsible for prioritizing work, and “value” is a perfectly reasonable way to do so. While some with product owner roles might decide to focus on features regardless of issue, such as technical debt accumulation, security, or perhaps developer happiness (working in a tricky code base is not good for morale), most just need the right information. Here are some thoughts on how to help prioritize technical work in a way that balances short and long term value.
Developers and the product owner need to work together. While in the Scrum process, the product owner sets priorities, and the team has a responsibility for helping the product owner understand cost, risks, and relative value. In most cases this can happen with an estimation discussion around implementation choices. For technical and infrastructure related items the team needs to make the value of the work clear. For example, “update to a new framework” isn’t something that is valuable to the stakeholders, but “updating to a new framework to improve speed of development” makes the value clearer. And in some cases, less direct value statements such as “improved morale and retention” can be a part of the conversation. The important thing is to provide enough context so that those who are not developers can understand the value. This applies to infrastructure, refactoring, design, and decisions to create or pay down technical debt.
Since risk and value for some issues is hard to quantify, a security or compliance team may be able to help. While some incarnations of compliance organizations can seem to get in the way of productive work, some understand how to balance complains with practicality and can help identify arguments for prioritizing certain technical work.
Technical debt can have a very real impact on a business. In the end the product owner prioritizes work. It’s the responsibility of the developers to help the product owner understand the importance of technical tasks and to identify which technical tasks should be considered for the product backlog.
