Technical Debt Goes Generic
Rally’s Richard Leavitt mentioned “his” technical debt in a conversation the two of us had last evening. As Richard is the head of marketing for Rally, I was expecting to hear about some deficit in the functionality, design, coding or testing of one of the market and customer facing websites his department deploys. I was dead wrong.
Richard was actually using technical debt in a generic sense. Anything in his department that they had to rush through and now plan to go back to and revisit/improve/fix is categorized as technical debt. The term applies to (say) laying the foundations for a marketing campaign as much as it does to re-architecting an application in order to improve its performance.
I don’t really know how wide spread the use of “technical debt” in this generic sense is. I am, however, impressed: another term of art is starting to get into the English language! How appropriate that such use of the term starts at a company that applies Agile values and practice to most of its operational and business processes.
The Agile Executive 
I’ve definitely adapted the term debt, but prefaced it with the appropriate discipline. In my realm, I tend to see lots of ‘design debt’ or ‘usability debt’ due to work that is released but will be difficult to use and will need to be fixed later.
Jeremy Kriegel
November 4, 2009 at 3:06 pm
Do I know your feeling, Jeremy.
I think the other case is when you go through a period of insufficient resources. You identify, and hopefully backlog, various items you will need to go back to.
Israel
israelgat
November 4, 2009 at 7:06 pm
Totally agree that the aim is not to release something that’s hard to use in the first place.
Are there not cases, though, where a strict approach to MMFS lets us release only to find that users are delighted with the product and the stories we initially saw as ‘usability debt’ fall by the wayside? Nice-to-haves that we didn’t need?
Susan Teschner
July 18, 2011 at 11:01 pm