Several really good articles summarize the crushing consequences of technical debt. But where does it come from?
Martin Fowler’s blog posting “FlaccidScrum” notes:
“What’s happened is that they haven’t paid enough attention to the internal quality of their software. If you make that mistake you’ll soon find your productivity dragged down because it’s much harder to add new features than you’d like. You’ve taken on a crippling TechnicalDebt and your scrum has gone weak at the knees.”
It doesn’t matter if your process is waterfall, scrum, kanban or some other agile practice; technical debt is process-angst – it can simply crush your team & product.
At the Toronto Agile 2015 conference, Scott Ambler provided a very good presentation of the source of technical debt and mitigation strategies. His presentation & slides are available and very worthwhile.
Now consider an architect being offered a chance to bid on a bridge. The owner takes the bid and says: “Cut the price in half, bring the delivery in by 6 months and the contract is yours!” The architect says: “No thank you and walks off the job.” In the software business, how many folks simply sacrifice quality and accept the deal?
Leadership at all levels is necessary to address this. (Imagine if hospitals took on debt like this?) Team leads can implement the day-to-day processes and feedback mechanisms. Managers can review bug counts vs unit tests vs features for velocity. VP’s can determine how processes can be transferred across teams…
If there is a dearth of leadership and you still have little or no technical debt – you are in a very rare universe. Enjoy it while it lasts!