Conclusions About Agile SCM, and Next Time: Part Deux!
Agile SCM is about having an Effective SCM process that helps get work done by establishing and ensuring the orderly, efficient flow of software development change & collaboration. Our aim with this article is to advance the cause and definition of "Agile CM". Anything claiming to be "Agile" needs to legitimately embrace the ideals of collaboration and the human element that Agile emphasizes, as well as Lean principles and techniques, including some heaping helpings of Theory of Constraints (including Critical Chain) and [Lean] Six-Sigma as they apply to CM and the "throughput" of change-flow, and change management.
The term "Agile" and the ideas behind it are no better or different from other labels (often called "fads") like Object-Orientation or [software/design] Patterns. They had lots of hype and buzz and they had some legitimate improvements to contribute to the state of the practice (even if the ideas themselves weren't new - that's not necessary in order to have great impact/influence). But once everything was all "hyped out" they faded into the woodwork, as a natural, acknowledged, part of the fundamental knowledge we should use and apply everyday.
Many tools/vendors are already headed in that direction, and have recognized the trend foretold by Tom Friedman (The World is Flat), Peter Fingar (Extreme Competition) and others like Dan Pink, John Seely Brown, and more. With CollabNet, MS VSTS and Rational Jazz, the emphasis is on connecting and collaborating. Ways of doing software development and CM that fail to acknowledge that, and at least the first five of what Steve McConnell calls the ten most important ideas in software engineering are going to have a tougher go of things than they have in the past.
As to whether or not "Agile CM" legitimately exists in its own right, that is determined by the people who end up actually doing it, and we count ourselves as well as other contributors to CMCrossroads as amongst the vanguard (although some would call it good practice as opposed to "Agile"!). Just as there are many different styles of architecture, and each has its appropriate context and use, so too are there different styles of CM, each with its appropriate context and use. There is more than one way (style) of doing good CM (and many more ways of doing it badly), and not all good ways will have the same style, nor should they.
The proof of the pudding, as ever, remains in the eating, and we thus welcome contributions/comments as to our success or otherwise of our efforts so far!
Next time we will be looking at the application and relevance of ideas from Lean Development, TOC, Six Sigma, and will also consider applying agile ideas to Change Control and CCB aspects of CM, as well as Value based software engineering (VBSE)