I've had both good and bad Agile experiences as a DBA.

In one case, "we're an agile shop" was used mainly as an excuse to avoid planning and documentation. Lots of half-finished software that was of some use, but that was hated by every user.

Another case was a mix of up-front planning on what the end result's functionality needed to be, and then more or less documented iterations up to that point.

All to often, I've run into the idea amongst "Agile developers" that properly planning the database was somehow counterproductive, and then they end up with a database that routinely has locking conflicts, has all the performance of a glacier and what I like to call "database epilepsy". Tables are slapped together with "we'll fix it later" attitudes, and you have dirty data all over the place because part of "fixing it later" is leaving off foreign keys, column constraints, unique indexes, etc.

On the other hand, I've heard (though not experienced) stories of databases so over-planned and over-normalized that no human can possibly manage them, where adding a new function, or changing the definition of an entity in some minor way, takes months of coordination and effort, if it can be accomplished at all.

As with all things, I think Agile methodology should be taken in moderation, and treated with a due amount of logic and review.