Introduction

The Configuration Management Process Area, a process area at maturity level 2, aims at establishing and maintaining the integrity of work products. The process area deals with selecting the work products that compose the baselines, controlling changes and maintaining the integrity over these items and providing accurate status on this data.

Below are the specific goals and practices:

SG 1 Establish Baselines

SP 1.1 Identify Configuration Items

SP 1.2 Establish a Configuration Management System

SP 1.3 Create or Release Baselines

SG 2 Track and Control Changes

SP 2.1 Track Change Requests

SP 2.2 Control Configuration Items

SG 3 Establish Integrity

SP 3.1 Establish Configuration Management Records

SP 3.2 Perform Configuration Audits

Is it too Formal?

CMMI states that the first thing is to create a baseline, which is a “a set of specifications or work products that has been formally reviewed and agreed on, that thereafter serves as the basis for further development or delivery, and that can be changed only through change control procedures.” and then modify this baseline through change requests, which should be approved by all stakeholders. It also states that this process should be audited.

Is this really suggesting that ALL changes should go through a change request system? When the developers are working in the project, they should create a change request ticket to commit their code? When the Product Owner is completing a User Story that was missing some information, s/he should do it via a change request ticket? I believe this formality would take too much time to the activities that add value, hurting the agility of the project. Of course, I believe it is important to track everything under a source control system, to keep the history of all configuration items and to analyze the impact of all changes (specially to requirements). Nonetheless, this should be done in the lighter, more non-obtrusive way. For example, the comments written in the commit to the source control system are (or should be) more than enough information that explains this change. Changes (the history) to the product backlog should be kept automatically, without the Product Owner needing to do anything. Formality is replaced with efficiency and trust. The Configuration System method chosen for an Agile project should be light and efficient. It should keep all the necessary information without the users spending too much time maintaining it. Automation (again in this area) is vital. The easiest way to maintain the integrity of a product is to avoid human intervention in the creation of the product. If the product is created automatically (running a command) there is no room for human mistakes.

Conclusion

When I first read the title of the process area, I thought that this process area was going to be totally compatible. However, after I read it, I began having my doubts. Having to create and maintain a baseline could lead to an overhead that reduces agility. Managing the backlog through change requests is practically impossible. Nonetheless, the need to have all items under a configuration management system is unavoidable. Having all or most of the steps of the configuration management process automated is vital.

- Is the Process and Product Quality Assurance Area compatible with Agile?

- Is the Measurement and Analysis Process Area compatible with Agile?

- Is the Requirements Management Process Area compatible with Agile?
- Is the Project Monitoring and Control Process Area compatible with Agile?
- Is the Project Planning Process Area compatible with Agile?