Development Cost
Chances are your company is spending more money on development than it needs to be. To oversimplify the problem and to throw arbitrary values that have real-world weight that I have experienced in my 20+ years of software development, I would estimate companies can be 2-3 times more efficient in the long-term by adding 10-20% of technical debt and TDD to your sprints. I only worked for one company that was developing code this efficiently; the rest were burning 2-10 times as much development effort on issues like trudging through technical debt with "quick" fixes. But I felt the difference and it had other interesting side-effects: higher employee retention, retaining higher quality developers, and increased developer happiness.
What did that one efficient company do differently? All of their project managers and management had to have software development experience. While I don't believe this is necessary, the reason I believe it worked is because management trusted the developers. Things like "technical debt" and bugs didn't get buried in the backlog, management knew that the cost would be much higher if left in the backlog and understood the weight of the developer issues. They trusted the subject experts. And this should be extended to all of your staff e.g. BA, QA, PM, management, etc. These are your subject experts and they know their domain best, trust them and the issues they bring up. Action on issues that are brought up in sprint retrospectives.
Because I like terrible analogies, imagine micromanaging a contractor building your house and telling him "I need you to hammer in nails with a screwdriver". Your reasoning might be what you know about that domain, you know that a screwdriver is lighter and that the contractor can swing it faster. But you shouldn't be micromanaging, much like project managers shouldn't be using Agile in such a rigid fashion that developers don't have time for things like writing tests, tackling technical debt, and fixing edge-case bugs. Trust your subject experts and give them the authourity to work with project management. This doesn't mean you ignore business value and deliveries. There are also occasions where code quality matters less: one-off deployments like a landing page or a seasonal feature, for these cases I wouldn't recommend TDD or worry about technical debt. But the rest of the time, the entire team should be influencing what goes in the sprint. If the project manager is constantly punting technical debt items to the backlog, you will grind to a halt over time. I've seen projects that have so much technical debt that it was faster to write the entire app from scratch.
So how can you fix this problem? What does the problem look like?
