Get certified - Transform your world of work today


Technical Debt and Agile

19 July 2017

In today’s innovative world in which we give priority to creativity, we have been experiencing a rapid growth in new technologies and applications while seeing a rise in technical debt. Let’s better understand technical debt and how it affects product quality. We can rescue our Agile team by following best practices and educating stakeholders.

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. The reasons for refactoring or restructuring code are several: poorly written code, an inappropriate approach as the result of misunderstanding the real problem, or budget and time constraints. Technical debt may be known also as design debt. It degrades the quality of the software to the extent that it becomes costlier to fix issues found in the software than to build the original software. It can also decrease the value of the application in the market.

Exposing technical debt

Last year, Southwest Airlines experienced a chain of failures that led to canceling 2,300 flights over four days, costing the airline an estimated US$54 million. British Airways has experienced several instances whereby its check-in systems failed. Mike Rosen, research vice president for executive programs at IDC, said in a recent webinar titled Technical Debt: A Framework for Unfunded, Critical Technical Liabilities, that he doesn’t want to pick on the airlines, "but you don’t want to be in the headlines."

"And these 'avoidable disasters' are in part due to aging systems that have become brittle due to budget pressures and deferred investments," he said. "Nontechnical people don’t understand the technology or its complexity," said Rosen, and one can make the argument they shouldn’t have to. But they do need to understand the consequences of technical debt, and IT must learn how to communicate it in business terms they can understand.

Real losses from technical debt

  • Quality of the software design
  • Market/brand value
  • Customer trust
  • Time and cost associated with refactoring

How technical debt evolves

  • Reckless thinking
  • Market pressure: to keep up with market demand, bring innovations to the market
  • Budget pressure
  • Neglecting the consequences of technical debt
  • Technical debt is like an iceberg — it’s not immediately detected
  • Inadequate analysis of the exact issue required to resolve the problem

Symptoms of increasing technical debt

  • A pattern of issues emerges because of bad bug fixes, shortage of time, or lack of proper testing.
  • Frequent design issues. The proper solution has not been found, and the architecture is not well designed.
  • As time passes, there is a corresponding increase in the number of issues, even though no new features were added.
  • Existing code is breaking as the direct result of adding new features.

Case study: Toyota's unintended acceleration

Issue: In 2013, several Toyota drivers reported that their car was accelerating without them touching the gas pedal and, in some cases, while they were even stepping on the brake pedal.

Analysis: After a deep-dive analysis, Toyota found that there was a critical problem with the software of the car, thus calling it the big bowl of "spaghetti" code.

Conclusion: If best engineering practices were followed, and if the software design had been tested thoroughly, the defect could have been avoided. We should also understand that the safety of the customer comes first. We can’t take risks with safety for the sake of including a few features.

How to reduce technical debt using the Agile framework

It isn’t easy to change a team's philosophy, or that of the team's stakeholders, about how to manage technical debt. To fulfill business needs and to bring innovation to the market sooner, the development cycle is typically shortened. With that in mind, below are actions that you can take, especially for those who are less tech savvy, to tame technical debt.
  1. Educate the product owner on the true cost of technical debt. Ensure that story point values are accurate for future stories that require resolution of existing technical debt.
  2. Ensure that stakeholders understand that architecture growth is akin to any application growth. For any new features that we add to an application, we should have an equal extension in architecture in the initial phases of a sprint. This practice has been well described in the SAFe framework as having an architectural runway that is parallel to the application runway. This can be planned based on the requirements of the application. This way, we’ll reduce technical debt by following proper engineering processes.
  3. Modularize your architecture in the form of components so that these same components can be well used in other applications.
  4. Write frequent unit test cases for each of your modules and have frequent peer code reviews.
  5. Automate test cases.
  6. Plan to have a designated amount of known technical debt as targeted technical debts to be serviced during the sprint.
In addition to these actions, strategize how your team wants to work. The work done in a quarter or in six months is going to be the same whether or not the team has no debt, in which case they work slowly or leave some technical debt and take care of it at the end of the quarter or within six months. The latter choice would lead to a better outcome since the team would have a better understanding of the debt. Technical debt sprints are required to keep the backyard clean. This will at least allow the team to maintain the velocity. It depends how you and your team wants to drive it.


1. N. Kalapalli, "Why Agile Teams Need 'Technical Debt' Sprints,"

2. G. Hilson, "IT must communicate liabilities and consequences of technical debt," IT World Canada, September 22, 2016,

3. "Architectural Runway," SAFe,

4. "Technical Debt," Techopedia,

5. D. Radigan,"Escaping the Black Hole of Technical Debt," Altassian,

6. Technical debt images,

7. Technical Debt Book, "Case Study: Toyota and Unintended Acceleration,"


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.5 (30 ratings)


Apoorv Shrivastava, CSM, 7/19/2017 11:44:50 AM
Very informative and well written.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up