We do Agile dev in our shop and spend a decent amount of time planning DB changes up-front to avoid doing it over as we move forward. Sometimes we overplan, sometimes underplan, but it helps to at least attempt to get it right up-front. It helped once the team finally understood that you couldn't just drop tables and create new ones like you can with DLLs and EXEs. It took a while for that to sink in, but they understood it and it helped us handle DB migrations a little better in the future. There are still times we need to do a large data operation the night of a release, but on the whole knowing that helped us make better plans for the future. Finding the correct balance of "just enough" as opposed to "plan it as far out as we can" can still be challenging, but having the team backing up those decisions makes a huge difference.

I actually like the Agile plan when it can work. I've seen too many large DB Projects fail due to using waterfall (think Amazon Falls) methodology and then years of work to deliver the finished project. I'd much rather start small enough to show something and get feedback as we go. That helps us make course corrections and tackle more important needs as they come up instead of delaying them further.