Agile methods call for fearless refactoring. Fearlessness on its own is foolishness. Fearlessness based on skill is freedom.
When developing code, you must develop it to be testable. I could talk about the theory of developing testable code, but the practice can be enforced with Test Driven Development, now more commonly referred to as Behavior Driven Development (see behaviordriven.org). If you define the tests your code must pass before you begin coding, you have the natural motivation to make the code testable.
Having written well designed code and solid automated tests, you can be free to refactor your code as needed. This means you are free to develop your code in a way that allows you to demonstrate business value from the first builds. You don’t need to fear that your tactical decisions for today might be impacted by the strategic needs of tomorrow. If you discover you’ve made a bad tactical trade-off, you can refactor to correct the error, confident that your tests will catch any mistakes.
One caveat, don’t combine refactoring with other activities. Whether you need to refactor to fix a bug or to add a feature, do the refactoring first. The refactored code should behave exactly like the code you started from. Once the refactoring is complete, then make the changes. Separating out these two activities makes clear where you have to make changes if one of your existing tests doesn’t pass. First refactor, then test, then write the tests for the new functionality, then write the new functionality until the new tests pass.
If you follow this process, you can be fearless.