Tackling Technical Debt Redux: a Deeper Dive

Software development teams that follow Agile methodology move quickly to continuously release and refine features in periods of time called sprints. The duration of a sprint varies from company to company, but many adopt the two-week sprint. Product managers work with their development teams to reduce the planned work scope to what can be achieved during the sprint. Due to the fast nature of Agile development, it has the potential to both be a source of new technical debt and the cure for paying down technical debt.

“Move fast, break things”

When teams implement Agile aspects and over-pivot on speed and micromanagement instead of responsiveness and individuals, they may accumulate considerable technical debt as they race to release features and their developers start to burn out, increasing the odds of mistakes. This builds on top of any technical debt your team inherited in legacy code.

Find the balance during sprint planning

Most product owners and teams enjoy working on new features, but finding a balance between new development and resolving technical debt is important. This begins with understanding how much technical debt you have, where it is, and what business outcomes that debt is hindering. Educate product owners and technical leadership on these tradeoffs to get their buy-in and support for tackling technical debt as part of the ongoing sprint planning.

Without leadership support to tackle technical debt, development teams either attempt to fit it into another sprint—which can affect accurately predicting the level of effort and productivity—or continue to allow it to accumulate due to lack of priority. Both of these approaches lead to suboptimal outcomes, and eventually, the technical debt has grown so large that it disrupts releases and becomes more difficult to fix.

Planning Approaches

Agile teams can plan for, and work on, technical debt in a few different ways:

Fix it as you go

When developers work within the code and come across something that is not working well, they can address the problem before moving on with their planned work.

As long as there isn’t a barrier, such as regulatory constraints, to allow developers to “fix it as they go,” trust your employees and empower them to fix problems without formally filing a backlog task and waiting for it to be added to a future sprint. This approach works well for small effort bugs and poorly written code while continuously improving the code base. Even though these issues have not been submitted for a decision to move forward, it’s important to make developers’ work in this area visible. Visibility into continuous code improvements helps teams accurately predict work, determine if there are larger issues to address, and adjust sprint planning to accommodate future work.

Remember that “fix it as you go” is unstructured and unlikely to address any larger backlog tasks, infrastructure, or performance issues the team needs to work through.

Set aside time per sprint

In this approach, teams set aside a certain amount of time or story points per sprint to address known technical debt. This chips away at technical debt over time while building new features and making the permission to work on technical debt explicit and highly visible.

Dedicated technical debt sprints

Some technical debt requires the full focus of the development team to understand the problem dependencies and determine the best solution. Or perhaps the backlog has grown so intimidating or disruptive that the only option left is to schedule a sprint (or sprints) dedicated to cleaning up the open issues.

The advantages of scheduling dedicated sprints are that the entire team is available to solve tricky problems, that there is a sense of achievement in crossing off issues and watching the backlog shrink, and that there isn’t pressure to try to do everything all the time. The disadvantage of this approach is that these dedicated sprints may be scheduled so far apart that technical debt isn’t addressed in a timely manner.

Next steps

Most teams must use multiple planning approaches to balance new feature development and prevent technical debt from accumulating too quickly. Use fix-it-as-you-go for small, quickly resolvable code fixes that developers encounter in the code they’re working on, regularly set aside time per sprint to tackle small and medium tasks as part of regular planning, and, when needed, schedule dedicated time to tackle big problems that require the team’s collaboration and skills.