Handling Technical Debt in Agile Management

No one wants to talk about it, but we have to – there is no getting around debt. It is part of life. Debt happens and each of us responds to it differently. When it comes to agile management, technical debt is a cold-harsh reality. Just as we have to sometimes borrow now and pay later, the same happens with agile development and teams.

The thing about debt is that it is so tied up in stress, self-doubt, and negative emotions. People avoid reading their credit card statements or put off hard conversations. All in a hope to avoid the ugly realities that can come with debt.

We want to put an end to this in your agile team. It’s time to learn about, analyze, dissect, and develop strategies to handle your team’s technical debt. Just like that unopened bill, the longer you ignore it, the worse it will be. This ends for you today – yes, technical debt happens – and now it’s time to address it.

Defining Technical Debt

Just as there are as multiple ways to implement an agile management system in your organization, the same holds true for defining technical debt. There is not one cut-and-dried definition of technical debt. This is simply because of the nature of development, project planning, management strategies, and the interpretations of done and ready.

Trust us, we want to give you a simple definition, but we can’t – instead we’ve collected some different (but similar) definitions of technical debt. Use these as your guide when assessing your team’s technical debt status and how to best manage it.

• When taking short cuts and delivering code that is not quite right for the programming task of the moment, a development team incurs Technical Debt. This debt decreases productivity. This loss of productivity is the interest of the Technical Debt. (From Introduction to the Technical Debt Concept by Agile Alliance.)
• Technical debt is the difference between what was promised and what was actually delivered. (From Escaping the black hole of technical debt by Dan Radigan.)
• Technical debt can be defined as the longer term consequences of poor design decisions. (From The Product Backlog and Technical Debt by Ian Mitchell.)
• You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy – you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place. (Metaphor for technical debt introduced by Ward Cunningham, referenced by Martin Fowler.)

As you can understand from these four definitions of technical debt, the term is open to complex interpretation. While we can spend hours debating the true definition of technical debt, this is wasted effort.

The critical step is in defining for your team the meaning of technical debt. Sit down with your entire team and talk about technical debt. Discuss the different definitions, the implications of technical debt, concerns over technical debt, and how you as a team want to handle technical debt.

As in all things agile management, there is no one way to do things – define technical debt so it makes sense for you and be ready to adjust this definition as your team and projects change.

How To Stop Technical Debt from Taking Over

The beauty of agile management is that you can make it work for your team however you need to, and this makes it much easier to manage technical debt. Just as you take what you need from agile management training, definitions, and other resources – do the same for the internal strategies you use to stop technical debt from taking over.

• Development strategies. Your developers, quality assurance experts, designers, and DevOps team members must agree on how they work together. For example, pair programming, automated testing, acceptance test reviews – all help to create an environment that prevents technical debt from being missed or ignored.
• Remember the long-term. All too often teams are focused on the current iteration and neglect to look forward. When planning and reviewing code, make sure the long-term impacts of the design decisions do not result in technical debt. Take the time early-on to plan the design, code, and review process to minimize technical debt in future work.
• Plan to fix it. Devote epics, stories, and iterations to fixing technical debt. This is a good opportunity to review, analyze, and change development processes to prevent further technical debt accumulation. This is also a great way for your team to get familiar with legacy code.
• Plan better. Yes, easy to write but not as easy to do – but better planning gives you and your team the time needed to prevent the short-cuts and quick fixes that can result in technical debt. Create an effective way to rank and evaluate story impacts and be ready to make changes during an iteration accordingly. Remind your team of the costs of rushing and implementing the quick solution.
• Done and ready. Does your team have clear definitions for done and ready? Without knowing what it means to be done and ready, it’s impossible to avoid technical debt. Done and ready are key in defining stories and in delivering quality software.

Getting a handle on technical debt in your agile team is not going to happen overnight. Remember how debt accumulates and take the same approach to getting a handle on it within your team. Forcing or rushing into changes in the development process does not work. Remember this is a team problem and it takes team effort and commitment to better manage and handle technical debt. Slow and steady wins the race against technical debt – and there is not a team out there who is free of technical debt.