Is configuration management (CM) integrated into your development process? Do you have a good way to assess this? Do you have a process to improve the situation? Development without CM will eventually lead to lost code, delays in release schedules, and regression in functionality (amongst other negative impacts). One could say if the "tower of development" does not have CM bands to keep it together, this structure becomes the Tower of Babel, doomed to fail. But enough depressing talk. What can CM professionals do to make the development world a better place? How can CM professionals make CM improvement efforts collaborative so that development team feels involved, engaged, and heard?

Guidance is on the way! The purpose of this article is less a narrative of CM and the development process, and more of a set of steps that can help assess the level of CM in the current development process (and environment), then identify ways to improve the situation.

Step 1: Assessment
Like most improvement efforts, the first step in the process should be assessing the current state of CM within the development process. This provides valuable information about what is occurring within the development process from a CM perspective. While these questions focus on the key areas of CM, feel free to tailor these questions. Consider moving these questions into a spreadsheet and adding an answers column where you can put what you found as well as any thoughts for improvement and a rating column where you provide a score as to areas that are in better shape and the areas that need improvement (this can be helpful in sorting later on).

The Questionnaire
The questionnaire is divided into sections. Again, feel free to tailor.A. CM Plan

1.       Are CM roles and responsibilities documented and communicated?

2.       Are CM procedures placed in a common repository, communicated to developers, and easily viewed/retrieved?

3.       Do CM tasks live in the project plan?

B. CM Process

1.       Is there a change control process defined for managing changes to the following baselines: (a) requirements, (b) project plan, and (c) production?

2.       Is there a development/CM process currently defined and followed?

3.       Is there a checkout/checkin procedure defined and followed?

4.       Is there a branching/merging procedure defined and followed?

5.       Is there a build procedure defined and followed?

6.       Is there a release procedure defined and followed?

C. CM and other Tools

1.       Does the project currently use a CM Tool for managing: (a) code, (b) 3^rd party tools needed for build time, (c) documents, and (d) test cases

2.       Are there any integrations between CM tool and Development tool(s)

D. Development and Build

1.       How does the code get baselined to establish a new development stream/branch?

2.       How often do builds occur?

3.       Who performs the official builds?

4.       Are builds automated?

5.       Is there a build cycle defined?

6.       What happens to the output of a build?

7.       Does parallel development occur?

8.       Is branching currently setup? If so, what is the working model?

E. Test and Production

1.       How is code moved to test?

2.       Who performs the code migration to test?

3.       Does a release schedule/Plan exist?

4.       Are release notes prepared?

5.       Is there a release readiness meeting in place?

6.       Who performs the code migration to production?

7.       Is there a backout and recovery procedure?

8.       Is a release naming convention defined?

9.       Are there release label naming conventions established?

F. Audits and Status Reporting

1.       Do SCM process audits occur?

2.       Do SCM baseline audits occur?

3.       Is there regular SCM status reporting?

4.       Are SCM risks being identified?

Step 2: Results
Once you have completed the questionnaire, the second step is to review the answers to the questions and sort them by the areas that appear to need more help and can benefit the development organization the most. Consider limiting the areas of improvement to the Top 10 (or the number you feel is appropriate) and placed them on a list. If an area of improvement is build automation (based on the question, "Are builds automated?"), simply write down "build automation". Avoid adding judgment to the area (e.g., lack of build automation).

Step 3: Developer's Input
The third step is to take this “Top 10 areas of improvement list” (from step #2) and meet with the development team. Consider calling this session “CM/development roundtable” or something that indicates a collaborative nature. Showing the list on a poster board, a chalkboard, or white board (so that it is large and can be written on), explain that you have completed a CM assessment and that you have identified potential areas of improvement within the development process. Walk through the list with them indicating that they are not in any particular order. Feel free to allow the development team to add more areas of improvement.After you review the list with them, ask them to help you prioritize the list. Explain to them that the prioritization is based on what the development team sees as the biggest problem(s) and where they may see the most benefit if an area of improvement were addressed. Consider low-controversy prioritization techniques such as dot voting. Dot voting is the process of giving each developer 3 dots and asking them to place the dots on the area (or areas) of improvement that most benefits them if addressed. An example can be a developer places 3 dots on 1 area or improvement, or 2 dots on an area and 1 dot on another area, or 1 dot on 3 different areas. Note: feel free to use your own technique for getting to priority.

At the end of the dot placement, count the number of dots for each area of improvement, and then indicate the priority based on the count. From there, focus on the top three areas of improvement and discuss the target solution for each. For example, if Build Automation is a top priority, the target solution should include what the developers think may improve the area and benefit them (e.g., establish automated nightly builds or establish a mechanism to initiate a build upon checkin). It should be noted that the assessment in step #1 can also focus CM professionals on separate areas of improvement that primarily benefit CM (e.g., in the best interests for CM integrity and not necessarily where the development team wants to focus).

Step 4: Plan and Delivery
Now it is time to deliver on the solution. Prior to beginning the work, put together a project plan that encompasses the tasks that focus on the agreed areas of improvement. Consider the effort per task and expected duration (effort multiplied by the percentage of time in a company day focusing on the task given the fact that other daily CM work is occurring). In addition, identify tasks where development team members are needed. These tasks are a dependency to meeting any planned dates. When the plan is prepared, communicate expected delivery dates and the tasks where members of the development team are needed. Come to an agreement on expected delivery dates and a commitment from the development team to help per the tasks they are assigned.

Begin the work of building the solution. Work with development team (as needed) to ensure what you are providing will meet the needs and follows solid CM practices. Once completed, release the solution into the development process. After about 3 months of usage, hold a session with the development team to understand if the solution is working and providing a benefit. Make adjustments as necessary.

Step 5: Rinse, Repeat
After a couple of CM improvement solutions are released into the development process, revisit step #3 (e.g., developer's input) and identify new areas of improvement. If most of the initial areas of improvement are completed, consider revisiting step #1 and perform a new assessment.

Summary
When considering improvements, it is important to make it a collaborative effort with development. Focus on areas where development sees benefits. This will make them see CM as a value-added proposition. Of course, additional CM efforts can focus on ensuring there is solid CM, even if the development team does not see a benefit.

References

1. Chapter 5, "Establish SCM Tasks on a Project", p147-176 of the Software Configuration Management Implementation Roadmap by Mario E. Moreira, 2004, John Wiley & Sons, Ltd Publishing.

2. Application, Project, and Organizational Configuration Management, by Mario Moreira, CM Crossroads, October 2004