I believe what people intend when they say there is nothing new in the AgileRevolution is the fact it aligns with how skilled practitioners have always done their work, not that these ideas were previously captured by the advocates of traditional approaches. It might be more accurate if agilists represented themselves as anthropologists documenting the workings of a pre-existing culture, as opposed to discoverers of something new. Sure, they are doing something new in terms of writing textbooks about the stuff, but that is analogous to the first person who published sheet music for jazz or blues claiming to have invented them.
I believe what people intend when they say there is nothing new in the AgileRevolution is that they are scared of change.

Sure they are skilled practitioners, but they dismiss this as a revolution because they cling to their skills, knowledge and successes. In the process they dilute the message and the potential change that applying AgilePrinciples to the root of software development can bring about. Let go of your expertise, shift paradigms, with a beginner?s mind see the many possibilities and join the revolution.

Maybe there are some of you who have been saying, to your teams and your customers:

Let's not bother too much on this contract negotiation

I can't predict the outcome of this software project

Success is achieved by giving developers greater freedom

Quality of Life is essential if we are going be part of an emergent living system

? but if you have, speak up, because none of these messages have had any impact on my existence in the mainstream corporate world of software development.

I like the first part of the article, which uses logic and experience to argue that the agile development process is a paradigm shift.

Do paradigm shifts always tend toward improvement? Why? Are the "old" pardigms retiring from the scene, or is it that the that one scene has retired and the new scene has brought with it new people, and new ways of doing things? If the new scene tends toward more simplicity and ease of use along with efficiency and accuracy, survival and long working life is likely. If the new scene tends toward more complexity and difficulty of use along with confusion and fuzziness, it will enter early retirement. -- DonaldNoyes

JohnNash? adds to the credibility of this statement when he mathematically proved that the AdamSmith economic model is not the most optimal. Optimizing collaboratively will lead to greater value that individual optimization.

Great article Mike.

As I read it, I couldn't help but think about the article JackReeves wrote. He argues that "the source code is the design". If one accepts that, then one must accept that making software is a creative process. That it's not like building a house - i.e. its not like architecture-plus-construction. Instead, it's just like architecture. That's a creative process. I can't imaging going to an architecture firm and seeing them use a defined, repeatable linear process. Instead, I would expect them to use a collaborative, iterative process - very similar to the one you describe in your article.

So, to summarize what I'm trying to say: I think that many people will be reluctant to adopt Agile processes because they don't see _why_ agility should work. And often, those of us in the "agile" camp don't help, because we don't explain _why_ it works. We just explain what it _is_, and assert that it works. I think we should present evidence to show that software development is a creative process. It is like what your architect does, not what your builder does. If we can convince people of that, "selling" agility may become much easier.