Circumstances often place developers in a situation where they face the decision: Do I write a cheap and nasty solution in order to move forward now? Or do I take more time to solve the problem properly and risk delivering less business value by the end of the sprint? In this situation, an agile developer should do the right thing .

Technical debt was a metaphor first coined by Ward Cunningham. Electing to implement a quick solution with dirty code can sometimes be the right thing to do. What's important is to realise that it incurs technical debt which, like financial debt, requires repayment by returning at a later date to refactor the dirty code. Recognising the implications of technical debt helps us to understand its effects and enables us to control our level of debt to ensure that it remains affordable.

It's a responsible practice to repay technical debt frequently, and we are obligated to manage the repayment as we would with financial debt. However, the repayment plan can be flexible. Extending the financial debt metaphor, I like to use a special case - flexible mortgages - to describe the various methods I employ for repaying technical debt over a project's lifetime. Flexible mortgages generally allow you to take the following actions:

Regular monthly repayments : In agreement with the product owner, a fixed part of each sprint can be reserved for repaying technical debt. In the interests of open and honest communication and keeping things visible I maintain an explicit technical debt backlog as part of the product backlog. During sprint planning, the scrum team negotiates the inclusion of technical debt items with the product owner. Consequently, a typical sprint becomes a concoction comprising a selection of high business-value user stories, a selection of the more risky technical debt items, and some slack containing a handful of low business-value user stories. I dedicate approximately 20% of the sprint's velocity to slack, leaving 80% to be divided between delivering business value and repaying technical debt.

Lump-sum repayments : If it's acceptable to the product owner, an entire sprint can be dedicated to repaying the technical debt incurred by previous sprints. This approach may be considered part of a recurring stabilisation strategy (if you consider stabilisation to be more than preparing a product for release), which occurs periodically throughout the project.

Borrow money back : Sometimes, in order to repay some technical debt in one place you inadvertently (or advertently) create a smaller piece of technical debt in another place. Perhaps, there's not enough time left in the sprint to completely repay a piece of technical debt, e.g. a refactoring was more complex than anticipated and consequently a tactical solution had to be left in place that will require more refactoring later on.

Take payment holidays : Some dirty solutions may not require immediate refactoring if, given certain circumstances, they are considered to be of acceptable risk. Therefore, some sprints may not repay technical debt and instead focus entirely on delivering business value. However, it should be agreed with the product owner that deferred technical debt must be repaid sooner rather than later.

Underpayments : If the technical debt is small or it has acceptable risk, the scrum team can spend less time in the sprint repaying technical debt and more time focusing on delivering business value.


Further reading:
Technical Debt by Martin Fowler
Don't Live with Broken Windows, A Conversation with Andy Hunt and Dave Thomas, Part I by Bill Venners
Climbing Out of Technical Debt by Johanna Rothman
What Testers Can Do About Technical Debt by Johanna Rothman