Situation: The dba is an offsite contractor who keeps the entire DAL code checked out in TFS. It would be nice as the front end developer to be able to add columns, and tweak procs and whatnot, without having to rely on waiting for this dude to respond to your emails to do the work.
Question: What would be a recommended solution/process that would allow for more rapid/agile development, while maintaining data integrity as well as peace love and happiness among the team?
Martin Fowler and Pramod Sadalage have written an excellent article on this subject.
Every developer has his own database to which changes can be made. These changes are then communicated back (as a changeset) to the DBA who implements them in the master database, so he's still involved in the process, he probably knows best about the structures and needs of the database anyway. I think that's the best approach as it's satisfactory for all people involved in the process and it's also very agile.
You can change the DAL in a similar manner. Just make your changes and provide a changeset for the DBA when you think you're done, so he can review it and merge it into his master.
Wellll, when I'm doing the DBA thing, I have been known to lock everything up so the damn dirty programmers can't get their mits on it. Everybody thinks they know how to do it better, and they "tweak" things to make them easier for themselves, and it causes an unholy mess.
The other alternative is to throw it wide open, and let the programmers melee on it for a while, then jump in and impose order as things begin to wind to a close...This is certainly more "agile", but it can be a real nightmare depending on what has to be cut out or changed...DBAs often have a better understanding of the project as a whole, and some changes that seem innocuous can be problematical.
If he's going to be the sole gatekeeper, he needs to either have a fixed spec, or be able to "sell" his vision to the rest of the devs.
There is a major problem that supercedes any other problem:
Why is he allowed to do this? No one should have a file checked out unless they're actively making edits. There should be a team policy about checkouts.
The contractor (whether they like it or not) works as part of a team, and sometimes other members of the team may need to make changes. This is a communication issue. There's no automated way to fix this communication issue, unfortunately.
Instead of horizontal layers, I prefer to work in silo's across layers.
That way no 1 person/team can block in this fashion.
It also means you're developers are multi-skilled and able to move around features much more easily.
Of course, there are sections (UI design, and DB design) that may need more speciality work, but you get the idea.
Simple, If you don't already, you should have a 3 Environments:
The develoment environment should be administered by your developers.
You might also want to add an RC environment.
Another answer, If multiple environments isn't possible, you could develop against a mocked repository... This way you build your models and then your contractor is responsable for making your models match the DB. In a way this is better since it frees your developers from worrying about the database.
You problem appears to me to be one of manpower. It is apropriate and necessary for all potential daatbase changes to be approved by a database specialist. If the current person cannot keep up with the work in a timely manner, you need more database specialists.
This is a management issue as much as a technical one.
There are certainly valid reasons for a DBA (regardless of whether onsite or off, contractor or employee) to keep developers away from making any type of database changes.
However the main issue you defined is one of availability. Does your manager know that time/money is wasted waiting on this person? If not, you might want to bring it up how everyone is sitting around.
