Best Practices of Agile SCM

• Depending on the needs of the project, the next step is usually to automate the build process, if not done already.
• It's usually a good cutover point once we have all the artifacts checked in and the build process automated. So we typically schedule a demo meeting with the project stakeholders to show them the final solution, and schedule a project cutover event.
• The project cutover event occurs during off-hours while the development project is out of the office. This event collects all of the software artifacts from their original locations and imports them into the new SCM repository.
• The next morning is developer training. We usually try to keep this as brief as possible so as not to "slow the bus" too much. We offer lots of references to resources so that when the developer has a question, they know where to go for answers.
• Hyper-support. For the next several days, we perform what we call Hyper-support. This involves wandering the halls of the development area asking developers how things are going. It's amazing how many users will run into the first challenge and never pick up the phone - they just curse the change. By simply dropping by shows that you are truly interested in making this successful, puts a friendly face to the support and makes it much more likely that your user will pick up the phone or send an email next time he/she has a problem.
• Collect feedback and measure metrics. This part gets forgotten far too often. Remember the point of the "pilot" is to collect the feedback and improve the infrastructure. We typically send out questionnaires via email as well as schedule follow-up meetings. Sometimes it really helps to have the feedback meetings be a brown-bag event.
• Have some give-aways such as a coffee mug, T-shirt, etc. You'd be surprised how much buzz that will generate within a group. With one customer, we gave out mugs and t-shirts to project members who had finished converting to the improved SCM solution that said "Got SCM?" They were a HUGE hit and we had project teams signing up to be next.

Rollout Phase

Once you've fine-tuned your Infrastructure and you're ready to roll out a solution to several other projects, there's some preparation that should occur. If you're looking at a small number of projects, then estimate each of them individually. Estimating large groups of projects takes a more creative approach.

We worked with a customer where we rolled out an enterprise solution to approximately 600 projects. We estimated and scheduled the projects based upon three variables: (1) Project size; (2) Project maturity; and (3) Project type.

Project size determined the number of developers (Small, Med, Large) that we would have to train. We also find that the larger projects typically have more places to hide artifacts and the CI collection process usually takes longer.

Project maturity is based upon the developers' past experience with the new SCM Solution. Remember that SCM Solutions address all the facets of a business process: people, process and technology - not just technology. If they are familiar with the process and technology because of involvement with another project that's been converted already, it likely won't take as long to rollout the solution. We ranked them light, medium, heavy.

Project type has quite an impact as well since the work that you have to do to convert them can be quite a bit different based upon their environment. Examples of this could be mainframe, C/C++, Java/J2EE, etc.

This estimating process allowed us to generalize each project and to determine a