While that's certainly true - if it weren't going to involve a relational database, we'd be reading about this on AgileDevelopmentUsingExcelAsDataStoreCentral.com.:w00t:

It's a shame to come in with all guns blazing, especially when making assumptions about the posters and what they "do for a living". It's also a shame you didn't catch the fact that David is now espousing Agile, albeit it with some reservations. After all - the job of the DBA is to make sure that whatever is being done on the data side is solid, and ultimately doesn't tear the rest of the house down.

Like just about any methodology - Agile can be very powerful if implemented and run correctly. However - like any other methodology - a lot of bad implementations of Agile have also been advanced, often by folks with either faulty understandings of what Agile is about or those who have no care or understanding of some of the roles involved in such a project. Once such implementation is the Extreme Agile programming David mentioned, which more or less advocates the data design as being irrelevant or an after-thought, which then of course makes the job of those with the DBA title or role very difficult, unpopular and frustrating.

The thing to remember about this is the person filling the role of DBA isn't necessarily being an A**hole when they're asking to look a little ahead. It's that (like Scott Ambler himself points out) the further into something like this - the harder/bigger continuous refactoring of the data gets to be. Making the developer's job easier at the expense of sending the data team through a never-ending loop of increasingly hard iterations to remodel/refactor the data is viciating the purpose of Agile to begin with (it's to save work for the TEAM, not help the developers and scr** the data side). I don't know when the last time it was when you tried to change the tire on a moving car - but it does get a little tricky.