I'd say that if any of that is happening, then yes, you're doing agile wrong. :) Most importantly, a product where that happens is missing a definition of done

I'd say that if any of that is happening, then yes, you're doing agile wrong. :) Most importantly, a product where that happens is missing a definition of done. Done includes, among other things, automated tests, good code quality, and a product owner looking at it and saying, "yes, this will actually meet the business requirements." If it doesn't get done within the 2 weeks, then it rolls over to the next two weeks. If not enough shit gets done in a 2 week sprint (and yes, I hate sprint as a concept), then you schedule less work. That two weeks are efforts to work in small chunks (something good developers do anyway) and give a general sense of when the project will be done. That means that everyone is aware earlier that a project's scope or timeline is unrealistic. You're doing this rewrite because shit is slow to change; it's the developers' fucking job to point out that repeating the same problem again is a waste of money. (Agile means pointing out unicorn fantasies as early as possible as to make the hard decisions before the project is 3 months late.) Now, personally, I prefer continuous flow boards and cycle time to measure that. Then, you can skip the sprint bullshit, but that's a detail. Finally, the problem you describe is a rewrite. If the problem is that nobody wants to touch that code with a ten foot pole, then you are "fucking empowered" to spend that same time to clean that shit up. Unless business requirements have changed and the software is no longer the right thing to do (see: implements the actual business requirements) then the right, sane thing to do is get a copy of Michael Feathers' Working With Legacy Code and dig in. Using an agile methodology to do a dumb thing doesn't make it any more or less dumb.