The concept of the "golden" and immutable database schema makes me crazy.
Agile methodologies, like SCRUM, have been adopted by many development groups to account for the fact that a perfect and unchangeable requirements specification will never exist before programming begins.
However, a big impedance mismatch will threaten your efforts if the application's database schema is under the control of a separate DBA group that is following a traditional waterfall methodology. (Note that I am talking about the application's database schema and not enterprise data store schemas.)
Academically I have seen and discussed many different ways of dealing with the issues associated with database changes. Martin Fowler and Pramod Sadalage discuss many of these issues in "Evolutionary Database Design".
In practice I have favored individual developer database instances with data architecture/DBA review. Just as solution architects don't babysit each system design change I don't think that data architects or DBAs should either. Any issues related to a design change can be dealt with using regular reviews and subsequent re-factoring.
In this practice the database schema and build scripts are part of the solution. To get a local database instance to work with the developer just gets the latest solution from source control and runs the DB build script. If they need to make changes to the DB then these changes are made and tested locally by the developer and then finally checked into source control for the rest of the team. The developer who makes the DB changes is also responsible for making sure that any required code changes are also checked in at the same time. A communication mechanism needs to be put into place so that the rest of the team knows that they will need to update their database at their next integration point (i.e. source code get latest).
Depending upon the phase of development, changes may be made to the original schema and everyone will have to rebuild their database or changes will be implemented as alter scripts and everyone will only have to update their database. Once the system goes to production all modifications will need to be implemented as alter scripts.