Lean Configuration Management
Evolving the CM Discipline Through the Agile Paradigm Shift

Jens Norin

Configuration management, as a discipline for supporting software development, has been around for half a century and has evolved into standard practice within traditional software development processes. One of the key purposes of configuration management is to control changes made to the software product.

Lean software principles focus on delivering customer value in a steady flow and eliminating unnecessary process waste. One way to implement lean is to introduce agile software development methods, such as Scrum or XP. Agile values also have a lot of focus on how to handle changes, but unlike traditional CM, agile methods are being more adaptive to changes.

The increasing popularity of agile development methods is putting new demands on the traditional CM discipline. A working CM environment is essential for the rapid nature of agile development methods, but the CM process and the CM role has to be adapted to the present evolution of software development methods as well as automated tools.

This article discusses lean principles and agile values within a CM scope and also introduces a method to classify the CM discipline in relation to development method and level of tool automation, and finally shares some of the experiences of the author.

Traditional Configuration Management Definition

Nearly every publication on Configuration Management (CM) has its own definition of the subject. I have chosen to quote a few examples to illustrate their common properties and to be able to compare those further on with lean and agile thoughts.

Especially note how they all mention how to deal with changes, where traditional CM handles changes by controlling them. Agile ideas also focus a lot around how to handle changes, but talks more on how to be adaptive to changes. They are targeting the same basic problem, but with slightly different approaches.

IEEE - "Configuration Management is the process of identifying and defining the items in the system, controlling the change of these items throughout their lifecycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items." [8]

CMM - "...Software Configuration Management involves identifying the configuration of the software (selected software works products and their descriptions) at given points in time, systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration throughout the software lifecycle. The work products placed under software configuration management include the software products that are delivered to the customer (for example the software requirements document and the code) and the items that are identified with or required to create these software products (for example the compiler)...".[3]

RUP - "The task of defining and maintaining configurations and versions of artifacts. This includes baselining, version control, status control, and storage control of the artifacts." [21]

Here is a brief list of practices that usually are included in the definition of CM:

• Identify configuration items
• Version control of configuration items
• Release management
• Build management
• Controlling changes
• Tracking status
• Auditing

LEAN principles applied on the CM process

CM in itself is a supporting discipline not delivering any direct customer value. But what if we turn it around a bit and look at the CM process as the deliverable? Being careful not to sub-optimize, we could ask ourselves who is the customer and end user of the CM process? And what is value to them?

I would say the development team is the primary customer and user of the CM process. There are still more stakeholders that benefit the CM discipline, like project managers, product management etc and indirectly the end user/customer. Value, primarily to the development team, but also the other stakeholders, must be a visible and streamlined CM process that allows them to develop features fast in order to fulfill their main task, which is to deliver value to their customer, the end user. This means that CM should support and help the project to deliver customer value more rapidly.

Below is a brief discussion of Poppendiecks' seven principles of lean software development, from a CM perspective. [17]

Eliminate Waste - this is what Lean is all about, identifying and eliminating unnecessary waste. When it comes to CM a typical source for waste is the CCB (Change Control Board) or the change control process. CCB-meetings are often held periodically and a Change Request is often visited over several meetings updating the status in between, making the turnaround time unnecessarily long.

Running the project according to Scrum makes the traditional CCB/change process obsolete. New features, bug fixes and change requests should be prioritized together by the product owner. By shortening the iteration length the cycle time for change requests can be shortened. If we need to shorten it even further we can set aside a certain amount of time or resources in an iteration to focus only on incoming change requests (still prioritized). For example one person in the team is focusing on change requests during the whole iteration and the next iteration someone else is doing it, in a rolling schedule.

Another common source of waste related to CM is code ownership. The strong code ownership seen in many large organizations has a key responsible person for a code module. This key responsible person is the only one allowed to do changes in this module. When implementing a feature many modules can be affected, which could lead to a situation where we are queuing work at the module responsible person, and queues are waste. We need to move from a module driven development process towards a feature driven. [15]

Build Quality In - This is about building quality into the process/product instead of adding it in a test phase at the end. Traditionally it is often the configuration manger's task to keep track of the defect list, or queue. A lean approach would be to prevent defects by finding and fixing them before they end up as defects in a test phase. This can be done by automating the test process having automated tests of different levels for unit- acceptance- and regression testing and eventually also Test Driven Development (TDD).

Building quality into the CM process is also about enabling continuous improvement by implementing agile retrospectives at the end of every iteration, and making sure CM issues are brought up.

Create Knowledge - Feedback is knowledge, and to get knowledge through feedback we have to identify the feedback loops and run them frequently. This means that the CM infrastructure must allow frequent releases, with an efficient build process and frequent integrations between parallel activities. An efficient agile build process utilizes continuous integration and automatic testing enabling immediate feedback to the developer, as well as frequent deliveries, and feedback, to the customer.

Another CM aspect of creating knowledge is to spread the daily operating CM routines throughout the team. The team should have the knowledge to perform these daily operations themselves without having to rely on an explicit CM role. If this knowledge is missing it could be introduced by periodically pairing an inexperienced team member with an experienced CM [14]. The CM role still exists within the organization, but with a more enterprise focus towards CM strategies, tool support and facilitating agile development for projects and teams.

Defer Commitment - In short this means that we should not make decisions until we have to. More strictly it says that for irreversible decisions we should first decide when the last responsible moment for taking a decision takes place. When that last responsible moment occurs we have the most information to make our decision.

For reversible decisions we can just go ahead and make a decision and simply change it if it turns out to be a bad decision, instead of just sitting around and not making any decision at all.

Putting a CM aspect on this would rather be to create a flexible CM environment allowing reversible decisions. Creating a branching structure that allows parallel development is one example.

Deliver Fast - For some reason it has been widespread in the software industry that if we do things slow and careful we get higher quality, especially when it comes to requirements gathering. However if we instead deliver fast and frequent we get rid of waste, we get valuable feedback and we are able to find hidden errors much earlier, all leading to higher quality.

We can make the CM process support fast deliveries and higher quality by introducing continuous integration and automated testing into the build process together with frequent incremental deliveries.

Respect People - If you give respect you will get respect and only by showing respect and listening to people you will benefit their full creativity, ideas, loyalty and engagement. In today's tough competition you cannot afford not to. Agile leaders respect the workers and support and facilitate their work. In the same way an agile CM process is supporting and facilitating the work of the team.

Optimize the Whole - It is not enough to only optimize the CM process by introducing Lean CM. That would be to sub-optimize. A lean organization optimizes the whole value stream, from the receiving of a customer request until the deployment and customer satisfaction. This article tells how to adapt a more traditional CM process to a lean and agile environment.

Agile methodology and CM

Agile CM is maybe a more widespread expression than Lean CM. However I like to think that agile methodologies and engineering practices can be seen as ways to implement LEAN software principles, and what I actually aim for is to make the CM discipline leaner focusing on flow and minimizing waste.

Most agile methods do not mention any explicit CM routines or practices, simply because it is out of the context of the agile methods. For example XP and Scrum are more of project frameworks that do not explicitly include CM in their scope. XP does however rely on working CM routines for some of its engineering practices. [12][19]

Agile CM is not limited to CM for agile projects, but is when you actually apply agile values on the CM discipline [2]. The agile values are captured in the Agile Manifesto [11]. If we analyze the agile manifesto within a CM context we get the following discussion:

Individuals and interactions over processes and tools - The CM discipline is traditionally heavy on tools. Even though it should be obvious that tools should support the process, it is far too common that the process is adapted to the tools. We should not forget that software is developed by humans and the process should support appropriate human behavior and not obstruct it. A more pragmatic approach is preferred over a dogmatic.

Working software over comprehensive documentation - Since CM is a supporting discipline we can make agile CM support agile development by shifting focus towards optimizing the "value chain" instead of creating waste such as unnecessary CM documentation. The production of necessary CM documentation should be automated where possible.

Customer collaboration over contract negotiation - I have seen many CCB routines that have ended up in endless contract negotiations to decide whether an issue is a change request (customer cost) or a trouble report (project cost). In these cases the change process is often constructed in a way that aims to prevent the customer from filing changes. In agile methods, such as Scrum, the product backlog replaces the need for a CCB. Instead the backlog is a continuously prioritized list containing all that is planned to be done, including change requests and trouble reports. The resources should constrain what is finally implemented, not the original contract.

Responding to change over following a plan - Traditional CM seeks to control change, while agile values adapt and respond to change. The common property between CM and agile methods is that they should facilitate change and not prevent it.

CM performance

The performance of CM in a project or an organization can be measured with two parameters: the degree of CM process formality and the degree of CM (tool) automation. Plotting the two parameters in a diagram gives the following picture. Here we classify each parameter into relatively high and relatively low measures according to our perception of current practices.

Figure 1: Configuration Management performance quadrant.

Ad hoc CM = low degree of defined process and low degree of automation

Defined CM = high degree of defined process and low degree of automation

Automated CM = high degree of defined process and high degree of automation

Lean CM = low degree of defined process and high degree of automation

Case Studies

The following ideas are based on real world experiences from several different projects in different organizations. I choose to describe two of these organizations, which have had the largest impact, in more detail.

Company A - This is a multinational retail company where an effective global supply chain is a key success factor. IT is a supporting discipline of great importance for fulfilling their supply chain. Company A has adopted a customized RUP adaptation as the central development method for the last few years. Most projects within the organization have interpreted this in a way that most closely resembles a waterfall approach. This makes it a very heavy and defined process with a heavy CM overhead and no tool automation.

Most projects are running the RUP adaptation and have the prescribed dedicated CM role within the project. The same CM resource is often shared between several projects. The company also uses a gate model to manage their projects and productivity is in general perceived as quite low. However, also mentioned in coming sections, there are isolated agile initiatives outside of the general enterprise process.

Company B - This is a multinational company producing consumer electronic products in a highly competitive business. IT is a central part of their products, which are very hi-tech, containing advanced customhardware and software, with short life-cycles. They have a development method that closely resembles waterfall method and a gate model for managing products. They are forced to be productive because of the extremely tough competition in their market. Given the circumstances they succeed quite well, but this is often perceived to be on the staff's expense. However there is plenty of room for improvements, as for example the lead times for change requests are very long.

The CM role in company B is split up into two roles. One which mostly resembles a change control manager on a product level, who is occupied with change requests, CCB-issues and release management. The other part of the CM role is heavily biased towards integration and building.

Ad hoc CM

Ad hoc CM is here defined as when the degree of process is low and the degree of tool automation is low. The typical setup would be having a simple versioning tool, but no dedicated CM role and no formal CM routines. This is sufficient for the smallest of projects and predictable environments.

The degree of process, however, could also be more highly developed, but still be slim and low in waste. This is better, but the lack of automation creates unnecessary manual overhead.

Ad hoc CM in its most extreme form implies no process and no tools, which could also be referred to as "chaos CM" or "no CM". This might be enough for projects with very small teams, maybe only one team member. But in this case there is no traceability, no version handling tool, no support for change management and should generally be avoided because of the potential risk exposure and unexpected high costs these can lead to.

The CM process has for many organizations developed from an initial low degree of process together with a low degree of automation. From there the CM process evolves to a defined CM process concurrently with the evolution of the rest of the software development method, maybe triggered by an initiative to introduce RUP, waterfall, CMM or any other traditional method.

The relation with company A began several years ago, and started with projects categorized as having an Ad Hoc CM process. Between five to ten years ago this seemed to be the standard setup at company A for small and medium sized projects. At the time, company A had no central development process and no central function promoting development methods. It was instead up to the individual projects to decide, often ending up with no particularly formal process. This led to a diverse environment and maintenance problems. However the productivity was interestingly enough very high. There are still isolated projects that for some reason have little or no CM process, but in the ones witnessed this have only led to bad traceability and general confusion.

Defined CM

The defined CM process is defined as when there is a relatively high degree of defined process, but a low degree of tool automation. This could typically be the case when an organization has introduced a quality framework such as CMM or a development method such as RUP. In these methods we have a dedicated CM role with a heavier process including CCB routines.

Company A has the last 5 years been centralizing many of their software systems and functions. As a step in this process they also standardized the development method throughout the organization by introducing RUP as the common development method. The CM role is pretty much taken from off the shelf RUP. This has shifted focus from producing code towards distinct handovers, rigid planning and very formal change management. Unfortunately this has led to a serious decrease in productivity within the organization.

Company B, with its very large development organization, is also considered to be put into this category. The code is very modularized and they have a culture with strong code ownership. This, together with the large number of differently configured products in varying states of development makes CM a challenging task to handle. The development organization is also large enough for them to require many CMs/integrators in the project in some form of hierarchy that mirrors the architecture of the product. The problem they experience with this setup is that they have very long lead times for change requests.

Automated Configuration Management

We define Automated CM as the rather uncommon situation of having a relatively high degree of CM process while having a relatively high level of tool automation. Our experience says that organizations that benefit from automated tool support have also learned to benefit from agile methods.

At company A, however, there are isolated projects that are moving towards more CM tool automation. This is due to agile supporters among the developers that are introducing continuous integration into a RUP project. This might shift attitudes within the project towards an interest in agile development, but does not do enough for productivity, since the development process is effectively blocking a large part of the possible benefits gained from the automation.

Lean Configuration Management

Lean CM shares the same values as agile development methods and lean principles. Lean CM supports the empirical nature of software development and is more adaptive to changes instead of being predictive. To support agile development processes, tools use must be automated.

These prerequisites to Lean CM disqualifies traditional development methods like the waterfall or RUP, as these describe a very much more controlled and heavy CM process based on predictive planning with high amounts of waste.

Company A have lately started to introduce Scrum into a few projects with very successful results. They have in general experienced an increase in productivity. They have managed to do this with the above recipe of not having a dedicated CM, and in coexistence with a legacy RUP environment.

In company A there is also at least one project that has been completely excepted from the RUP policy for very long. This project is doing XP and is able to deploy into production every 3 weeks. This project is also perceived as being very productive.

Creating Value with Lean CM

By applying lean software principles to the CM discipline we can enable projects or organizations to create more value and reduce waste. If we look at this from an economical perspective we are actually improving productivity. There are three basic ways to do this [18]:

• Reduce software development effort.
• Streamline development processes.
• Increase customer value.

Reducing software development effort

This is basically about reducing development costs by eliminating investments in features that are not valuable to the customer. Lean principles support this by reducing waste, especially by avoiding overproduction. Agile methods encourage an empirical approach to development as opposed to the waterfall approach where detailed and complete requirements are done upfront. This is achieved by identifying and shortening feedback loops and also to manage requirements in a prioritized product backlog.

Streamline development processes

More mature industries (outside software industry) have been increasing productivity for decades by streamlining processes and making more efficient use of resources, a good example is the car industry with Toyota as a classical example [9]. A mature software development organization is one that can rapidly and repeatedly transform customer requirements into deployed high quality code. This is where lean CM really comes into play by supporting the agile methods and lean principles in order to reduce waste, as well as using tools to further support the process and automate tasks.

Increase customer value

The key issue here is to understand what represents value to the customer, and often the customers do not know this themselves, especially in the beginning of the project. We must try to understand how the customer will be using the product to be able to deliver value. Since CM is a supporting discipline it doesn't have a great impact on customer value. However CM can help sweep the path for the team by enabling short feedback loops.

Conclusion

We have seen that traditional CM handles changes by controlling them while agile methods handle changes by responding and adapting to them. Can these two disciplines really co-exist, or does one make the other obsolete? Well actually CM is more important than ever for enabling an agile environment. The short feedback loops and some of the agile engineering practices rely heavily on working CM processes. But a different mindset could be used, where CM is seen as supporting and enhancing the agile methods.

My top three measures to be taken to transfer the organization towards lean CM, a bit provocative to some, would be:

• Cancel the traditional CCB - Instead introduce the backlogs of Scrum where new features and changes can be prioritized together. Badly setup CCB routines just add waste and long lead times to the change process, because important change decisions are held up just waiting for the CCB to convene, This introduces wasted lead time if the decision affects the critical path of the project.
• Remove the dedicated project CM - Instead let the daily operative CM routines be handled by the self-organizing team, while the CM experts in the organization focus more on enterprise issues such as CM strategy, tool support and supporting the teams when needed.
• Automate tools - Automate the build environment by introducing continuous integration, automatic testing etc. using tools such as CruiseControl. [5]

References

1. Alistair Cockburn, Agile Software Development, Addison Wesley, 2002.
2. Brad Appleton, Robert Cowham, Steve Berczuk, Defining Agile SCM: Past, Present & Future, CMCrossroads.com, 2007
3. Carnegie Mellon Univ. Software Engineering Inst.The Capability Maturity Model: Guidelines for Improving the Software Process, Addison Wesley, 1995.
4. Craig Larman, Agile & Iterative Development, A Manager's Guide, Addison Wesley, 2004.
5. CruiseControl, https://cruisecontrol.sourceforge.net/
6. David E. Bellagio and Tom J. Milligan, Software Configuration Management Strategies and IBM Rational ClearCase, IBM Press, 2005.
7. Goldratt, E., Critical Chain, North River Press, 1997.
8. IEEE-Standard-729-1983, Standard Glossary for Software Engineering, ANSI/IEEE.
9. Jeffrey Liker, The Toyota Way, McGraw-Hill, 2003.
10. Jens Norin, Daniel Karlstrom, Lean Configuration Management - Supporting Increased Value Delivery from Agile Software Teams, 6^th Conference on Software Engineering Research & Practice in Sweden (SERPS'06), 2006
11. Kent Beck et al, Manifesto for Agile Software Development, https://agilemanifesto.org/, 2001.
12. Kent Beck, eXtreme Programming - Embracing Change, Addison Wesley, 1999.
13. Kent Beck, Test Driven Development: By Example, Addison Wesley, 2002.
14. Laurie Williams, Robert R. Kessler, Ward Cunningham and Ron Jeffries, Strengthening the Case for Pair-Programming, IEEE Software (Vol. 17, No. 4), 2000.
15. Martin Fowler, Code Ownership, https://www.martinfowler.com/bliki/CodeOwnership.html, 2006.
16. Martin Fowler, The New Methodology, https://www.martinfowler.com/articles/newMethodology.html, 2005
17. Mary and Tom Poppendieck, Implementing Lean Software Development: From Concept to Cash, Addison Wesley, 2006
18. Mary Poppendieck, Agile Contracts: How to Develop Contracts that Support Agile Software Development, Agile 2005 Conference, 2005.
19. Mike Beedle and Ken Schwaber, Agile Software Development with SCRUM, Prentice Hall, 2001.
20. Peter H. Feiler, "Configuration Management Models in Commercial Environments", CMU/SEI-91-TR-7, Carnegie-Mellon University/Software Engineering Institute, March 1991.
21. Philippe Kruchten, The Rational Unified Process: An Introduction, Addison Wesley, 2003.
22. Poppendieck LLC, "Software Development Productivity", https://www.leanessays.com/
23. Stapleton, J. Dynamic Systems Development Method: The Method in Practice, Addison Wesley, 1997.
24. The SEI Software Capability Maturity Model

More Agile Software Development and Project Management Knowledge

Scrum Expert

Project Management Planet

Click here to view the complete list of archived articles

This article was originally published in the Fall 2007 issue of Methods & Tools