Technical Debt - Dig Your Way Out

In software development, technical debt can come in many forms. For instance, a new product was created using a prototype that was never architected after the proof of concept was created. Another example is bugs that had workarounds, but a fix has not been implemented yet. Another issue is that a series of software upgrades need to be implemented, but the team is understaffed. These are only a few examples of technical debt, but all of them create a problem that can haunt a project in the form of risk. How does a project manager dig their way out of technical debt?

Sometimes, technical debt is invisible to everyone outside of the team. It simmers just beneath the surface, waiting to boil over and disrupt everything around it. At other times, technical debt raises its head in minor ways, which gradually become larger problems over time. The key idea is to eliminate technical debt as soon as possible. Project managers should collaborate with their team and stakeholders to assess the situation, categorize its risks, prioritize the issues that need to be addressed first, and then implement the necessary fixes.

Assess Risks

Assess the debt, its impact, and potential resolution options. Risk is the bane of the existence of project managers. Risk should be avoided, mitigated, or (preferably) removed whenever possible. The team will often have input on areas they see as risky, and project managers should take these seriously. Project managers should keep a list of observed risks, their potential impacts, and develop plans to mitigate or resolve them.

Categorize and Prioritize Risks

Categorize the technical debt based on risk. If a risk is seen as system-wide, it should be categorized as major. Whenever possible, focus should be placed on developing plans for significant risks. Sometimes, project managers try to focus on easy “pick-up” wins, but this can divert attention away from risks that may develop into emergencies. There is nothing wrong with quick fixes for minor risks, but they should not be a priority. Take stakeholders into account when prioritizing, but also defer to your team’s expertise. If they feel that something poses a higher risk due to its complexity or impact, they will have a better idea of its priority. Stakeholders often do not fully understand the risks, particularly if the risk is not a top business priority. Project managers should be able to approach a stakeholder and explain why they are assigning a higher priority to addressing technical debt. Their teams can assist in building that explanation.

Implement Fixes

Implement the requirements to resolve the issue. In an ideal world, a project manager would request a “code freeze,” where all coding activity stops to focus on the problem. This is not always an option, though, so they should then prioritize a certain percentage of implementation capacity to address the issue. Many places allocate 10-20% of their development capacity to addressing technical debt. Sometimes this is done during a standard sprint, while at other times, a technical debt sprint is initiated every quarter or so. The critical concept is to spend time addressing and fixing problems before they escalate. Fixes do not have to happen all at once; instead, they can be done incrementally. Continuous improvement is the goal. Keep track of the fixes as they are implemented so that you can display your team’s improvement.