Technical Debt

We have a very interesting and controversial notion of "Technical Debt" in Agile projects. In this article I shall get your attention to the two adverb that I have used to describe Technical Debt.

It’s interesting because we can easily draw parallels to financial debt from where this term and concept has been originally derived.  To take any loan (which eventually results in debt) we first need to qualify for it, present the repayment plan and also prove our capability for doing so in advance.  If our credit history has not been good and we already have existing debts or missed payments, then we may not even qualify as we fall under the high-risk category. This said, debt is ultimately a burden and not really desirable to start with; it is best to avoid it as much as possible.  Any financial advisor would discourage you to go for it without justification and a proper repayment plan. However, if we are in dire need and can justify the risks involved and the interest payments, we can take the loan after due-diligence. Similar to financial debt, we have the concept of Technical Debt.  Simply put, it is the gap between completing the task in quick and dirty manner vs. doing it perfectly, for e.g. having proper design or architecture, good programming practices, use of production like data, relevant documentation, hard coded PaaS scripts and regression testing etc. fall into the category. This gap is the Technical Debt that we are obligated to acknowledge and pay off. Have you ever heard somebody utter these words, "We got a tight deadline; let’s somehow make it work fast?” I am sure you have and chances are this would result in technical debt (if not worse).  The real trick lies in identifying and accepting that it is happening. And it takes courage to not sweep it under the rug and boldly declare that I plan to take a shortcut and accept the risks associated with that.

If you have it, accept it with prudence

Now let's look at any agile project. While working on a task, we may take some shortcut, typically due to time pressure to deliver the story faster, to complete the work.  This would result in technical debt and as per the debt process, we acknowledge the shortcuts taken and the resulting unfinished work. The plan to finish the work also needs to be shared and it should be very visible on the task-board, this would typically fall under refactoring. In traditional projects, the individuals or teams taking the shortcuts may not feel the need or obligation to bring this out or even find it more "convenient" to hide it all together.  However, as Agile prescribes honesty, courage and transparency, we need to come out with the details regarding the shortcuts taken, reasons for the same and any risks involved. This must be shared with the entire team (including the PO or other business stakeholders).  The reason for putting it out there to the entire team is to assess the risk from all points of view, including project, technical and business risks. There are several instances where what we reckon as a low technical risk can turn out to be a high business risk. After assessing and accepting the risks, dealing with the shortcoming due to the shortcuts becomes a task in itself and goes on the backlog with high visibility. The backlog can be created as a seperate section if required, with a clear plan and deadline to pay off this debt. Based on the impact analysis, the debt can be short-term or long-term. Here the entire team is aware of the associated risks; if upon re-assessment the risks turn out to be higher than previously thought, then we need to complete the task on priority.Not assessing the risk or keeping it from certain roles will make this technical debt controversial and against the Agile principles. And that’s the reason, I imagine, why some Agile “purists” are altogether against the concept of “Technical Debt.”

The key to paying off technical debt is to acknowledge the debt and carry out a detailed risk assessment.  

Who took this loan?!

There can also be a case that we have incurred debt and we are not aware of it (for e.g. if someone you know shops using your Credit Card and you only realise it when you see the statement).  This can typically be the case where we have inexperienced team members who are doing their best to complete the task and "think" that the work has been completed; however there can be some gaps which they are not aware of, and this would turn into Debt when we realize the gaps  at a later time, probably during review or when they mention it. This would be categorized as Un-intentional Debt. Now there is no point in getting into a relentless debate about the categorization into Intentional vs. Unintentional debt.

Unintentional debt can be incurred by oversight of team members

The key takeaway is to deal with the debt as soon as we are made aware of it. However, there is an inherent risk element associated with unintentional debt as we are unaware of the scope of impact and have no mitigation plan.

Debt? No, that's just electricity bill that you gotta pay

There could also be confusion around the idea of debt, not all pending work qualifies as debt. To keep it simple, I use this thumb-rule, if there is a task that "looks" completed, you can stick it to "Completed" column on task-board and you can very easily hide this fact (at least for the time being). However, since you know there is some shortcut involved which will need further refactoring to your task before you claim it as done, this additional work will classify as Debt.

Don't be Debt-ridden

There is always a risk with taking shortcuts while completing tasks (not withstanding all the good intentions to smoothen those "rough edges"). This risk multiplies over time and goes beyond the accepted levels if not regularly paid off as per the schedule. It is mostly seen that such small imperfections result in cumulative failure and often it is found late which makes it even worse. Debt is an excellent instrument for de-risking the project from the schedule perspective, keeping things transparent and boosting the team spirit, only when we show due discipline in paying it off. 


A word of caution here, once established and accepted, Debt should not become an excuse to take shortcuts and then having the plan to pay it off as a single Test Hardening Iteration at a later time. If you have to incur debt, please plan to pay it off urgently and never have a plan to pay off the cumulative debt as part of a hardening iteration. The hardening iterations (another controversial concept) are not meant for paying off debt.

Please remember nothing comes for free; you have to pay interest on debt as escalating maintenance cost. So spend judiciously and don't let it spoil your credit history.

Ashish Mishra is an executive consultant with over 23 years of experience in delivering business agility and agile development solutions to organizations. As an Agile Coach, he has helped facilitate Lean-Agile transformation at an enterprise level. Register for a SAFe certification course with Ashish to explore the principles of a Lean-Agile mindset.

Like this post? Share it with friends