[xtracto]

I disagree with this sentiment, well at least I disagree that it is SCRUM's fault. I think this is a problem that resides higher up.

I have been in teams that to take the time to solve technical debt and even generate technical wealth. The best approach that has worked for me is to divide the development available time per sprint in: 33% new product features, 33% existing product maintenance, 30% Solve Technical debt (or 20% tech debt, 20% product debt with a 30-30-20-20 split).

With this I try to show that the problem of development teams NOT fixing their crap i not an issue of the Agile/SCRUM process (or any other process), it is an issue of management that prefers to ignore the mounting technical debt (until it explodes and you have the Github downtime, or LinkedIn leaks or the fact that changes become slower and slower due to codebase complexity).

[JoeAltmaier]

Hm. That sounds like a process issue. Which is what SCRUM etc are part of. So its not process, but changing process will fix it? SCRUM + technical debt management is the cure? Then SCRUM was missing something.

I put the blame squarely on the process, whether its SCRUM or whatever.

[mindcrime]

Then SCRUM was missing something.

Scrum is missing a LOT of things, because it's very specifically intended to not be highly prescriptive. The whole idea is to iterate, use empirical feedback, and evolve your process to match your context.

Right near the beginning of the Scrum Guide it reads

Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.