@Scott – I like that approach as well. I guess that role you describe could work out quite nicely for countering the problem of fine grained changes too. Neat.

I still go with the rule that once a change script is checked in, it is published and can never change (unless there was something really, really wrong). Otherwise it creates confusion (do I really have the latest schema?).

One thing we've tried to do during those times when the schema is still in flux is try to batch things up by nominating one person as the person to collect changes, verify them, and check in a change script. It's not a great job to have, but these periods usually don't last very long and it avoids the problem of too many fine grained change scripts.

My other $0.02

We also, automatically build an "alpha" environment between dev and UAT that can be tested by managers internally so they don't have to checkout and build code and/or update their database to review functionality.

The best part though, is the automated deploy of change scripts to produciton. Now I have an installer for code and an update batch file/power shell script to update the production database! Manual deploys only take a few minutes to perform, and could eventually be scheduled to be automated. All of this thanks to change scripts!