Best Practices of Agile SCM

• 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 it's 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, "Just don't impact my 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.