The Company
There are many situations we run into when starting with a new customer or company. Generally, there exists some form of ad hoc SCM that has evolved to meet tactical needs in a disjointed way across the organization. Sometimes we are brought in because of a regulating agency's audit identified problems in the way they manage their software assets. Other times it's because of a recent change in management. In any case, there is a catalyst that causes the company to want to improve their SCM processes and technology.
The Assessment
Steven Covey's “Seven Habits of Highly Effective People" identifies one very important step that you must take before charging off to implement SCM change in your organization. One of the seven habits is, "Start with the end in mind."
We start with an SCM Assessment with the intent of developing the optimal end. Our assessments are conducted by interviewing developers, other SCM people, testers and managers from different groups in the organization to understand how they manage change in their environments, what technologies they're using, how their teams communicate, etc. The information is collected, analyzed and published in a detailed document broken down into the following areas:
- Current state of the SCM systems (people, process, technology): This section discusses how change is managed and tracked today in the development organization. The SCM disciplines focused on include version management, build management, change management and release management. It's important that this section is stated in a very factual way with no analysis or subjective comments. Its job is to merely communicate how things are done today with no bias.
- The pain points that the organization is currently experiencing: This section is the opportunity to document all the problems and issues that you heard during your interviews, as well as goals that the organization is trying to achieve. As you're collecting this information, make sure you ask lots of questions of the complaints in the attempt to understand the root cause of the issue. Group these into a small number of manageable topics and come up with some ways of measuring success against these issues. An example might be that software builds take forever to accomplish and they become a huge fire-drill effort to get them done. These releases then need fine-tuning over the next week or so before they become really testable. Determine the cost savings of creating an automated build environment that may improve this process both in quality and speed. Keep these types of metrics in your back pocket for use later in the process.
- Recommended future state of the SCM solution: Here's where your experience comes in handy. Based on the current state, technology used, and needs of the organization, develop a picture of the future related to SCM. It's sometimes valuable to actually just tell a story of the ideal development environment. Keep this somewhat high level for several reasons. First, there will need to be flexibility across project types. One solution doesn't fit all. Second, this information is intended primarily for management folk. It's tempting for SCM folks to dive into details. Our objective with this document is to communicate at a high level to whet the appetite for further learning. Feel free to throw in benefits to the organization as you write this document and relate the benefits directly to the main issues that management faces.
- Remediation plan: This is where the real magic happens. This section takes into account psychology, technical understanding of the development environments you're implementing to, and a healthy understanding of the process used and organization effected. The remediation plan forms a roadmap for the organization to gradually implement positive change -with the end in mind. Without this high level roadmap, the organization oftentimes gets lost in all the details and doesn't achieve its goals. When determining the speed at which you recommend implementing changes, factor in the culture of the organization. This means, how willing in the organization going to be to change. Some are much more agile than others are. We often break the plan down into phases based on technology types, infrastructure requirements, etc.
The Implementation Plan
The implementation plan is what is discussed in the remediation plan. It is typically broken down into an infrastructure phase, pilot phase, rollout phase, and finally the support phase. These phases may work in parallel depending on the approach you decide to take.
Infrastructure Phase
In this phase, you build standards and other reusable components of your SCM solution by project type. Let's say, for example, that you have the following development groups within your IT organization: Cobol/Mainframe, C/C++ mid-range, MS Visual Studio/.NET, and Java/J2EE. They all develop software for the same basic business customer(s). Consider some of the following items as infrastructure for different project types.
Project Naming Structures
Development IDEs that need interfacing:
- The development process: Document how the development process is supported by the technology being used. This may involve some customization for IDE integration.
- Document how changes in scope and requirements are managed, then determine and customize the technology to support the process.
- What automated build systems are available for this technology: Create a reusable template that will work as a starting point for new projects
- Document the recommended change request (defect) workflow and data requirements by project type
- Document the recommended release workflow by project type (dev, uat, systst, prd)
Pilot Phase
Now you've created the basics for a given project type, choose a project that will work with you to offer feedback, and has some level of tolerance to weather a few bumps in the road. These first-time pilot projects can sometimes incur a little disruption for the development team. It gets much better the more you do. We usually ask the development team what would define success for them on this effort and oftentimes the answer is to not impact the team's progress on the project. That's unfortunate, but common.
We like to characterize these implementation efforts as changing the wheels on the bus while it's going down the road at 60 mph. Our intent is to minimize the impact on development during this transition process, while building the capability for the bus to be able to cruise faster and more predictably once we're done. The typical pilot phase goes something like:
- Kickoff meeting where we discuss the approach and determine the specific needs of the project.
- Decide on data conversion approach. Do we bring over history from your current version control tool or grab the latest and run?
- Trial conversion and/or import. Here you convert or import all of the known software artifacts related to the project and try to run it through a mock development process following your infrastructure standards. More times than not, the project missed something that you need. Here's where you find what those things are. Be sure you capture the steps and locations of the artifacts since you will need to do this again when performing the final cutover. We usually create a script that includes the import of all the necessary files from their original locations so that the final cutover is merely running the script.
- 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, medium, and 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, and 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 total level of effort for the rollout with a relatively high level of confidence. Answering these questions also helped in scheduling the projects for conversion since we could group and assign them based on project type, maturity level, et cetera.
Support Phase
Once a project has been brought to the bright side, it must be deemed converted and moved to support. Progress is noted and tracked just like any other project. Metrics are added to the overall benefit being brought to the organization by your effort, and published. We recommend using an Intranet website to advertise the success and improvements being made to the bottom line and keep that up to date. It's amazing how quickly people will forget how it was before your SCM solution, yet be quick to point out its flaws.
A project in support should receive routine correspondence from the SCM Team regarding enhancements, happenings, etc. They should be routinely scheduled for consulting visits from the SCM Team, otherwise known as audits. They should be invited to routine brown bag sessions to collect feedback on the solution and recommendations for enhancements. These improvements are then prioritized and scheduled in a constant (much smaller than at the beginning) budget focused on continuous Infrastructure improvements. Without this, the SCM Team's capability to support projects will constantly erode over time and eventually you will be back to working tons of hours performing tactical activities.
The Metrics
The metrics you capture are your best friends. In a world of IT strategies that change with the wind, it's very easy to find your budget being questioned - even after a big successful implementation. We took the metric measuring to a new level at a client where we calculated the average dollar savings of creating a formal release the new way versus the old way. Then we kept an automated counter of every release created. When that counter got to a certain "significant" amount, the system sent a text page to a pager that we gave to the CIO. The CIO would be sitting in a meeting and receive a page that said, "Your SCM group just saved you another $102,832." The CIO loved it because he was able to brag in the meeting, and we loved it because it kept the value we were providing in front of the decision-maker on a constant basis.
Summary
The nature of best practices is that they are detailed enough to be tangible, so they need to be specific for a particular situation. The best practices mentioned above won't work for every situation, nor do they attempt to be a complete list of SCM related best practices. Agile SCM has been implemented on many projects the way mentioned above, quite successfully. We hope that you will find some of these ideas useful in your organization or situation.
