I have a love/hate relationship with "technical debt". Having covered apps modernization, rationalization, and portfolio management at Forrester for more than a decade, I have a keen appreciation for the concept of technical debt - in all its permutations.
So I love the term for the sentiment it expresses about the need for change:
As we have modernized applications over the past 4 decades, we have "kicked the can" down the road far too many times - opting for expediant change over "refactoring to make it right"
Within any mature single app, technical debt spawned by years of compromise can accumulate to daunting levels
The debt eventually reaches the point of becoming a self-fulfilling prophecy - today's debt is too big to tackle, so we kick it down the road and watch it grow out of control
Across the entire apps portfolio, the accrued debt cripples firms by gobbling up huge percentages of the available business technology (BT) spend
As we rush to build out customer facing and mobile apps to address the age of the customer, the technical debt within the systems of record act like an anchor on change velocity - at both the app AND portfolio levels
And I hate the term because well-intentioned techies wield it like a bludgeon to pound business leaders with an urgency to act. But imagine for a moment how it sounds to business leaders, how they react to the term:
"If it's technical, then its your problem Mr App Dev leader, not mine - I'm a business leader"
"This debt you want to hand me ... YOU created it, YOU made technology decisions - it's your problem, don't try to hand me a bill to clean up YOUR mess"
Within the modern applications era, regardless of whether new software applications are being developed and delivered for mobile, tablets, or the Web, the truly successful app-dev leaders will be those who focus on delivering constant value and incremental improvement to their business. That is a totally different perspective from “I need to keep control of my team’s productivity to make sure that we stick to our estimated costs, scope, and project dates.” Of course, the interest in cost is never going away, but app-dev leaders today have a great chance to enhance their conversation with executives and business stakeholders and add value to the conversation.
However, as the recent research I just published, Agile Metrics That Matter, proves, while some of the most advanced Agile teams do use new progress, quality, efficiency, and value/benefits metrics (these to a lesser degree), some software development industry luminaries have worked and are working on new methods to measure value in software development. But it’s still early days!
I’d like to summarize here some good old practices on establishing metrics that count together with some of the new findings of the research: