A big part of agile development is only writing code for what you know you need today and not writing code for what you might need tomorrow. This idea is also known as “You Aren’t Gonna Need It” (YAGNI).
One implication of this is that code will need to change frequently. So change should be expected and be made as easy as possible.
Recognize that nothing is set in stone.
Especially during an iterative phase of development, it is common to encounter code that seems incomplete. Perhaps it doesn’t cover all the cases you thought it should. Or maybe it’s oriented in a direction that’s incompatible with the current product direction.
When you encounter code in this state, it is easy to shy away from changing too much. Maybe your current work could be shoe-horned into the existing structure. Or maybe it touches components that you’re not too familiar with.
But this inclination to not change too much can cause a snowball effect, requiring a significant refactoring later on. It is often beneficial to tackle refactoring when it is small and more manageable.
At this point, you may even be tempted to say, “But I don’t want to over-build!” I didn’t intend to get into a discussion about YAGNI (lots has already been written), so I’ll just say that YAGNI does not have to result in spaghetti code. Clean coding practices are still a Good Thing, even under iterative development. That’s because clean code that is easy to understand is easier to change.
Write code that is easy to change.
The next developer to work on your code is much more likely to make good changes if you set them up for success. Tests can be another way to make code easier to change, but there is a balance (they can also make it harder to change).
On one end, having zero tests means less code to update when you make changes! But it also doesn’t provide any assurance that your changes are correct.
On the other end, a test suite that is basically a rewrite of your application in different words will give you a high degree of confidence that it works correctly. But the overwhelming number of tests that must be updated for every change will greatly discourage change.
It can even feel wrong to delete an existing test. But as code changes through phases of iteration, tests can become obsolete or redundant. So removing them is as important as refactoring code.
Even better, write fewer tests by making bad code impossible to write.
Keep the bigger picture in mind.
Although YAGNI encourages a sort of tunnel vision when it comes to building iteratively, it is still useful to keep the general direction in mind. You might be faced with multiple possible implementations. One is cheap but is basically a dead-end; the other would require only slightly more time and is more in line with the anticipated direction.
Of course, neither one of these will always be the right choice. But if you’re not aware of the overall direction (of the project as a whole, or even just parts of it), you might not even know what all the options are.