In-Depth

Solving the Puzzle: Configuration Management in Agile Development

Experts and users weigh in on the challenge of integrating configuration management into your agile development projects.

• By David Ramel
• April 5, 2010

Are you having trouble controlling changes in your agile development project? Could a vital piece of the puzzle be missing from your process? Mario Moreira thinks so. He believes solving the puzzle requires some new thinking.

"I'm here to stretch your brains," said Moreira, addressing more than 60 developers at last week's meeting of the New England Agile Bazaar user group in Waltham, Mass.

Moreira is a configuration management expert and author who specializes in configuration management as it applies to agile development. He is the author of the recent book, Adapting Configuration Management for Agile Teams (Wiley Publishing, 2010), and the agile/configuration management champion at software giant CA.

"Configuration management is basically the process to ensure the integrity of your product at a very, very high level," he said in an interview with this site before his presentation. "What that really means is: ‘Do you have the controls that will ensure the change you intend to make actually gets made, and that when you make the change, that it's the right change?' So basically, controlling change. Can you identify it? Can you put a control on it? Can you report on it -- actually indicate that you make the change? Things like that."

Configuration management has been around a lot longer than agile development, though, so why is new thinking required? Moreira said that very few agile methods, with the exception of Extreme Programming, even address configuration management. But with the increased speed of agile processes, he said, companies need to make sure their change mechanisms keep up with the fast pace.

Also, they need to allow for many new practices. Moreira used as an example the technique of pair programming. That's when two developers work together on the same machine, with one coding and one reviewing and providing input, switching places every 30 minutes.

That can bring up a lot of questions, he said, such as "Do you use one workspace? Do you use two workspaces?" And after the 30-minute swap, "Do you check it in at that time? Do you not? Do you check it in and then the other person checks it out from their workspace, or do you use the same one?"

Those particular questions can be answered in different ways, he said, depending upon how much risk a team is willing to take. Some advocate checking code in after the swap and checking it back out in case an error is made a particular version needs to be recovered. Others accept more risk and keep working on the checked-out code.

In his presentation he touched on general concepts and specific areas of concern such as dealing with customers, the idea of "project owners" and project managers, moving from event-driven to continuous processes, adapting to continuous integration and builds, refactoring, minimizing merging, sprint planning and many more.

Many of those techniques aren't new to attendee Paul Fernandes, who was doing agile development long before it was called agile development. "I was doing things that made sense, but I didn't have a name for them. We were just in a specific situation that required us to work smarter and be in much closer contact with the customer," Fernandes told this site in an interview after the presentation. He is director of software development at U.S. Genomics in Woburn, Mass. "I've seen huge benefits" from agile development, he said. But he cautioned that while people seem to be jumping on the agile bandwagon, "it's not appropriate for everything. It's not a silver bullet." He said the process should be tailored to the one's specific environment, taking into account factors such as acceptable risk levels and company culture.

Also, Fernandes said, companies can't just dictate to developers that they must start using agile methodology, because it takes specific skills and personality types to be successful. Often, he said, dev teams are better served with a combination of agile and more traditional methods.

Attendee Kaj Telenar has firsthand experience with that very issue. While in a previous position, "I got a lot of push-back from the legacy C++ developers who didn't want to use agile development techniques" said the currently unemployed development manager in an e-mail message after the meeting. Also, he said, "I found it difficult to convey some of the agile practices to overseas teams."

Agile pioneer Fernandes said that configuration management isn't new to him, either. "This is something that I've keyed on quite a bit. It helps automate builds, unit testing, branching, merging and deployment of the actual code."

As far as configuration management's marriage with agile development, he said, "To me there isn't really an agile configuration management system. I think the configuration management tool needs to be supportive of the agile processes, meaning that this constant checking in of code, checking out, automated builds -- it needs to provide automation. And you can basically take most configuration management tools and use them in an agile way."

One such tool that he has used quite effectively is Microsoft Visual Team System, Fernandes said.

Telenar has also successfully used configuration management tools. "I have always used a change management/version control system, such as cvs in Unix, PVCS on DOS, Source Safe and Visual Source Safe on Windows and more recently Subversion," he said.

David Rosenberg, a recently retired senior programmer/analyst who was working for MIT in Cambridge, Mass., didn't need special configuration management tools. "I was working in an environment (SAP) where configuration management was built-in and hence not something requiring a lot of thought or planning," he said in an e-mail message after the meeting.

Speaking about agile development in general, Rosenberg said several aspects of the technique can provide multiple benefits. "Refactoring can improve code, make it more logical and easier to understand and modify in the future. The attitude of being open to mid-course corrections to both requirements and architecture makes for a saner project."

But problems can arise with agile development if teams aren't careful, he said. "Not thinking through likely extensions and future developments results in a lot of refactoring that could have been avoided if there was a bit more upfront planning."

Nevertheless, he is an agile supporter. "I like and embrace the idea of being willing to change direction as necessary," he said.

Telenar also is onboard. "Using agile is a win/win/win for developers, project management and users," he said.

Moreira, meanwhile, will continue to spread the word about CM and agile development. He said there are many questions that companies need to answer as they undertake configuration management in an agile setting, but the main question is: "Are you even aware that you need to adapt?"