(and still enabling self-organization). This is the view that Lean takes toward management, and is a big part of why it is better received by management and is more broadly applicable for scaling agility "up" and "out" in larger enterprises.
Upon understanding this, we then we realize why we perhaps need to pass the "Agile" baton on to Lean and the likes of the Lean SSC ( www.leanssc.org) rather than the agile alliance.
Furthermore, perhaps the notion of "Agile SCM" (and even "Lean SCM") is inherently flawed because it limits the focus to just Software CM rather than to the whole 'system' that creates and delivers software products; focusing it on SCM without the larger context might be all too likely to result in sub-optimizing by optimizing SCM at the expense of some other aspect of the business/enterprise.
So that leaves us with " Leaning CM for Agility " which doesnt invent a new "brand name" but simply describes the act of applying Lean to CM (presumably as part of applying Lean overall, not just CM) with the purpose of achieving the "attributes" of agility: adaptive, goal/end-result driven, iterative, lean, emergent. Where the "results" of agility are the ability to quickly and easily sense (and make-sense-of), respond-to, and create change through a balance of adaptable people/planning and sinmple yet flexible structures.
While we havent given up on the original purpose of agile, we recognize the course that "ship" has sailed, and look more to Lean for additional direction and focus. By virtue of Lean, this supports the notion of making something (in this case CM) more "lean", or "leaning it out" by focusing on value in the value-stream and balancing the load to achieve fast, flexible flow of valued changes. Often we can do this with a relentless focus on simplicity and "keeping things simple." Granted, many misconstrue the meaning of "simple" here -- see Simple Ain't Easy: Myths and Misunderstandings about Simplicity for what we mean (this blog-entry was the original and more in-depth version of Brad's Nov'07 article in Better Software magazine ), as well as through simple (generative) rules, as in the Dee Hock quote:
"Simple, clear purpose and principles give rise to complex, intelligent behavior.
Complex rules and regulations give rise to simple, stupid behavior."
-- Dee Hock, Birth of the Chaordic Age
This also gives rise to the notion of identifying "waste" in our current CM implementation, and eliminating (or preventing) CM "Debt". Regarding "CM debt", we need to define what it is, how to recognize it (like one recognizes "waste" in Lean), and common forms of it in CM, like integration-debt (delayed or big-bang integration), branching anti-patterns, and other SCM anti-patterns. We hope to do this in future articles. (For now, you can read Technical Debt - Definition & Resources and especially see what Chris Sterling has to say about "CM Debt" in Architecture in an Agile Organization .)
So perhaps it is more along the lines of “Agile SCM is dead, long live lean & agile for CM ”?!