Lean CM is the process of doing the minimum 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. 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 we must first have a product concept, and a number of "story cards" or other representations of how the product is supposed to work. These are an essential part of the requirements. And the CM tool must support the management, including evolution, of both concepts and user stories.
But the whole point about Agile is that we'll discover requirements as we go - at the end of and beginning of each iteration. Here's where the Product Managers and/or Product Owners come into play. They are critical players in determining what the priorities are for the next iteration. So the important thing is how to communicate these priorities - these feature tasks - for each iteration. From a CM perspective, it's how