During the years when I started to learn agile development, especially TDD and good OO, I had the fortune to work as a consultant for a company that ran a massive number of small projects, each lasting for approximately 3 months. This was exactly the amount of time I needed to learn something new, apply it, and discover the limitations of it.
At the end of each project I realized there was a much better way of doing things, and the effort to rewrite the code probably would have eaten me alive. But hey, no problem, I’ll be on a new project next week, with a fresh code base to apply my new findings at.
At that time the recurring project restarts actually was a good strategy to improve the average code quality! If I would have had to keep on working with the same code base I would never have been able to incorporate that much new technology and knowledge in the code base, and I would never have learned that much about what makes code good.
Later on I also learned refactoring, but I doubt I would appreciate it as much if I hadn’t learned about good code first. I think this is one of the great limitations of refactorings, it requires a lot of experience to know in what direction to go.
By allowing people and projects to restart you can make people raise their sight to take a new direction, to get a new vision of what it will be like there, to learn and incorporate their experiences in the new. Granted, most agile processes have retrospectives, but sometimes they are not enough a kick-in-the-butt to start off something new.
If it is hard to introduce refactoring in order to improve the code base, or when retrospectives don’t seem to do it either; try a fresh start iteration where you can dream a little! If you realize it’s not leading anywhere, just keep on working with the old code base. In the long run you will probably gain more from the new perspectives than the lost iteration cost.