In his CM: The Next Generation Series, Joe Farah writes that anyone who thinks that agile development implies minimal CM is probably in the situation of not having to deal with customers. Instead, agile development requires agile CM; configuration management tuned to the agile development shop and philosophy.

Lean CM is the process of doing the minimum configuration management (CM) to support development of a product. Of course this can result in less than optimum returns. Agile CM is the ability to adapt CM to the specific needs of an organization or project. There's a big difference here. Anyone who thinks that agile development implies minimal CM is probably in the situation of not having to deal with customers. Instead, agile development requires agile CM; configuration management tuned to the agile development shop and philosophy.

Agile development/CM does not imply, for example, that we don't gather requirements. It implies that we gather them in a different way. We still need to know what to build and we still need to identify what was built. The difference is that we don't specify all of the requirements up front At first glance, this one example might make agile CM look more complex! We don't "do requiremets" all at once with a small team. With agile development requirements may be constantly changing - there's no single spec for the team to work from. So this does sound more complex.

But take a look at the Agile process, understand it, and tune your CM to it, and things take on a different tune.

For one thing, because agile is very incremental in nature, from a development viewpoint, it is more task-oriented than requirement-oriented, at least in a formal sense. However, when you dig deeper and look back through your agile project, you find that the task definitions actually more closely match the customer requirements, moreso than a requirements specification which is usually out-of-date by the time it's released. The traditional requirements specification does not benefit from feedback during development to help better understand and define requirements. It doesn't adapt easily to market changes, and especially to competitive pressures.

Many argue that at least a requirements spec gives a clear statement of what is being produced, allowing better testing, product documentation, and so forth. If I'm building a launch vehicle for Mars, this may be very important. If I'm building a cell phone, my better tested, well documented product will simply fail in the market place because it targeted a market which has moved on to greener pastures.

Don't get me wrong. Having a clear statement of what is being produced is critical. What has to be different with agile CM is how this clear statement comes into being. And in this case, CM becomes much, much more critical for agile development than for traditional development. Seems counter-intuitive at first glance. But consider that CM's main purpose is to manage change, and there's a lot more change happening when you're doing agile development.

So this is why lean CM will never do in an agile development shop. Lean CM has a much better success rate with traditional development, precisely because change is less radical. An agile shop needs to handle more change - and not just in specifications, but also in process. That's why we need agile CM, that is, CM that can adapt to the changing process.

Task Definition: Gathering Agile Requirements So how do we gather requirements in Agile Development? Well, first we have to ask the question: How do we know what to build? Then we have to ask the question: How do we tell the developers what to build? From the first question, we understand that

Pages

About the author

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com