Agile Configuration Management – overview

Written by Blaise Rey-Mermet on . Posted in Agile Configuration Management

 

What is it? Configuration Management (CM) plays a central role to keep a development team synchronized. A classical definition can be found for example in CMMI for development: “The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.“Common configuration Management practices are:

  • Identifying and organizing the configuration items (configuration items: work products that undergoes changes during the product lifecycle and needs to be maintained, e.g. software code, documentation, requirements, and more)
  • Maintaining change requests and systematically controlling the changes to the configuration items
  • Managing the status of configuration items
  • Creating and managing product baselines (baseline: a set of specifications or work products that has been formally reviewed and agreed on, which thereafter serves as the basis for further development)

 

Relationship between versions of work products and baselines

Relationship between versions of work products and baselines

Lean / Agile Configuration Management (CM) Concepts The goals of applying lean and agile principle to CM are

  • to reduce the development time by avoiding waste and delays in the development process,
  • and to get fast feedback about the integration and quality of the product.

An important point to remember is that a lean configuration management process is also continuously adapted and improved. For the CM process to profit from the lean and agile software development principles, we should keep in mind the following aspects:

  • Add support for parallel multiple development branches, because large programs will be organized in a set small agile teams.
  • Avoid centralized Change Control Boards (CCB) that control all changes – Instead control non-strategic decisions on changes in the distributed organization of Scrums and using the cadence of the Sprints. Reserve centralized decisions for changes that impacts the whole program or organization.
  • Let the agile team assumes the CM role instead of a dedicated Configuration Manager. The daily management of configuration items can be handled by the self-organizing team, while the Configuration Manager at the program level defines enterprise-wide aspects such as a CM strategy and CM tools, and support the teams when needed.
  • Use automated tools – Automated continuous integration helps to reduce the integration and testing delays and allow quick feedback about the product quality.
  • Continuously observe and adapt the CM tools and process. For example, avoid complex branching or baselining mechanism if your team does not need them, or observe where long build times are slowing down the team and improve these procedures.
Roles Configuration Manager
This describes the role of the Configuration Manager at the Project or Agile Team Level. The Configuration Manager will typically:

  • Adapt the CM Plan with assistance from the (agile) team, the IT project manager or Scrum Master. Communicate the CM Plan to the team.
  • Ensure team compliance with CM Handbook and CM Plan.
  • Manage the CM System and the Configuration Libraries
  • Identify the configuration item,
  • Control configuration
Read more  [1] Configuration Management Best Practices: Practical Methods That Work in the Real World  – Bob Aiello, Leslie Sachs – Addison Wesley Pub Co Inc (10. August 2010)
[2] Practical Perforce von Laura Wingerd von O’Reilly Media (25. November 2005). This book describes in particular branching and merging in agile environments.

 

Kanban Lean techniques applied to change requests management

Written by Blaise Rey-Mermet on . Posted in Agile Configuration Management

When maintaining and developing a large software system, the many change requests and service requests coming from the support (including bugs and incidents) are usually solved as soon as possible by the production team. The requests that comes from the sales and R&D and contain new customer needs (as opposed to let’s say: bugs) must be examined and passed to the development team.

Why Lean Change Request Management?

For our system, dozens of requests are raised every day, so we have a proper change request management in place. As the change management team gets overloaded, we asked ourselves how to apply Kanban and Lean techniques (in particular limiting and measuring the work in progress) to balance speed and quality.

Kanban board for Change Request Management

Kanban board for Change Request Management

 

How to do it?

We are experimenting with the following set of principles:

  • Maintain a prioritized entry queue: The change requests are first roughly estimated and placed in a request queue until the Change Management Team pulls them. The queue is roughly prioritized by value and urgency. There is no limit to the work in progress (WIP) here, since this is the initial request queue. Emergency requests are directly handled in a dedicated flow.
  • Limit the amount of Requests in progress: The prioritized requests are pulled from the queue by the change request management team according to the team’s capacity or work in progress limit (WIP). Change Requests and User Stories are analyzed. Requests that are sufficiently understood are pulled by the development team. This makes capacity free for new Change Requests.
  • Avoid early commitment on the deadline: We stop to call the changes a “2 days change” or “10 days change” from the start. Estimation is done with the collaboration of development team once a common understanding is reached.
  • We add a different flow for requests with fixed deadlines and for emergency requests.
  • Formulate the business value to make them understandable and valuable. For example:
    Increase / Protect / Promote <something of value>
    Decrease <something reducing the value>
    Don’t forget to estimate the effort, the impact and list the risks.
  • Add examples whenever useful to make them understandable and serve as acceptance test, such as:
    Given <precondition>
    When <action>
    Then <resulting action>

As we will gain more experience, we surely will have to adapt. So far, it sounds logical to apply some lean techniques here, since there is some effort to be done for each single request and we can’t control the amount of requests we get. With some lean and agile techniques, we can process all requests in sufficient detail depending on their priority, find the highest sustainable speed and enjoy our weekends.