When Band-Aids Live Forever

During my recent Professional Scrum Product Owner - Advanced classes, one of the class participants - Anne Rosine - made the comment that "Band-aids last forever."  We were talking about technical debt and the tendency for organizations to do a quick fix, but then not come back around and, well, fix it.

Band-aids are supposed to be temporary.

You put one on, it does its job, and then you take it off. But in many organizations, band-aids have a funny way of sticking around far too long. Workarounds become “the way we do things.” Temporary fixes become sort-of permanent. Work-around processes stay in place Sprint after Sprint and month after month and even year after year.

That’s technical debt.

Technical debt isn’t always bad. In fact, sometimes it’s the right choice. If you’re testing a new idea, exploring market demand, or running an experiment, it doesn't make sense to build a fully scalable robust solution. A quick fix can help you learn fast without over-investing too much too soon. That kind of technical debt is intentional - and intentional debt can reduce risk when done well.

The problem isn’t that we create band-aids. The problem is that we forget they’re there - or worse, ignore them because we're under pressure to deliver more stuff.

Bad technical debt is what happens when teams cut corners without realizing it, or under pressure from leadership, or when “temporary” solutions never get addressed.

Over time, these band-aids slow teams down, increase risk, and make change harder. Eventually, the cost of keeping them becomes higher than the cost of fixing them - but by then, they feel permanent and besides that, there are a LOT of them out there. 

In many industries, technical debt has gotten so bad that it's a crisis. Many organizations have accumulated technical debt for 20 years or more. So much so that it often feels like a re-write would be better than fixing the current system. The "Modernization" trend seems to me sometimes like a desperate bid to escape technical debt.

I once worked on a team where the leadership felt that we would need to replace our current system because it had become so unwieldy.  Technical debt had been accumulating - unchecked - for 20 years due to the fact that first, no one really owned the product, and second, we were delivering updates via a series of projects.  So (ironically) a new project was created to address the most urgent technical debt while we prepared to purchase third party software.  We decided to implement Scrum, and we found a Product Owner to help us order our work.  After six months, we had cleaned up so much technical debt that buying a new system was not necessary.  Scrum was so effective at delivering this project that it was operationalized and that system (and the Product Owner) was still in place years later. 

Product Owners play a huge role in preventing technical debt because they own the product - not just the new features. That includes quality, maintainability, and the long-term health of the system. Fixing technical debt is product work, and it belongs on the Product Backlog alongside features and enhancements.

For that to work, the Product Owner must have the authority to order the entire Product Backlog - including fixes for technical debt. Sometimes a new feature will be more important than a refactor. Other times, paying down technical debt will deliver more value by reducing risk or enabling faster delivery later. Those tradeoffs are part of Product Ownership.

Technical debt becomes dangerous when it’s invisible and unmanaged.

Making it visible—by capturing it in the Product Backlog—turns it into a conscious decision instead of an accident. The question stops being “Can we afford to fix this?” and becomes “Is this fix the most valuable thing to do next?”

One of the best ways to prevent new, unchecked technical debt from piling up is a strong Definition of Done. A clear Definition of Done sets shared expectations for quality. It helps teams avoid introducing unnecessary shortcuts and ensures that “Done” really means ready to build on.

Band-aids aren’t necessarily bad. Sometimes they’re exactly what you need.

But if they live forever, you don’t have a temporary fix—you have a structural problem. Scrum gives teams a way to see it, talk about it, and decide - on purpose - when it’s time to finally rip the band-aid off.