Conceived in 2001 to members of the Agile Manifesto, Agile had a tempestuous upbringing. She became well known development circles as the new bright young thing. Admirers were always at her feet. She was cited as the inspiration for major successes, and for bringing some fun back in to development. But gradually the apparent novelty factor started wearing off, and she became coloured by a certain corporate greyness, and started fading into the background.
Alistair Cockburn took a similar theme in his excellent presentation at the Agile 2009 conference “ I Come to Bury Agile, Not to Praise It” ( http://www.infoq.com/presentations/cockburn-bury-not-praise-agile):
Agile has spread to large, globally distributed commercial projects, affecting the IEEE, the PMI, the SEI and the Department of Defense.
In last year’s review column, we touched on the Agile Backlash.
There are many signs that Agile has “crossed the Chasm” and become mainstream. Many organisations (a majority?) now claim they are “doing Agile” in some shape or form. How successfully will of course depend on many factors. There remain perhaps misunderstandings of the discipline required for successful Agile development.
There is a relatively common sequence of steps for the adoption of new ideas:
1. That’ll never work!
As some examples of success come in, this changes to:
2. It’ll never work here! (Our challenges are different.)
Ending up with:
3. We’ve always done it that way!
As regards Agile SCM, we think that this same sequence has been followed. Practices such as iterative development, continuous integration (and all that means for the improvement and repeatability of the build process), test driven development, patterns of working
Some CM people objected to the term Agile SCM, thinking of it is as simply “SCM for Agile development teams” and that calling it " Agile CM " suggests it is somehow different from CM or a "separate branch" of CM. Mario's Moreira's blog-entry The Chicken (CM) or the Egg (Agile) is a clear example of this. It treats the meaning of "Agile CM" as that of "CM for Agile projects", and maintains the status quo of CM thinking, suggesting that one really doesn't have to do or think about CM in any genuinely different way nor in any legitimately different style in order to accommodate agile projects! From this perspective, it's just another buzzword development method and we just have to make some tweaks and tunings here and there. And it's all still just the same good old CM from before!
We have always maintained that Agile CM is CM implemented "Agile style" in the agile mind-set according to the agile values and principles. Our contention was that the phrase “Agile SCM” did not imply throwing away sound CM principles, but instead focused on satisfying those principles and requirements in a slightly different way: emphasizing collaboration, flow and working results. There has been raging disagreement and very little acceptance of this in the SCM community. And with the aforementioned "agile backlash" and every ALM vendor and product marketer touting "Agile wares", everything is now "agile" - the term has been so commoditized and watered down that it has lost much of its original meaning, and impact.
There has however been agreement that SCM has needed to respond to Agile methods and principles – using Kanban or continuous improvement principles to: reduce cycle times, smooth friction in the development process, ensure appropriate automation while still being able to satisfy traceability requirements, etc..
Anyway, we think that there is a different reason to perhaps let the term Agile SCM just be subsumed into SCM (so henceforth we will