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

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.

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.