The term “debt” immediately makes us think of owing money and, most of the times, it is related to financial issues such as loans, financing, and credit cards, among others. In the agile methodology context, technical debt can bring significant impact on project development – especially when teams do not adopt good practices.

Below we address the topic thoroughly and show how to identify and deal with tech debt.

Technical debt

“Your company switches to the home office model and you are one of the first collaborators to work remotely full time.

After some time, you realize you could be more productive with a second monitor. Despite you are low on cash, you decide to buy a new monitor at an online store and pays it with your credit card. When the credit card bill arrives, you realize you do not have money to pay it. With interest rates at around 300% per year, the credit card bill will increase on a daily basis, creating a snowball effect.”

This is an example of how one can incur a financial debt. But what are the similarities between financial and technical debt? Check out below:

“Now imagine that, during that same period, several other companies also adopted the remote work model and, as a result, the website where you bought your new monitor starts to experience higher purchase and delivery demand levels, meaning that the development team has to adjust the delivery dates.

After some analysis, two execution approaches are identified to meet the business requirements:

Approach A: following all technical best practices, it will take the development team almost two weeks to make the necessary adjustments.

Approach B: the development team will aim to accelerate delivery down to two days, making the necessary adjustments, but they will cut some corners in coding and will use a different standard from the current architecture.

Because the adjustments are critical, the team decides for the quicker approach (B). With that, it incurs in a technical debt. Despite more agile, the solution was implemented in a hurry and compromised several points of the system: variables, codes, logic etc.”

The story above is an analogy introduced by Mr. Ward Cunningham in the Agile Manifesto in 1992. Co-author of the Manifesto, Mr. Cunningham shows it doesn´t take too much to incur a financial or technical debt that can compromise future plans.

In the website case, refactoring the code is the only way to solve the technical debt.

Technical debts are not generated only by implementation decisions. There are other issues that negatively affect the team productivity, among which:

• Obsolete architecture;
• Duplicate code;
• Lack of testing coverage;
• Lack of a coding standard.

On the other hand, not all software issues are necessarily technical debts. They can also be:

• Quality debts, such as detected and unfixed bugs;
• Process debts, such as missing or faulty processes;
• Feature debts, such as wrong or outdated features;
• UX debts, such as inconsistent or bad experiences;
• Skill debts, such as lack of knowledge or seniority of the team.

What if I do not pay the debt?

As with compound interests in the case of financial debts, unpaid technical debts will become more complex and dependent on the existing code in every sprint or iteration, when new features are added to the system.

That is to say, when one decides to implement a kludge to circumvent a prior quick fix, this directly affects agility, quality and productivity of the team in future implementations.

And these are just some of the consequences. Quick fixes can bring other problems as well.

For example: a team that is continuously sorting things out to circumvent a problem or has to justify why simple adjustments became so complex and time consuming can feel highly discouraged.

How can I pay technical debt?

It all starts with communicating openly and being honest and transparent!

The alignment of the business and technical areas is crucial because, when it comes to the team’s decisions and responsibilities, it is important to remember that the Product Owner is also part of the team.

Accordingly, if the pressure to deliver a given feature ends up leading decisions of taking a shortcut, all technical consequences should be crystal clear and agreed upon by the entire team, including the PO.

These technical details, besides serving as input to decision making, also help the team be aware of the whole scenario when it is time to prioritize the technical debt.

In addition here are other tips that can help you with technical debt:

1- Always keep the tasks board organized

After they are identified, debts should be demonstrated. There are several ways to handle these activities as part of the iteration:

• Building up a separate backlog listing only the technical debt;
• Applying the 80/20 rule, where 80% refer to activities of the development backlog and 20% of the technical debt backlog;
• Having an exclusive swimlane on the board for the debts and setting a minimum and maximum limit of cards.

Regardless of the methodology used, it is important to follow the debt closely and make it always visible. together with identifying associated impact, amount of effort, and timeline the organization will be able to pay it back.

Another good practice is to prevent the tech debt from accumulating to an extent that hinders the team’s ability to deal with it or to have a debt backlog that exceeds the features backlog. This can lead the software to “go bankrupt.”

2- Be aware that unexpected expenses are unavoidable

Not always technical debt will be planned or identified. To mitigate unintentional debt, consider the following:

• Peer Review and Definition of “Done”: in addition to ensuring the software standard and quality, a peer review ensures that more members in the team are aware of the features that are being implemented. Furthermore, peers definition of done can help reinforce the process.
• Have a robust codification standard and architecture: in general terms, a standard helps prevent, reduce and even solve the technical debt as the entire team becomes familiar with the model.

3- Maintain your financial health

In the same way we use our credit card to anticipate purchases, incurring technical debt can also improve the team productivity, meaning it is not always a bad choice.

However, it is important to remember that, like financial debt, the accumulation of technical debt can quickly reduce the speed and quality of deliveries.

Accordingly, maintaining the financial health is pivotal to the process, that is, it is important to find a balance and include technical debt activities in the iteration without busting your budget.

So tell us: How is the financial health of your agile project