Best Practices of Agile SCM

There is a good amount of training, discussion and many articles concerning software configuration management (SCM) standards that tell us to implement configuration identification, status accounting, routine auditing, etc. All of this information is good and very important because it helps us understand the overall objectives. Rarely, though, do you find real tangible approaches for "how" to actually implement solutions that accomplish the objectives. This article will discuss a typical SCM Implementation engagement focusing on some practical best practices in order to achieve the objectives of the many CM standards out there. These best practices won't apply to all situations.

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.

About the author

About the author

About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.