Technical Debt and How It Affects Agile Projects | David Tzemach
Updated: Mar 2, 2022
This article focuses on one of the most critical aspects of software development projects, known as technical debt.
What Is 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 interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of 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 one main point (my interpretation), stating that the development team and the organization must know the consequences of creating technical debt and what they will need to pay to reduce it later to allow continued business growth.
Since this metaphor was published (the term technical debt was introduced earlier in the 1990s), there have been conflicts in the software industry about defining technical debt. The software industry expanded Cunningham’s definition of technical debt to include all the bad things affecting the software development cycle. These include:
Poor test coverage – Poor test coverage leads to a sizeable number of bugs and issues likely to be found in the advanced phases of the project.
Software bugs – All bugs discovered during the development of a specific feature and not handled within the current sprint.
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.
Excessive manual tests – There is a reason why Agile teams push 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 for future sprints.
What Technical Debt Is NOT
A common misunderstanding about technical debt is that it refers to many other software project issues. According to Cunningham, technical debt does not refer to individuals in the team, incorrect processes used during development, or poor engineering quality resulting from a lack of experience.
Now, let us 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 should not be classified as technical debt. Although it’s a huge issue that may substantially impact 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, not all engineers have the full set of skills to handle the project's different challenges. 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
Although traditional and Agile methodologies use different processes throughout the software development life cycle, a lack of knowledge on using them may cause harmful 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
Cunningham did not intend for technical debt to refer to process issues that led to the bad design, problems with individuals in the team, or any other issue related to business maturity.
This debt can be eliminated easily if the organization provides the time and training to allow development teams to learn better technical practices and better decision-making throughout the project.
Now that we know what technical debt is all about, we can 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. This is with the full and calculated understanding of the consequences of the decision (more risks, higher costs, and less time to deliver new functionality).
When the team makes a strategic decision to generate technical debt, it becomes critical to let upper management know about the team's compromises.
One great example is related to testing. In many cases, when the team arrives at the end of the sprint, they will decide to keep some areas untested to ensure they can deliver on time. If tested, it will result in the team postponing the feature planned for the following sprint to run the missing tests. Therefore, the technical debt is areas of the application that are not tested, which adds more risk to the application.
Another essential aspect of planned technical debt is to ensure the organization maintains a record of its decisions. By creating documentation, the organization and the team increase the likelihood the technical debt will eventually be removed. If this is not done, it is highly likely to be forgotten and become a more significant and unplanned problem in the long term.
Unplanned technical debt
This refers to any technical debt created by the team due to poor technical or logical practices such as:
Inadequate communication among the different teams leads to an inefficient integration process.
Poor risk management leads to critical errors and delays of the release.
The use of a poor design approach leads to many bugs in the application.
Unavoidable technical debt
This type of technical debt refers to changes in the business and fast-moving 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 it appears when a new business requirement makes the current code obsolete.
Managing Technical Debt
Sometimes the business can control the technical debt, and sometimes it cannot be predicted. The main thing is that the business ensures it has the tools to handle debt no matter the cause. 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 technical debt.
Processes – The organization should update the product backlog with all the incomplete tasks raised during day-to-day activities. The team can prioritize their work, increase transparency for external stakeholders, and be aware of the effort needed to reduce the new debt.
Employees – The organization should foster a culture of accountability, awareness, and responsibility. By implementing this type of culture, the organization creates the necessary approach among its employees to reduce future technical debt.