Why is it important for agile teams to reduce technical debt?

Ward Cunningham, one of the creators of the Agile Manifesto, was the first to describe the concept of technical debt (Cunningham, 1992, OOPSLA conference). He defined technical debt by using the following logical metaphor:

Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as an interest. Entire engineering organizations can be brought to a stand-still under an unconsolidated implementation.

Cunningham used the metaphor above to explain to his colleagues why creating software quickly to get customer feedback is a great thing., However, he addressed two main points (my own interpretation):

• The development team and the organization must become familiar with the consequences of creating technical debt, and what they will need to pay to reduce it to allow continued growth of the business.
• The team must embrace the first key point during the design and implementation of the software.

Since this metaphor was published (the term technical debt was introduced earlier in the 1990s), there have been conflicts in the software industry about how to more accurately define technical debt. The software industry has expanded Cunningham’s definition of technical debt to include all the bad things affecting the software development cycle. These include:

Software defects – All defects discovered during the SDLC and not removed by the team (classic examples are defects that the organization defers to a future project or iteration).

Outdated code design – Code design created at the beginning of the project that is no longer relevant due to changes in the software structure, architecture, or technological improvements.

Poor test coverage – Poor test coverage leads to a sizeable number of defects and issues most likely to be found in advanced phases of the project.

Excessive manual tests – There is a reason why agile teams are pushing towards automating tests as much as they can. Manual testing does not allow the team to complete testing in a single sprint, and as a result, technical debt is created in future sprints.

WHAT TECHNICAL DEBT IS NOT

A common misunderstanding about technical debt is that it refers to many other software project issues, which is an incorrect interpretation of what Cunningham intended for technical debt to be. According to Cunningham, technical debt does not refer to individuals in the team, incorrect processes used during development, or poor engineering quality that comes from a lack of experience.

Let’s review some software project issues that may be classified as a technical debt due to an inaccurate interpretation of Cunningham’s definition:

Delay in the delivery of a feature – Delayed features delivered to a customer should not be classified as technical debt. Although it’s a huge issue that may have a strong impact on the organization, it’s still classified as feature debt.

Poor or missing training – In some cases, engineers will need the training to succeed with the different development and testing challenges. Lack of training is classified as training or educational debt. This kind of debt can be eliminated or improved through proper training from the get-go.

Lack of skills – Sometimes it is just the way it is, and not all engineers have the full set of skills to handle the different challenges the project entails. This type of debt is called skill debt. This debt can be easily removed by having the right people participate in the project.

The use of poor processes during the SDLC– Although traditional and agile methodologies use different processes throughout the software development life cycle, a lack of knowledge on how to use them may cause deleterious effects. Regardless, this should be classified as process debt. This type of debt can be eliminated when the business understands how to apply these processes correctly.

UX issues – Poor user experience can make the software unusable for some, but it’s not technical debt; it should be classified as UX debt.

TYPES OF TECHNICAL DEBT

As you can see from the previous paragraph, Cunningham didn’t intend for technical debt to refer to process issues that led to bad design, problems with individuals in the team, or any other issue related to business maturity.

This kind of debt can be eliminated easily if the organization provides the time and the training that allows development teams to learn better technical practices and better decision-making throughout the project. Now that we know what technical debt is all about, it’s time to review the three categories of technical debt.

Planned technical debt

This type of technical debt occurs when the organization or team makes an informed decision to generate technical debt with the full and calculated understanding of the consequences that this decision entails (more risks, higher costs, and less time to deliver new functionality).

When the organization decides on a strategic decision to generate technical debt, it becomes critical that the team let upper management know the compromises the team will have to make.

One great example is related to testing. In many cases, when the team arrives at the end of the sprint, and there are tight deadlines, they will decide to keep some areas untested to ensure they can deliver on time. Technical debt is areas of the application that are not tested, which will add more risk to the application. In addition, the team will have to postpone the feature planned for the following sprint in order to run the missing tests.

Another important aspect of planned technical debt is to ensure that the team and the organization maintain a record of their decisions. By creating documentation, the organization and the team increase the likelihood that the technical debt will eventually get removed. Otherwise, it will most likely be forgotten and become a bigger and unplanned problem in the long term.

Unplanned technical debt

This refers to any technical debt created by the team due to the use or execution of poor technical or logical practices. Examples:

• The use of a poor design approach leads to many defects in the application.
• Inadequate communication among the different teams leads to an ineffective integration process.
• Insufficient risk management leads to critical errors and delays in the release.

Unavoidable technical debt

This type of technical debt refers to changes in the business and the fast-developing technology that, over time, allow the organization to create and adopt better solutions. It typically arises when the customer asks to add changes to the project scope after the project has already started. This results in an immediate cost, such as adding new functionality to an existing part of the system. The easiest way to describe this type of technical debt is to say that it appears when a new business requirement makes the current code obsolete.

MANAGING TECHNICAL DEBT

As we’ve seen, sometimes the business can control the technical debt, and sometimes it cannot be predicted, but the main thing is that the business ensures it has the tools to handle debt no matter the cause. As the years have gone by, I’ve learned that there are three main dimensions that the business should focus on:

• Technology – The organization must follow the market to be aware of any tools and technologies that will help create better products, increase work efficiency, and manage its technical debt.
• Processes – The organization should ensure that the product backlog is updated with all the incomplete tasks that were raised during day-to-day activities. By doing so, the team will gain major benefits, such as the ability to prioritize their work, increased transparency for external stakeholders, and awareness of the effort they need to reduce the new debt.
• Employees – The organization should ensure that it fosters a culture of accountability, awareness, and responsibility. By implementing this type of culture, the organization will create the necessary approach among its employees that will allow for reduced future technical debt and, at best, a reduction to the minimum necessary.

David Tzemach

The founder and owner of the Agile Quality Made Easy blog (25K followers). A platform that he uses for teaching and coaching others, sharing knowledge with people, and guiding them towards success while giving them the inspiration and tools to discover their own path.

See author's profile