In software development, technical debt is a concept that reflects the extra development work that arises when we use quick or easy solutions. But the concept is useful beyond the world of software too. In the digital world, where new technologies and ideas are emerging just about every day, technical debt is almost unavoidable. So we need to know how to deal with it. 

Watch now | Why Technical Debt is an Opportunity

Roberto Bettazzoni has experience as a technical trainer and a software developer. Alessa Leuschen has experience in different Agile roles, including a Product Owner and Scrum master. Together, they share their different perspectives and experiences, outlining some effective ways to deal with technical debt, and how to use it as an opportunity.

Join us for our upcoming webinar about Burnout, or stay in the loop about upcoming webinars by joining our mailing list. 

Five key takeaways from the webinar

Technical debt is unavoidable in Agile product development.

Technical Debt is a metaphor, coined by Ward Cunningham. He explains that when we initially ship a product, we are likely to go into “debt” as we do not have all the knowledge we need yet. This phenomenon happens after we ship an easy or limited solution that may require extra-work or an additional cost later on. Roberto Bettazzoni clears up some misconceptions, saying, “Technical debt is not bad code. It’s not a bad solution. It’s not putting something in production that doesn’t really work. It’s shipping with the quality that we can do quickly and with the knowledge we have now.” Once we have feedback and our hypotheses are verified, we can “pay our debt back.” “This is in the heart of Scrum or any Agile way of building solutions,” Bettazzoni concludes.

There are different types of technical debt 

The incremental nature of Agile methods allows us to keep technical debt small and deliberate, which can be continuously evaluated. However, it can also be unintentional, and this can show up in a review. In this case, these discoveries will need to be quantified and corrected. Roberto Bettazzoni says that not all types of technical debt are helpful.  He explains that, “There’s another way in which it is reckless. So, when you make a big technical debt, you go quick and dirty in production.” And this is something you want to avoid if you are already deep in debt.

Technical debt can become a threat if it gets out of control 

Alessa Leuschen uses a metaphor to explain how technical debt can get out of control. She asks webinar attendees to imagine that construction workers arrive at a house to add new features. Upon arrival, they notice that the house has a lot of existing problems: the foundation is missing, there are holes in the wall, and the whole construction is unstable. 

The manager asks them to put a window in. The workers realize that this is going to be challenging because of the poor foundations they have to work with. This task will take longer than usual because they need to think about how they can put in a window without breaking the whole house. Of course, their morale and productivity will suffer. A manager might then put additional pressure on the workers to try to increase their productivity. To meet these unrealistic demands, the team might resort to so-called “quick and dirty solutions” that will produce even more technical debt. In this scenario, you can see how technical debt can become a vicious cycle and can be expensive in the long run. Leuschen explains,  “In the beginning, you’re not going to feel it that much but at a certain point in time it’s going to grow exponentially.” 

Make sure you pay back your debt

Bettazzoni sticks to the metaphor of buildings. “We need to have healthy habits to clean the house,” he explains, “don’t let the dirt pile up.” To keep our technical debt under control, we need to continuously invest in it and pay it back. We can do this by visualizing our technical debt, sharing this knowledge with the relevant parties, mapping out our technical debt, and lastly coming up with a refactoring plan. This may mean allocating a certain amount of time in your Sprint to technical debt or putting it into the product backlog. Plus, Bettazzoni recommends using one of many great tools that can help us to manage technical debt, like Sonarqube. 

Our Certified Scrum Master training covers technical debt, and can equip you with the skills you need to manage it. 

5. Technical debt can help us grasp market opportunities 

In today’s volatile world, we don’t have as much time to develop products and bring them to the market.  “A way to deal with that is to create a vision, an understanding, and clarity to find out how to serve our customers best,” shares Leuschen, “Agility can help us do this by incrementally allowing us to figure out what the best solution for the market is.” 

We often do not know what the solution will look like in the end. By shipping faster, we get customer feedback faster, and we can experiment as we go. This approach means that we may need to use an easy or limited solution. “Acquiring technical debt is not only a technical topic but it’s also a design topic, because we have this uncertainty,” continues Leuschen, “we need to figure out what the solution will look like in the end.”