Technical Debt: The Elephant in the Scrum Room

We need to talk about the elephant in the room. Not the one from that tired idiom about obvious problems nobody wants to discuss — though that applies too — but the one that’s been trampling through our sprint planning sessions for years now: Scrum. Or more specifically, “Scurm” as I’ve come to call it — Bad Scrum masquerading as methodology while systematically ignoring the very foundation it claims to stand on.

As Warren Buffett once said, “Someone’s sitting in the shade today because someone planted a tree a long time ago.” In our world, we’re often so busy chopping down trees to meet this sprint’s targets that we forget nobody’s planting new ones. And when the forest is gone, we wonder why we’re standing in a desert.

The Manifesto’s Forgotten Second Page

Here’s something that might shock you: the Agile Manifesto has more than four values. It has twelve principles. Yet in my years working across continents — from Australia to here in Bangkok — I’ve met countless teams who can recite “individuals and interactions over processes and tools” but draw a blank when you mention principle number nine.

Let me refresh your memory:

“Continuous attention to technical excellence and good design enhances agility.”

There it is, right there in the foundational document. Not hidden in footnotes, not implied between lines — explicitly stated. Yet we’ve built an entire industry around stand-ups, planning poker with the latest Slack bot, and retros using whatever tool we discovered last week, while systematically ignoring this fundamental principle.

Even more telling is principle number eight: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

You know what directly threatens sustainability? Technical debt. It’s the compound interest on all those “we’ll fix it later” decisions, accumulating faster than credit card debt after a particularly enthusiastic night out in Sukhumvit.

The Product Owner Paradox

Let’s address the core dysfunction: Scrum, as religiously practiced in most organisations, puts a business person — the Product Owner — in charge of prioritising everything. And if you follow this doctrine without question, you’re heading straight for a cliff where technical improvements never get prioritised over product features until the entire system collapses under its own weight.

Most Product Owners I’ve encountered aren’t former software engineers. They don’t viscerally understand that ignoring technical debt is like what the economist John Kenneth Galbraith observed about financial speculation: “The euphoria is followed by the crash, and the crash is followed by recrimination.” Except in our case, the euphoria is shipping features quickly, and the recrimination comes when deployment takes three days and nobody remembers why that one service needs to be restarted in a specific order on Tuesdays.

You wouldn’t let someone who’s never driven design the braking system of your car, yet we routinely let people who’ve never debugged a race condition at 3 AM decide whether refactoring that critical service is worth the sprint points.

The Creative Escapes

So what happens when reality meets methodology? Companies get creative. They invent escape hatches from their own processes:

Atlassian’s 20% Time (Google famously did this too): One day a week for whatever engineers want to work on. Brilliant in theory, except when sprint commitments mysteriously require 100% of your time, that 20% becomes the first casualty.

Innovation Days/Weeks: The tech equivalent of a spa retreat. We pause everything, fix some debt, build some cool prototypes, then return to our regular programming of accumulating more debt. As the chef Anthony Bourdain once said about quick fixes in the kitchen: “The plate might leave the pass looking good, but the mess in the kitchen tells the real story.”

Agoda’s 30% Tech Time: Here at Agoda, we’ve institutionalised what others treat as an exception. Thirty percent of engineering time is explicitly reserved for technical improvements. It’s not perfect — nothing is — but it acknowledges a fundamental truth: if you don’t schedule maintenance, you’re scheduling a breakdown.

The Path Forward

The solution isn’t abandoning Agile — despite its flaws, it’s still better than the waterfall days when we’d spend eighteen months building the wrong thing very carefully. But we need to stop treating Scrum as scripture and start treating it as a framework that needs adaptation.

Here’s what we’ve learned works:

Make technical debt visible: If it’s not on the board, it doesn’t exist. We need to quantify the cost of debt in terms POs understand — velocity degradation, increased bug rates, deployment failures.Establish non-negotiable engineering standards: Some things shouldn’t be up for prioritisation. You wouldn’t negotiate whether to change the oil in your car; nor should you have a product backlog item for writing test automation that gets split from the work itself, some technical maintenance is simply the cost of having a functioning system.Foster T-shaped collaboration: We need POs and engineers working together on prioritisation every single sprint. POs should be actively encouraged to learn about technical debt — sit in on architecture discussions, understand the real cost of that workaround we implemented six months ago. Similarly, engineers need to understand business drivers, customer impact, and market pressures. When both sides become T-shaped professionals — deep in their expertise but with broad understanding across disciplines — the “us versus them” dynamic dissolves. That database migration isn’t competing with features; it’s enabling them.Measure the right things: If you only measure feature delivery, guess what you’ll get? Start measuring deployment frequency, mean time to recovery, and code quality metrics. What gets measured gets managed.

The Bottom Line

As Peter Drucker wisely noted, “There is nothing so useless as doing efficiently that which should not be done at all.” We’ve become remarkably efficient at accumulating technical debt while religiously following a methodology that was supposed to make us more agile.

The irony isn’t lost on me: we’ve taken a manifesto that explicitly values “responding to change over following a plan” and turned it into a rigid process where the PO’s prioritisation is gospel. We’ve taken principles about technical excellence and sustainable pace and buried them under a mountain of ceremony.

Technical debt isn’t just a technology problem — it’s an organisational dysfunction dressed up as a methodology. Until we acknowledge that Scrum, as commonly practiced, has a massive blind spot around technical sustainability, we’ll keep having the same conversations about why everything takes longer than it used to.

The next time someone tells you that refactoring isn’t a business priority, remind them that neither is bankruptcy — but ignore the warning signs long enough, and that’s exactly where you’ll end up. In software, as in life, you can ignore reality, but you cannot ignore the consequences of ignoring reality.

Now, if you’ll excuse me, I need to go update our team’s capacity planning — apparently, our latest feature requires us to work around that service we’ve been meaning to fix for two years. But hey, at least our velocity looks good on paper.

What’s your experience with technical debt in Agile environments? How does your organisation balance feature delivery with technical sustainability? Drop a comment below — I promise to read them during my next 30% tech time.