Ron Jeffries explains why software quality and speed of delivery are not mutually exclusive. If you want to continually deliver working software quickly, then you need to maintain high quality:
http://xprogramming.com/blog/2009/02/01/quality-speed-tradeoff-youre-kidding-yourself/
Uncle Bob has also posted his thoughts:
http://blog.objectmentor.com/articles/2009/02/03/speed-kills
I often find there is a lot of focus on delivering software quickly, but not so much on maintaining quality. I think this is because it is generally considered that maintaining high quality means greater expense and later delivery. However, the higher the quality of code, the better able we are to deliver working software quickly and repeatedly. My belief is that the quality leaver should never be touched, or you risk taking on crushing debt.
Not letting quality drop and technical debt creep in is a good thing. But you must make sure you are also de-scoping appropriately and that this is communicated to and decided on by the right people.
Yes, but maintaining quality should not result in de-scoping. If anything you should find you are able to improve delivery by reducing defects and clarifying code.
Reworded the title
Over time it should. But if you find that within a given iteration you have to take an unexpected course of action that takes care of or avoids technical debt, then while you should absolutely avoid delaying refactoring, you must make sure that it is communicated correctly so the project as a whole can stay on track.
Yes, that’s very true for large, break-through refactorings, as these can affect planned work. But small, continual design improvements should just be part of the development process.