Is Continuous Integration Just Another Buzz Word?

Last month we wrote that we would be addressing some questions and concerns raised by readers who gave us feedback on previous articles. We still intend to address these concerns. However, since the theme for this month (continuous integration) is one of the core "enabling practices" of agile methods like extreme programming, we felt it necessary to shift our focus this month to cover it instead of what we had originally intended.

What is Change Management?

"Change management is a general term encompassing controlling and tracking change. Change management may be very low ceremony (developers handle physical cards) or high ceremony (change is allowed only through formal change control boards), but should be set to the appropriate level for the given development domain and culture." (Grady Booch, posted 08 July 2003 on the extreme programming mailing list).

To some people, change management refers to a delivered product configuration and its physical and functional contents. Controlling changes is then largely about ensuring that the delivered configuration conforms to its physical and functional specifications, and that it is indeed what you said it was when you agreed to produce and deliver it.

Others regard change management as more of a project management function to manage the scope of work that is performed to provide a product or service. Controlling changes then becomes largely about managing expectations to realistically match the amount of work that can be accomplished within the agreed upon scope and schedule, and the means by which scope and schedule changes are accepted

The reality is that change management encompasses both of these perspectives: the project's scope and the product's scope. What's more, the project and the product may each have different customers whose needs and expectations aren't always in alignment. Successfully managing and tracking the expectations and requirements of the project's organization and sponsors, as well as the product's purchasers and consumers (end-users) hinges upon successful cooperation between the project management and configuration management functions.

What is Agile Change Management?

So what's so agile about change management as proposed by the agile methods "du jour"? The agile in agile change management can be interpreted in a couple of ways:

  • Change management that successfully meets the needs of an agile project
  • An approach to change management that is agile in its own right
  • These are not mutually exclusive: an agile approach to change management certainly helps to meet the needs of an agile project. So there is a broad area of overlap between the two. Furthermore, the argument can (and perhaps should) be made that so-called agile change management is really just plain old sound, and solid change management practices. You know, the things that we are supposed to have been doing all along, but either got lost in all the noise, or perhaps just fell upon deaf ears.

Whether we regard agile change management as new, or yet another case of “what's old is new", an agile spin has since been spun: it is a focus on close collaboration via informal face-to-face communication, and on keeping processes and tools lean and simple. Let's take a look at some relevant portions of two of the more commonly used agile methods today: eXtreme programming (XP) and scrum.

Agile Change Management in XP

At the beginning of each iteration (which lasts typically between 1-3 weeks), XP conducts the planning game: the project manager, developers, and customers get together in a room and look at the existing back-log of to-be-implemented requests (called user stories and captured on plain index cards). The customers may add or remove requests from the stack. Developer's converse with the customers and attach estimates to each request. (See [1] for more details. 

Then the customer decides which requests they want implemented during the next iteration. They do this based upon the iteration length, the estimates for each request, and their stated priorities about which requests are the most important. The customer may completely change priorities from one iteration to the next. This is okay as long as development and project management agree the result can be successfully implemented within the scheduled period


About the author

About the author

About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.