Adapting Configuration Management for Agile Teams E-Book

Mario E. Moreira

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 488

Veröffentlichungsjahr: 2010

Beschreibung

Adapting Configuration Management for Agile Teams provides very tangible approaches on how Configuration Management with its practices and infrastructure can be adapted and managed in order to directly benefit agile teams. Written by Mario E. Moreira, author of Software Configuration Management Implementation Roadmap, columnist for CM Crossroads online community and writer for the Agile Journal, this unique book provides concrete guidance on tailoring CM for Agile projects without sacrificing the principles of Configuration Management.

Leseprobe

Table of Contents

Title Page

Copyright Page

Dedication

Acknowledgements

Preface

Acknowledgements

About the Author

Contributor Biography

Bob Aiello

Damon Poole

CHAPTER 1 - Introduction: Racing with Confidence

1.1 Focus of this Book

1.3 Navigation through this Book

1.4 Value of this Book

CHAPTER 2 - CM Primer

2.1 Brief History of CM

2.2 CM Values

2.3 CM Practices

2.4 Benefits of CM

2.5 CM Roles

2.6 CM Mindset

2.7 Relationship of CM to Culture, Methods, & Governance

2.8 CM Resource Guide

CHAPTER 3 - Agile Primer

3.1 Brief History of Agile

3.2 Agile Values (a.k.a., Manifesto)

3.3 Agile Methods

3.4 Benefits of Agile

3.5 Agile Personality Types

3.6 Agile Roles

3.7 Agile Mindset

3.8 Moving to an Agile Culture

3.9 Agile Resource Guide

CHAPTER 4 - How CM and Agile Values Work Together

4.1 Aligning Agile and CM Mindsets

4.2 Supporting Agile and CM Values without Sacrifice

4.3 Value of Retrospective to CM

4.4 Agile Perspective of CM Practices

CHAPTER 5 - Approaching Infrastructure for Agile

5.1 Guiding Principles for Approaching Infrastructure

5.2 Considerations for Approaching Infrastructure

5.3 Infrastructure Envisioning

5.4 Infrastructure Refactoring

5.5 Owning on Premises or Renting in the Clouds

CHAPTER 6 - Approaching the CM Implementation for Agile

6.1 CM Envisioning

6.2 CM Refactoring

6.3 Automate, Automate, Automate for Agile

CHAPTER 7 - Adapting CM Practices for Agile

7.1 Adapting to Continuous Integration and Build

7.2 Adapting CM Planning

7.3 Adapting to Support Refactoring

7.4 Adapting to Support Pair Programming

7.5 Adapting to Support Test Driven Development (TDD)

7.6 Adapting to Support Agile Distributed Teams

7.7 Adapting Change Control, Traceability, and Baselines

7.8 Adapting CM Audit

7.9 Adapting Problem Management

7.10 Adapting CM Report and Review

CHAPTER 8 - CM Tool as a Strategic Agile Partner

8.1 CM Tool Support for Software Development

8.2 The Agile Practices that Impact a CM Tool

8.3 Evaluating Your Situation

8.4 CM Tool Features that Facilitate Agile Development

8.5 Integration with Your Agile Ecosystem

8.6 Conclusion

CHAPTER 9 - Evaluating Tools Suited for Agile

9.1 Looking for Tools out there and in here

9.2 Levels of Technology Evaluation

9.3 Perform a Technology Evaluation

CHAPTER 10 - Using CM Standards and Frameworks to Support Agile

10.1 Importance of CM

10.2 Compliance and IT Governance Requirements

10.3 Communicating Your Approach to Senior Management

10.4 Which Standards Should Be Considered?

10.5 Configuration Management Functions that are most Essential

10.6 How do Frameworks such as Cobit, ITIL, CMMI, and RUP support Agile?

10.7 Achieving Synergy through Harmonization and Tailoring

10.8 Conclusion

Bibliography

Index

This edition first published 2010

© 2010 Mario E. Moreira

Registered office John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom

For details of our global editorial offices, for customer services and for information about how to apply for permission to reuse the copyright material in this book please see our website at www.wiley.com. The right of the author to be identified as the author of this work has been asserted in accordance with the Copyright, Designs and Patents Act 1988.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by the UK Copyright, Designs and Patents Act 1988, without the prior permission of the publisher.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.

Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective owners. The publisher is not associated with any product or vendor mentioned in this book. This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold on the understanding that the publisher is not engaged in rendering professional services. If professional advice or other expert assistance is required, the services of a competent professional should be sought.

A catalogue record for this book is available from the British Library.

eISBN : 978-0-470-97083-6

Typeset in 11/13 Palatino by Laserwords Private Ltd, Chennai, India

Dedication

I dedicate this book to the following people who keep me motivated inlife and keep me young:Seeme, Aliya, and Iman

Publisher’s Acknowledgements

Some of the people who helped bring this book to market include the following:

Editorial and Production

VP Consumer and Technology Publishing Director: Michelle Leete Associate Director - Book Content Management: Martin Tribe Associate Publisher: Chris Webb Executive Commissioning Editor: Birgit Gruber Assistant Editor: Colleen Goldring Content Editor: Claire Spinks Copy Editor: David Price

Marketing

Senior Marketing Manager: Louise Breinholt Marketing Executive: Kate Batchelor

Composition Services

Compositor: Laserwords Private Limited Proof Reader: David Stone Indexer: Robert Swanson

Preface

For some Configuration Management (CM) professionals, notions of agility have been around and applied into CM practices for years. When I hear people talk about continuous integration and builds in an Agile context, it only reminds me that I and many other CM professionals established build processes that support frequent builds or on-demand builds much like continuous integration, but that was in the early 1990s. After all, CM is an enabler for change and can be adapted to the context and method it works in. CM professionals may have been working in more traditional methods, but it never stopped us from streamlining and automating build processes or introducing ways to make change easier. The primary reason is that, like me, many CM professionals understand that the more you automate and streamline, the more work can be done and the more time we have to focus on new value-added work. From the perspective of the CM professional, bringing value to our customer is important. In all cases, CM professionals should engage with their customer, which in most cases is the engineering team, to understand their needs, understand the technologies they use and the methods and practices they follow. I have found this an effective way to gain CM adoption and build a strong relationship with the engineering team.

As I gained experience in Agile methods back in the late 1990s, I found that many Agile teams struggled with their infrastructure. Since I happened to manage both the CM team that focused on tools and practices and the Unix System Administration teams that provided server and workstation support at a time when Agile was being introduced, I saw the impact when the focus of the Agile team was building functionality while their CM and infrastructure needs were being ignored. Not surprisingly, soon after they cobbled together a package and released it, they could not effectively put together a baseline of code for the next release and quickly realized that pieces were missing because of the ad hoc manner in which change, code, build, package, and release processes were handled. A short period of chaos and regression to the product ensued. In addition, there was no branching and merging process to support the next release and apply bug fixes to the existing release, and there was a very limited problem- management process to effectively manage the defects coming in. This initiated a CM project to establish right-sized CM functionality for the Agile team.

During a recent fact-finding mission on Agile implementations, I networked with companies who had implemented Agile (primarily smaller ones) and asked them what some of their Agile challenges were. Interestingly enough, I heard that getting their infrastructure set up was a challenge when trying to get Agile going, since Agile had instant demands on the infrastructure. I then had a flashback of the late 90s and realized that similar problems still exist with getting infrastructure and technology established.

The advent of Agile into the mainstream has raised awareness of the challenges in getting CM functionality established that suits the working processes of Agile methods. While not necessarily new to some CM professionals, the primary challenge is how to adapt CM practices in a tangible way that supports Agile values while not discarding the CM values that ensure integrity of the product under development. Using my experience of implementing CM on over 100 product lines that applied various methods (including Agile) and my experience of implementing and working on teams applying Agile, I embarked on writing this book.

As I was writing the book, I realized the combination of CM and Agile can form a very powerful partnership. Agile is a facilitator of change ensuring the customer gets more closely to what they want, while CM is an enabler of change ensuring the integrity and control of change. In order to run rapidly in a consistent and lean manner, some level of process and tool structure must be in place. This helps us maintain a velocity to get us to the finish line ahead of the competition while not dropping pieces along the way. In other words, an Agile team must be able to maintain a rapid pace without losing control. This is particularly true as we deliver one release after another.

This unique and innovative book provides very tangible options for implementing CM practices, from build management for continuous integration and build, to iterative CM planning, to support for refactoring, test-driven development, and pair programming (and so much more). It is intended to help the reader bridge the gap in a tangible way to ensure we have rigorous, yet lean, CM practices and infrastructure to support the Agile capability of moving fast and constantly delivering business value.

Acknowledgements

I want to thank Birgit Gruber, Colleen Goldring, Claire Spinks, Ellie Scott and Chris Webb from John Wiley & Sons, Ltd for their patience and support in helping me complete this book.

A special thank-you to Damon Poole and Bob Aiello for each contributing a chapter within this book and reviewing the rest of the book.

Thank you to Steve Berczuk for reviewing my book and providing great feedback.

Thank you to Brad Appleton, Robert Cowham, Curtis Yanko, Bill Langston, Joe Townsend, Alex Elentukh, and Chris Brookins for contributing to good discussions that helped me hone my thoughts as I worked on this book.

Thank you to the many folks who contributed to my surveys and provided feedback to my Configuration Management and Agile articles.

About the Author

Mario Moreira

Mario is both an Agile and a Configuration Management (CM) professional who has worked in the CM field since 1986 and in the Agile field since 1998. He is an IT professional who has been working in the communications, networking, product, open source, and financial industries for over 23 years. Mario brings additional experience in Architecture, Project Management, Software Quality Assurance, Requirement Engineering, and IT Governance, as well as Enterprise-Level Program Management, Coaching, and Team-Building expertise.

Mario has spoken in numerous conferences, including the International SCM Conference, the Swedish Configuration Management Summit, SD West, and SD East. In addition he has been the primary speaker for numerous seminars and webinars discussing Configuration Management, Agile, Build Management, Release Management, and Requirements Engineering, and has spoken on behalf of various product vendors.

Mario is a published author, who in addition to this book, Adapting Configuration Management for Agile Teams, also authored the CM book entitled, Software Configuration Management Implementation Roadmap in 2004, a Wiley publication. The latter book is unique in that it provides tailorable step-by-step guidance for implementing CM.

Mario is also a columnist for the CM Journal (www.cmcrossroads.com) and a writer for the Agile Journal (www.agilejournal.com). He has experience with several Agile methods, including Scrum and XP, and he is a certified ScrumMaster (CSM). He also has experience with numerous CM technologies and processes and has implemented CM on over 100 products, which include establishing global CM infrastructures. Mario holds an MA in Mass Communication from Bowling Green University (Ohio) with an emphasis on advanced communication technologies. His blog can be viewed at http://cmforagile.blogspot.com.

Contributor Biography

Bob Aiello

Bob is the editor-in-chief for CM Crossroads and a software engineer specializing in Software Process Improvement, including Software Configuration and Release Management. He has over 25 years experience as a technical manager in several top NYC Financial Services firms where he was responsible for company-wide Configuration Management (CM), often providing hands-on technical support for enterprise Source Code Management tools, build engineering, continuous integration and automated application deployment. He has developed a number of effective process improvement methodologies by combining the disciplines of Industrial Psychology with modern Software Engineering, including both Agile and more traditional processes. Bob demonstrates a passion for spreading CM best practices and good corporate citizenship through the successful implementation of IT Controls. He has practical experience in large scale SOX compliance by establishing Configuration and Change Management controls using the Cobit framework. Bob has also served as a Subject Matter Expert (SME) on Standards (e.g. IEEE, ISO) and frameworks (e.g. CMMI, ITIL) to government agencies, defense contractors and financial services firms.

Bob is the vice chair of the IEEE 828 CM planning Standards working group and serves on the IEEE Software and Systems Engineering Standards Committee (S2ESC) Management Board. He is a long-standing member of the Steering Committee of the SEI-sponsored NYC Software Process Improvement Network (CitySPIN), where he has served as the chair of the CM SIG. Bob holds a Masters in Industrial Psychology from NYU and a B.S. in Computer Science and Mathematics from Hofstra University. You may contact him at [email protected] or link with him at http://www.linkedin.com/in/bobaiello.

Damon Poole

Damon Poole is founder and CTO of AccuRev, a leading provider of Agile Development tools specializing in Configuration Management (CM). Damon has eighteen years of software development methodology, CM, and process improvement experience spanning the gamut from small co-located teams all the way up to 10,000-person shops doing global development. Damon is president of the Agile Bazaar (http://agilebazaar.org) in Boston and is a certified ScrumMaster. He writes frequently on the topic of Agile development and as one of AccuRev’s product owners works closely with AccuRev’s customers pioneering state-of-the-art Agile techniques, such as Multi-Stage Continuous Integration, that scale smoothly to large distributed teams. Damon has spoken at numerous software development and Agile-related conferences, including SD Best Practices, Software Test & Performance, Q-Con, Deep Lean, Agile 2008, and Agile Development Practices.

Damon is also the founder of CM Today, the first daily CM news site, which was acquired by CM Crossroads in 2003. Damon is the author of four pending CM patents, and is also the author of The TimeSafe Property - A Formal Statement of Immutability in CM. He earned his B.S. in Computer Science at the University of Vermont in 1987. His Agile Development Thoughts blog is at http://damonpoole.blogspot.com.

CHAPTER1

Introduction: Racing with Confidence

Effective Agile allows a team to move fast with confidence. In order to move with such speed and confidence, you need to have a very smooth, well-built, and maintained roadway. This ensures speed and the ability to stay on track. If you look at the road surface of automobile race tracks for the very fast racing cars (e.g. Formula 1, Indy car, stock car, and dragsters) you will find that the road surfaces are built with precision incorporating high-quality race construction and surface materials. All of this is to ensure the race-cars are allowed their maximum speed and maneuverability with a balance of minimal friction and maximum control.

Figure 1-1 CM raceway for Agile teams.

Configuration Management (CM) provides many of the same elements as a high-speed raceway. While a gravel road may allow for speeds of up to 40 or 50 mph without you getting thrown off course or crashing, and a standard paved roadway may allow for speeds of 120 mph, a smoothly paved and well-constructed raceway for high-speed race cars allows for speeds of 250 to 300 mph and beyond. Similarly, the values of CM and Agile can be a very powerful combination.

Agile methods, along with well-trained and seasoned Agile professionals, are the engine and the driver, while CM is the road surface. CM brings order and control to the world of Agile - an order that can be counted on and repeated with integrity, so that the Agile professionals can focus on the high-value tasks of building and delivering functionality to the customer for the checkered flag and the win!

Figure 1-2 Checkered flag for the Agile win!

On the one hand, CM professionals have seen Agile “pretenders” and “cowboys” claim that Agile is without process, tools, and discipline. This misrepresents Agile and damages its reputation. On the other hand, some Agile professionals have felt “heavy” CM adds too much process that burdens their velocity. The key is finding the balance that allows you to stay on the track while maintaining a high velocity.

Agile relies more on the strength of the team and their interactions than on processes and tools. However, Agile does not discard processes and tools, it just aims to use them in a lean way to strengthen the ability to interact more effectively and deliver value. This implies that the effort to define the need for processes and tools should be driven by the people and their interactions.

Pit Stop

Agile encourages change while CM is an enabler for change. This powerful combination ensures change can be frequent while under control.

CM should adapt to the needs of the lifecycle method (in this case Agile), which means it should be adjusted and honed for the changing needs of the method and the project without sacrificing the values of CM. Anyone who has ever established a CM infrastructure (environment, tools, and processes) knows that CM can be implemented in a number of different ways. I have implemented CM in over 100 different product lines and have adapted to the product, project, standards, framework, and method on numerous occasions. So why should implementing CM on a project using Agile be any different? Both Agile professionals and CM professionals should learn enough about each other’s values and principles in order to understand each other’s perspective to comprehend what it means to adapt CM to align with the values of Agile. Just like a racetrack, the goal is to establish CM so that it reduces friction between the Agile race-car and the road surface. But just like a well-constructed racetrack, the goal of CM is to ensure the car stays on track while allowing it to maintain a high velocity.

While both speed (for Agile) and control (for CM) are important, it is ultimately driven by the ability to quickly get value to the customer while maintaining the integrity of the deliverable, so that the customer can have confidence in what they are receiving.

Pit Stop

The goal with adapting CM for Agile teams is not to discard any of the values of each. Instead it is to determine how best to integrate the values through a leaner CM implementation that still provides those projects that follow Agile with the sticky surface needed to keep it on track and with the integrity the customer expects.

1.1 Focus of this Book

This book focuses on how Configuration Management (CM) with its practices and infrastructure can be adapted and managed in order to directly benefit Agile teams. It is intended to be a pragmatic guide but neither exhaustive nor prescriptive. It can be applied when a team is embarking on new product development following Agile methods or when being applied to legacy products that are introducing Agile methods. While this book focuses on those with an Agile mindset, please note that many of these adaptations can be done for traditional methods as well, and gain similar benefits.

1.2 Who should Use this Book

This book is intended for the following:

• The primary group who will benefit from this book includes:

• Agile professionals such as: Agile coaches, Agile project managers, Agile team members, and product managers. An Agile team member can be anyone with a background in programming, analysis, testing, architecture, design, quality assurance, (anyone who plays a full-time and active role on the project using Agile methods). This book will help Agile professionals broaden their perspective of CM and infrastructure and become familiar with CM values, and gain knowledge of CM, while considering leaner ways of implementing CM in the work context.

• CM professionals such as: CM managers, CM tool engineers, CM coordinators, and build & release engineers (i.e., anyone who plays a CM-related role). This book will help CM professionals broaden their perspective of Agile methods, become familiar with Agile values, and gain primer level knowledge of Agile methods, while learning about leaner approaches to implementing CM in an Agile context.

• The secondary group who will benefit from using this book includes:

• Product managers and product owners who are considering Agile methods for their product line. This book will provide them with a primer level understanding of Agile and Configuration Management and the implications of Agile to CM and infrastructure, focusing on leaner ways to approach them.

• VP of Engineering and Senior Management who are considering Agile methods for their organizations. This book will provide them with a primer level understanding of Agile and Configuration Management and the implications of Agile to CM and infrastructure, focusing on leaner ways to approach them.

• Quality Assurance professionals who want to learn more about both Agile and CM and recognize how each help improve quality across the lifecycle of both the product and projects therein.

• Operations and Infrastructure professionals who want to understand both Agile and CM better and recognize the implication of Agile to their field with more incremental and optional ways of establishing infrastructure on a project.

• Development, test, analyst, project management, and architect professionals who want to learn more about both Agile and CM and understand the implication of Agile and CM to their field.

• Project stakeholders and customers who want a primer level understanding of Agile and CM and want to recognize the benefits and implications of Agile and CM to their roles.

1.3 Navigation through this Book

You can read this book in a number of ways. Of course you are welcome to read the full book from front to back. However, you can also navigate the book according to the level of knowledge you have in Agile and/or CM, the profession you are in, and/or what challenges you are trying to solve. Below is a view of the sections within this book with navigation from top to bottom or to selected sections per your current need.

Figure 1-3 Navigation thru the chapters of this book.

First identify the column that is aligned with your profession and read the navigational details.

Agile ProfessionalCM ProfessionalOther ProfessionalIf you are an Agile professional, first read the “CM Primer” section of the book. This will ensure you have a solid understanding of CM values and practices which will help you understand what CM areas and adaptations may help you in your work.If you are a CM professional (you have experience as a CM engineer, build engineer, release engineer, CM coordinator, etc.), consider first reading the “Agile Primer” section of the book. This will ensure you have a solid understanding of Agile values, methods, and practices leading to an understanding of the Agile mindset.Other professionals, (product manager/owner, VP of engineering, senior management, QA, project management, development, test, analyst, and architect, operations and infrastructure, and project stakeholders, etc.) should read the “Agile Primer” and the “CM Primer”. This will give you a background in both fields so that you can understand each perspective.

Then review the following sections per your interest or current challenge.

• The “How CM and Agile Values Work together” chapter provides a merging of the minds and an understanding of how each are committed to change. This chapter includes recent survey results that highlight the importance of CM practices by Agile professionals while also providing an Agile perspective on the various CM practices.

• The “Approaching Infrastructure for Agile” chapter provides an understanding of the underlying structure that all products need and possible ways to approach this for Agile. Within this section, consider if you are introducing a brand new product line or are modifying an existing product line. If it is the former, visit the “Infrastructure Envisioning” section, or it is the latter, visit the “Infrastructure Refactoring” section.

• The “Approaching the CM Implementation for Agile” chapter provides guidance on implementing CM for Agile. Consider if you are implementing CM for a brand new product line that is following Agile methods or if you may need to adapt CM for an existing product line moving to Agile methods. If it is the former, visit the “CM Envisioning” section. If it is the latter (adapting CM for an existing product line), visit the “CM Refactoring” section. However, if you have CM standards within the organization that are expected to be applied to a new product line and you have not yet experienced implementing CM for a product line following Agile, then you may want to read both the “CM Envisioning” and “CM Refactoring” sections.

• Most importantly, read “Adapting CM Practices for Agile”. This will provide you with specific insight, guidance, and considerations for adapting CM for the various Agile practices and adapting CM practices in a leaner way.

• The “CM Tool as Strategic Agile Partner” chapter provides an understanding of the more modern CM features that can help with implementing Agile in an effective manner. Continued reading of “Evaluating Tools Suited for Agile” may help if you are considering an effective approach to evaluating tools that better align with your Agile needs.

• The “Using CM Standards and Frameworks to Support Agile” chapter helps if you are implementing Agile and must also implement an industry standard and/or framework. This will provide guidance in understanding the value of these standards and frameworks and how best to apply them in an Agile context.

Sprinkled throughout the book are “Pit Stops”. Pit Stops provide insightful information in bite-size chunks that highlight aspects of the section they are in. They should be part of the reading within each chapter. They may also be used as a means to browse through the book in order to get a sense of what each chapter and section therein is about.

1.4 Value of this Book

This book provides a number of valuable insights, details, guidance, and considerations when applying CM to Agile. Specifically, the value and benefits of this book include:

• It provides a unique perspective on how to adapt Configuration Management for teams that are using Agile methods. This book includes specific guidance, details, and considerations for adapting CM practices to support Agile values while still maintaining the values of CM. It also provides a unique approach to implementing CM for new Agile teams in a more iterative manner.

• It gives you enough information on Agile to understand its many facets from the various Agile methods, Agile practices, Agile roles, and the Agile mindset. It forms the basis of a stepping stone to seek more knowledge of Agile methods and practices.

• It provides specific details on CM, allowing readers to understand CM values, CM practices, CM roles, and the CM mindset.

• It provides a unique view in the area of implementing infrastructure for Agile. This is particularly beneficial when you are establishing a new product line following Agile methods. It helps you consider how you can more quickly establish infrastructure to ensure it is ready for the first iteration of development.

• It gives the reader an insight into both the Agile and CM mindset to better understand each perspective. It highlights Agile roles and Agile types (from Agile Champions to Agile Pretenders) along with the CM roles and how to integrate CM responsibilities into an Agile team.

CHAPTER2

CM Primer

Configuration Management (CM) is an engineering and management discipline that focuses on the management of change. CM enables change with its core attributes of identifying configuration items, controlling changes to items, auditing on the baseline of items, and reporting on the items. The basis for a CM process includes a set of functions that improve the integrity and quality of code, tools, documents, designs, and virtually any item that an organization desires to manage. Simply put, CM enables a person or group to manage changes to a project, a product, and even an organization. Since software development is not predictable, by identifying the pieces of the effort, a product or organization is better able to control changes to the individual pieces, the culmination of their software product, and the environment in which it is being built.

There has been a lot written in books and articles about CM and its capabilities. The objective of this section is not to recreate volumes of definitions and descriptions of what CM is. Instead, it aims to provide a concise summary and context for those involved with Agile specifically and for anyone in the software engineering field in general: to understand what CM is, in order to better support Agile and thus ensure we have speed with sustainability as we move into the future.

CM not only helps you manage the change, it attempts to provide a proactive model for change. Traditionally, changes should be considered and made after determining the impact of the change and the correct course of action instead of having to figure out what was changed after the fact. The CM model asks you to: understand what you want changed and why; make a decision to change or not; control the change; verify that the change was made; and communicate the change. In effect, CM provides a lifecycle for a change. In Agile, there are also many proactive decisions made that address what should be changed moving forward, beginning with iteration planning.

Pit Stop

As an enabler of change, CM instills the notion of proactively managing change for the right reasons.

A key benefit of CM is helping management and engineering manage changes. This ensures we can protect our assets, understand the changes to them, and reproduce the product as needed. Essentially CM provides the ability to ensure consistency, reliability, reproducibility, sustainability, and integrity of our assets.

Another key aspect of CM which is not often discussed is that CM provides a basis for communication and collaboration. It does this by providing the ability to identify and control so that we have a sense of how the product is evolving and discussions can therefore be based on known progress.

Interestingly enough, Agile also provides mechanisms to ensure we discuss proposed changes in a collaborative manner and then introduces daily stand-ups and end-of-iteration reviews to ensure we are aware of known progress. CM then provides the infrastructure where the team can work together using CM tools, branching strategies, and build processes.

Finally, CM enables the possibility for reuse that allows a team to avoid recreating something that may already exist and reducing the waste of the time spend on this activity. A side effect of reuse is that it facilitates communications amongst the project team so that everyone is aware of the functionality of the reusable items.

2.1 Brief History of CM

Configuration Management has been around since the 1950s, primarily used by the United States Department of Defense to manage changes to hardware and then to their software engineering work as software development became more prevalent. Early CM was mostly manual but as the volume of items that needed control grew, CM tools sprouted. CM tools provided a more automated way to manage changes while maintaining a historical record of the changes.

The first CM tool was called Source Code Control System (SCCS), developed by Bell Labs in the early 1970s, which primarily provided version control functionality. Subsequent early tools included Revisions Control System (RCS), Panvalet, Change and Configuration Control (CCC), and Concurrent Version System (CVS). While some of these older tools are still around, there was a significant increase in vendors getting into the business as development became more complex and companies were looking for more features and support. The CM tool market has become so large that it is now a multi-billion dollar business.

While CM tools expanded, CM practices that went much beyond tools were key to organizational and product delivery success. Over time, many other companies began using CM practices because of the control they realized and the ability it provided to protect their assets and ensure integrity of their products. Today, CM is pervasive in most software development organizations, with varying levels of discipline being followed.

CM has since been recognized and adopted by many organizations as well as frameworks and standards such as the Capability Maturity Model Integration (CMMI), the International Organization of Standardization (ISO), the Information Technology Infrastructure Library (ITIL), and others. It should be noted that each standard and framework model has its own definition of CM but the notion of identifying and controlling changes is consistent across all.

2.2 CM Values

Traditional CM comprises four fundamental values or components. They include Identification, Control, Audit, and Report (a.k.a., Status Accounting). It is important to communicate the definitions and interpretation of these components to those in the workplace to establish a common understanding.

Figure 2-1 Four fundamental values of configuration management.

Below are overviews of the four CM components that may help in communicating the definitions in more general terms. This can help facilitate a quicker understanding of CM throughout the organization.

2.2.1 Identification

The first value that CM provides is the ability to identify all configuration items (CIs) related to the product and the changes therein.

Figure 2-2 First value of CM - identification.

By identifying CIs, you establish a baseline of software-related items where you can then control, audit, and report the changes occurring to this baseline. CIs may include the product deliverables and the corresponding plans, requirements, specifications, designs, source code, executables, tools, system information (i.e., software & hardware platforms, etc.), and test cases, etc. Further consideration is given to the exact version of the tools you are using. Are you using release 4.1 of a tool or release 5.0? A different release of a tool may output different results.

Figure 2-3 CM identification sub-process.

The component of identification may be divided into four sub-processes: Detect, Name, Acquire, and Baseline. Detect refers to defining and identifying the CIs that make up your product. This is more than just source code. This may be web pages, documents, or even requirements. Name refers to developing a nomenclature that is unique, unambiguous, and traceable to easily identify and locate the CIs. This typically evolves into naming conventions. Acquire is the process of collecting the CIs under CM control. Baseline is the process of establishing a cohesive and meaningful set of CIs. Within the context of Agile, the identification sub-processes should be adapted to support Agile projects. More specifics on this can be found in chapter 7 - “Adapting CM Practices for Agile”.

2.2.2 Control

The second value that CM provides is the ability to control changes to all configuration items (CIs) in your product. While the first value (identification) provides us with a means of identifying when changes have occurred, control allows us to take a proactive approach to change so that we can decide when change will occur.

With the proactive nature of control comes the ability to request changes and track requested changes to closure, including the change control process of approving or disapproving the changes.

Figure 2-4 Second value of CM - control.

The sub-processes of Control are version control, change control, build management, and release engineering.

Figure 2-5 CM control sub-process.

Version control refers to the versioning of configuration items. Changes are typically controlled by a “version control” process and all changes are versioned incrementally. Modern version control processes typically are integrated with tools with version control capabilities. Change refers to an effective means of proactively controlling changes to a product. An effective way of facilitating control over changes to a product is to implement a Change Control Board (CCB). The CCB represents interests of the project manager and all groups who may be affected by the change to the software baseline. The CCB authorizes the establishment of a software baseline, reviews and authorizes changes to a baseline, and approves the creation of products (via releases) from a software baseline. Build refers to a standard repeatable and measurable build and release packaging process. Release refers to a controlled way of acquiring approval for release deliverables, installing and configuring the product into production thereby establishing the production baseline, and making the product generally available to the customer. Within the context of Agile, the control sub-processes should be adapted to support Agile projects. More specifics on this can be found in chapter 7 - “Adapting CM Practices for Agile”.

2.2.3 Audit

The third value that CM provides is the ability to ensure correctness, completeness, and consistency of baselines. This helps us ensure the integrity of the product under development so that it can be determined if the actual configuration of the product and changes therein are aligned with the physical and functional specification that were agreed upon. In other words, is what we said we would change actually what was changed and were there any unauthorized changes?

Figure 2-6 Third value of CM - audit.

The sub-processes of Audit include two activities. The first is to analyze the baselines and processes. The second is to assign action items for issues and non-compliance so that improvements can be made. In effect, this provides CM with a continuous process improvement loop.

Figure 2-7 CM audit sub-process.

CM auditing may be implemented by selecting members from the project who work with CM personnel to periodically audit different CM areas. By carrying out the CM auditing function, a more systematic improvement of the quality of the software assets may begin.

It is important to note that the term “audit” can bring about considerable resistance in an organization. You may consider changing the word “audit” to “analysis” or “assessment” to make this task appear less threatening and start by performing limited analysis or assessments when the organization is very young or less mature and using the results for improvement and not punishment. Within the context of Agile, auditing needs to be lean and adapted for an Agile process based on how value-added the activities are perceived to be. More specifics on this can be found in chapter 7 - “Adapting CM Practices for Agile”.

2.2.4 Report

The fourth value that CM provides is the ability to record and report the status of components surrounding projects. This is a form of communication that helps us understand what has changed, the evolution of changes, and the status of CM in general.

Figure 2-8 Fourth value of CM - report.

More traditionally, reporting is referred to as Status Accounting. The primary benefit of reporting is that it affords an opportunity to systematically collect the data needed, record the data in a measurable, meaningful, and repeatable way, and then report on the data to the appropriate personnel for improvement opportunities.

Figure 2-9 CM report sub-process.

The sub-process includes documenting and reporting on changes, providing quality and productivity metrics, providing results of software baseline audits, version history of configuration items, and meeting minutes. If the generated CM reports are important for tracking the efforts of a project, then these reports should be kept in a repository. This provides a traceable way of reviewing past reports and comparing them with current information. Within the context of Agile, CM reporting should be kept lean and focused on the status and metrics that are perceived to be of high value to the Agile team. More specifics on this can be found in chapter 7 - “Adapting CM Practices for Agile”.

2.3 CM Practices

Within the world of CM, there are a number of practices that are implemented on a product and projects therein. CM practices are an extension of the CM values and provide an approach for conveying those values in a workplace. CM professionals define practices for their organization, product, or project in order to improve the way CM work is done.

A practice is typically a collection of processes, approaches, techniques, strategies, and tools that work together to achieve a repeatable goal. A “best” practice is tailored in a specific way to help a unique team achieve superior performance. In most cases a best practice for one team or organization is not necessarily a best practice for another.

Pit Stop

A “best” practice is tailored to help a unique team achieve superior performance. In most cases a best practice for one team is not necessarily a best practice for another.

For example, a general CM practice is “version control”. Since there are so many different ways version control processes and tools can be applied, what is best can vary from team to team. As mentioned, practices are defined in different ways depending on the need of the workplace. Below is an attempt to loosely define the common CM practices.

2.3.1 CM Planning Practice

Configuration Management (CM) planning focuses on establishing a common approach for how CM will be implemented consistently and effectively on a product line and projects therein. A CM Plan (CMP) has traditionally been established as a document that specifies the way configuration items and their attributes will be:

• Identified uniquely and as a configuration set

• Controlled via version control, change control, build management, or release engineering of the configuration set (the size of the set will vary based on the focus of the control) and specifically control and who authorizes changes.

• Audited per the configuration baselines and the configuration items therein at any given point in time.

• Reported where the results are accurately recorded on any of the identification, control, and audit activities to verify integrity and consistency of the configuration set and changes therein.

While the name “CM Plan” seems to imply that there is an actual project plan for Configuration Management, the “plan” is really a strategy to ensure you have considered the CM elements for the product and effort therein. Also, the CM Plan effectively becomes the hub for all CM-related components and activities. A typical CM Plan includes the following sections:

• Introduction - this is where you document the CM scope and objectives for the product.

• CM roles and responsibilities - this is where you list the roles and the corresponding responsibilities of those who perform CM tasks. In more traditional methods, many of the CM responsibilities will have separate CM personnel allocated to them. In an Agile world, CM responsibilities may be shared.

• Overall CM structure - this illustrates how CM fits into the product team and/or organization.

• CM terminology - this includes the common CM terms and acronyms used on the product and/or organization.

• CM documents - this includes descriptions and links to CM documents, such as policy, processes, tools, templates, and any other artifacts that may have an impact on CM and the product.

• CM activities - this provides the list of work necessary to implement and maintain effective CM, revolving around the CM values of identification, control, audit, and report.

A key benefit of CM planning is that it allows the team to consider the CM values, processes, tasks, roles and responsibilities, and structure needed for the product. Because it provides an overall perspective of what is needed for CM, the team can consider implementation strategies for CM based on the methodology. In general, it makes you reflect on your CM needs and consider the options moving forward. For example, a more traditional lifecycle methodology may apply a big effort, up-front approach, while a more Agile lifecycle methodology may apply a more iterative approach to the implementation of CM. In having a perspective of the CM picture provided by a CM Plan, the team may also decide to only implement the areas they see of immediate value and consider others down the road.

Another reason why a team may need to implement CM planning is if the organization in which the product team lives is following an industry framework or standard (see below). These frameworks or standards include a CM component because they recognize the importance of CM to organizations. It is important to review any framework or standard so that you understand the impact and details when implementing CM.

• Institute of Electrical and Electronics Engineers (IEEE).

• Information Technology Infrastructure Library (ITIL) CM.

• International Organization for Standardization (ISO).

• Capability Maturity Model Integration (CMMI) CM (process area in level 2).

It is also important to understand that CM planning approaches and plan templates vary across the industry. If your organization follows a specific industry standard, then identifying the specific CMP template for that industry standard is appropriate. However, if you are not following any industry standard, it is worth identifying the various CMP approaches and templates available on the Internet and within other industry standard organizations. In the case of Agile, the details in chapter 7 - “Adapting CM practices for Agile” will provide insight into approaching CM planning for Agile teams.

2.3.2 Version Control Practice

Version control is a CM practice that combines a sequential numbering scheme for artifacts within the same lineage as they are changed and a repository and tool which automates the management of archiving the artifacts and their changes using a check-out/check-in process. Version control is the most widely used CM practice and the one found most valuable by Agile teams.

Version control systems, referred to more commonly as CM tools, have basic version control functions. However, the more modern CM tools include more functionality from branching and merging, to change sets, to workspace management, to build features, and more. Because version control is so important, its functionality is built into word-processing programs, document management tools, and databases.

The most important benefit of version control is that it is one of the key mechanisms that protect your software assets (code, documents, etc.) via a secured code repository. These days a quality version control system should version control not only source code, but also executables (a.k.a., deliverables), document, data files, and a variety of other elements that require version and change tracking. In addition, modern systems provide version control of the directory and align and track the contents within the directory to the directory container.

CM version control technology is perceived to be core and critical to the job function of a CM professional’s work and they believe it is critical to maintain the source code of the product. Version control is typically the first technology that a product team wants and it is the first tool implemented. Some of the CM professional’s work revolves around installing, improving, and maintaining the version control technology. By having a control mechanism of change, this helps avoid one engineer overwriting changes made by another.

The documented version control procedure is valuable when there are company standards like Capability Maturity Model Integration (CMMI). Otherwise, the value of a documented procedure diminishes over time, depending on the use. Keep in mind that CM professionals, like Agile professionals, do not want to write a document if it will not be used. However, in the case of the check-out/check-in procedure, when they must continually show people this process when engineers are new, then the value of the procedure or training is seen as high.

Agile teams perceive version control to be of high value. Consider reading chapter 7 “Adapting CM practices for Agile”, chapter 8 “CM Tool as a Strategic Agile Partner” and chapter 9 “Evaluating Tools suited for Agile” to get a better understanding of your version control needs for Agile.

2.3.3 Change Control Practice

Change control is a practice that is used to proactively manage changes to a baseline or environment. This typically includes defining the baselines for control, establishing a Change Control Board (CCB) who authorize the establishment of and changes to a baseline, defining CCB conduct guidelines, and defining repeatable change control processes to manage changes to the baseline(s).

The change control practice is initiated once the baseline is formally approved. An example is a requirements baseline. After several weeks of discovering, collecting, prioritizing, documenting, and reviewing requirements, a set of requirements is approved and baselined. Once this occurs, the change control practice is initiated to manage changes to the requirements baseline. Within this practice, changes are initiated via the stakeholder who submits a change request that highlights the requested change. The change is analysed to understand the details and estimated effort of the change. Then the CCB meets on a periodic basis to review and rule on the change. If it is accepted, then the requirements baseline is updated with the change and the work is assigned to a change agent, typically a programmer.

The benefit of initiating a change control practice is in ensuring that there is a way to manage changes to the product. The goal is to be open to change but a traditional method tends to constrain change, since stability in the baseline tends to be the goal. Interestingly enough, a type of change control does occur in Agile in relation to the iteration planning sessions. More details on this topic can be found in chapter 7 - “Adapting CM Practices for Agile”.

2.3.4 Build Management Practice

Build management is a common and highly valued practice in CM and in software development that includes a tool and process component. Build management (a.k.a., build) is the process of identifying source code (preferably in a CM version control system), and through some means of compilation or generation (via a compiler, linker, IDE, etc.) produces a set of executables and other files which can be used to perform a run-time function that represents a deployable product in part or in whole. These executables and deliverables form the basis for the product release and are the income-producing assets for software companies. Often, the build process is combined with the package, migrate, and release processes, since there is a strong affinity amongst them with a focus on getting a product from development into production.

Traditionally, build processes are a combination of manual and automated steps with a simple set of scripts, often hard-coded to specific systems, and developed by CM professionals and/or development staff on an ad hoc basis. With the advent of a growing need to support a number of platforms and languages, the move into geographically distributed development, and new methodologies like Agile, there is an increasing need for more sophisticated and advanced build tools. Also, in many cases the build engineer attempts to automate at least some part of the process, if not all of it.

The build process incorporates the use of a build tool. The build tool should support your process. It should also have the ability to establish end-to-end automation of the process, from identifying and preparing the code and build space, to building the code, to migrating deliverable into the smoke test area. The tool should provide the ability to build on various platforms without having to initiate a build per platform. It should be able to build in a distributed nature on various platforms. It should provide the ability to automatically gather and send build errors on any platform. It should integrate easily with test tools and problem management tools. It should be easy to administer the tool and provide the ability to utilize naming conventions (labeling), the standard build process, and stages therein. When approaching the build process, a key consideration should be given to the method that is being followed and how much build feedback the team is able to handle.

Build management is considered very important by CM and Agile professionals alike. A build process informs a team of the health of a product when their code is compiled and linking successfully, and when it is not. Product teams that use build management effectively find that more frequent builds help them identify integration and build issues earlier in the lifecycle, providing the opportunity to resolve issues more readily and allowing the team to have more stable and unified software. Effectively the more frequently you build, the more you reduce the risk of having unstable software.

Introducing Agile methods that focus on engineering practices raises the bar in this area by introducing continuous integration and build. This provides continuous awareness on the product health and its ability to integrate and compile together. Consider reading chapter 7 - “Adapting CM Practices for Agile” to get a better understanding of adapting build management for Agile teams.

2.3.5 Release Practice

Release is a common and highly valued practice in CM and Agile that focuses on managing changes into production. This typically includes defining a release migration infrastructure and a repeatable release process, which may include identifying baselines, attaining approvals from the CCB or customer, and installing deliverables into production (e.g., on servers or onto media).

The key deliverable of a release practice is the product release package and release notes that include the list of features in the release (typically based on the requirements or stories), defects corrected, installation instructions, and other information that is pertinent to the installation and maintenance of a release. The role most commonly assigned to execute this practice is the release engineer.

The benefit of a release practice is that it provides the product team with a repeatable way to get a release into production. It also ensures that the stakeholders are the ones who make the decision whether to accept or reject a release. A way to ensure repeatability and integrity of the release package is to automate the process as much as possible and ensure the release deliverables come from the CM version control repository.

2.3.6 Problem Management Practice

Problem management is a common and highly valued practice in CM and Agile that focuses on managing and resolving problems in a project, product, or organizational lifecycle. A “problem” may be divided into (but not limited to) types such an issue, a defect, and noncompliance. This practice typically includes establishing a problem management infrastructure and a repeatable problem management process to track problems to closure.

Problem management is initiated at the beginning of all project lifecycle methods, including traditional and Agile methods, since problems can arise at any time. Problems are managed much like changes to formal baselines: where a problem is identified, it is analysed and prioritized, a decision is made about when it will be corrected (release, patch, etc), and it is assigned to a programmer to fix.

Pit Stop

I had heard of an Agile project that was using their defect tracking tool as the system of record for work. They entered their stories as change requests into the system. This essentially became a master backlog of work which they managed to.

The benefit of having a problem management practice is that it provides a repeatable and closed-loop way of ensuring problems are identified, considered, and corrected and so problems that have been uncovered do not get lost. When a number of problems are identified and require tracking, it is beneficial to have an automated problem management tool (a.k.a., defect tracking) to reduce the effort of tracking problems manually and to enable problem management metrics (e.g., defects open, time to closure, defect severity counts, etc.). Consider reading chapter 7 - “Adapting CM Practices for Agile” to get a better understanding of adapting problem management for Agile teams.

2.3.7 Audit Practice

CM Audit is used to determine the integrity of baselines and to assess compliance to CM policy, processes, and technology usage. This typically includes defining a repeatable audit process to assess compliance, recommend improvements, and report audit results. The CM Audit practice is more often used in mature organizations, organizations that build mission-critical or health-related products, and organizations that align with industry standards and frameworks. This is because there must be an assurance that what was requested to be built can be clearly identified in downstream baselines.

The CM Audit practice may include an audit checklist. Audit checklists include areas of focus that help determine if the users of the CM system are following the CM processes (and their corresponding roles), if the deliverables being developed can be identified in the development (and production) baseline and traced to the requirements to verify their traceability and integrity of the release deliverables.

Since CM focuses primarily on the development or code baseline, this tends to be the place where the CM Audit occurs. From an Agile perspective, this helps identify if what was supposed to be worked on is actually being worked on, and to identify any over-production where programmers are working on changes that have not been allocated or approved. The CM Audit process can be somewhat automated, particularly if there is an interest in comparing the source code baseline with the production baseline.

The benefit of the CM Audit is that it provides a way to evaluate and compare downstream baselines with upstream baselines to ensure the right work is occurring. However, it is often seen as a heavy practice, so thinking of creative ways to keep it lean and streamlined are important. Consider reading chapter 7 - “Adapting CM Practices for Agile” to get an understanding of adapting CM Audit for Agile teams.

2.3.8 Report Practice

The CM report practice focuses on communicating the status of CM tasks to the team and management. This typically includes establishing necessary CM reports from a repeatable report process that will collect the CM status on progress, measures, training, resources, achievements, audits, and outstanding issues.

As you approach CM reporting, consider automating all or part of the data collection, report generation, and distribution of the CM report. If the report is too difficult to collect and generate, then the report process will not be sustainable over time. If this is the case, consider another approach or do not collect and generate that particular data. Consider the value of the status on each report and ensure it is useful (e.g., can it be used to validate that processes are running well or to make improvement decisions?). Otherwise, it may not be cost-effective to produce the report.

In addition, the report practice focuses on establishing CM metrics to determine the health of CM-related practices and product development in general. This may include lines of code, change rate, build times, and a myriad variety of metrics. However, it is important to assess the value of each metric to ensure you are applying metrics that provide the biggest benefit for a reasonable amount of effort. The benefit of applying this practice is that it stresses communication of CM activities in order to continuously improve the support CM provides to the team. Consider reading chapter 7 “Adapting CM practices for Agile” to examine lean approaches to CM reporting and metrics.

2.3.9 Other Practices

It is important to understand that there are other practices in the CM space. This may include identification, naming conventions, branching and merging, global distributed, and other practices. It should also be noted, that typically you cannot have a branching and merging practice without a version control practice.

2.4 Benefits of CM