Agile Configuration Management (2): Towards a Practical Definition of Software Configuration Management

Although definition should be simplifying the concept, in case of Software Configuration Management, the definition is complicating the concept! Take, for example, this definition:

"A discipline applying technical and administrative direction and surveillance to (1) identify and document the functional and physical characteristics of a configuration item, (2) control changes to those characteristics, (3) record and report change processing and implementation status, and (4) verify compliance with specified requirements" - SEI CMMI Glossary

To complement this definition, SEI added references to 7 other definitions: configuration audit, configuration control, configuration identification, configuration status accounting, configuration item, product, and audit. What this effectively does is adding to the complexity of the definition!

On the other hand, there are some other definitions which are simple and to the point, and in the same time give a clear explanation of what Configuration Management means. It may not receive a unanimity among theorists that it is correct. However, in itself, it proposes a clear definition of CM, and I personally believe that they are excellent definitions. These are two definitions:

"Software CM is a discipline for managing the evolution of computer program products, both during the initial stages of development and during all stages of maintenance" - ANSI/IEEE standard 1042-1987 (withdrawn standard)

"In software engineering, software configuration management (SCM) is the task of tracking and controlling changes in the software" - Wikipedia 

These two later definitions captures in simple terms the essence of Software configuration management as per its original intent. Building on this definition, I have added a 'Capability-oriented' definition, which defines SCM in terms of capabilities it adds to the team:

"Software configuration management enables the team to trace releases, work-items, and work products to each other"

A strong SCM environment empowers the team to relate workitems (what has been done) to work products (artifacts of work done) to releases (packaged and delivered software products). This is what I describe as a 'Strong configuration management environment'.

Implications of this definition is huge. It means that the team may instantly know the history of a workitem (say  a bug), when it was released and which artifacts or code changed due to it. The team may also know every thing about a specific release to a customer, which bugs or user stories were included, and what code files or documents delivered as part of this release.

Agile Configuration Management (1): Does it Make Any Sense?

Lean thinking is one of the pillars of Agile software development. This title: "Lean Configuration Management for Agile Teams" is the latest workshop I'm conducting at SECC. Now, I'm giving my self an opportunity to write, why this topic is important.

Configuration Management is one of the great successes of Software Engineering. It was marked by great persons like Gerald Weinberg as one of the achievements of software engineering is the 90's. However, the older the topic, the heavier it became. It is currently perceived that a middle size company would need about 7-10 templates, 4-5 procedures, and many sub-activities to implement a "good" configuration management environment.

In this workshop, I tried to dig into the essence of CM, and what is really useful about it. I have gone through texts dealing with this topic, and reviewed all the previous implementations I have gone through. I tried to bridge a link between theory and practice. I was doing this in order to answer the question of one of my colleagues asking: "All of this stuff have absolutely no value, why are we doing this?". I was also trying to answer another question about how to become a CMMI-L3 company, while still Agile and Lean, specially with regard to CM process area.

Actually, many of the practices which is currently implemented as part of the CM process adds no or little value, or may add value is other contexts, other than software development. Also, I have seen many practices or real value, but implemented in a completely incorrect manner, which made it of no value for this specific company or team.

It is time to implement "lean" configuration management, which achieves the utmost benefit for the team, with the minimal waste or overhead. keep watching my next posts.