How to implement check in policies

We met with Teamprise this morning to discuss check in policies. One of the larger business units in the company has a long list of policies they'd like to see. Including, but not limited to, Work Item Association, Comment Association, Forbidden Pattern Policy and a Are You Breathing Policy. We (a smaller business unit) on the other hand, are only looking for the first one, Work Item Association.

If you're coming from a tool that has never enforced check in policies before (like we are with VSS) here is my suggestion for how to best implement them. Keep things simple and follow the three step process I've laid out below.

Step 1) Don't implement any policy right away. That is, try to mimic your current source control workflow in TFS. If users could check in and out at will, then let them. This non-intrusive approach allows end users to get comfortable with the new tool, by using a common approach they're accustom to. Remember, change is hard for people.

Step 2) Start with one policy and one policy only. I'd suggest all user bases start with Work Item Association. Asking the user to simply select what piece of paperwork (e.g. Task or Bug) the code was addressing, is an innocuous approach to improving your processes. Remember, change is hard for people so don't Big Bang them. Lull them into a better place like you do when boiling a frog (not that I've ever tried that...).

Step 3) Don't get crazy. That is, don't feel like you have to implement every single check in policy known to man. Engineers are smart, that's why we're engineers for goodness sake. Assume that you don't need a check in policy to verify that we got morning coffee. We all know how to get morning coffee. A tool does not need to tell us so.

By following this three step process, you'll find a more accepting user base and a better TFS/Teamprise implementation.