Does the Agile Manifesto read like a Deceleration of Independence?
The Agile Manifesto happens to be a unique piece of document. I cannot find any equivalent document in whole of software engineering history. Why only software engineering, I cannot think of any equivalent in any field of engineering.
Think of how it was developed. In February, 2001, seventeen like-minded people got together and came up with the manifesto. They got together because all of them had a common goal … to break out of the rigidity imposed by the prevalent heavy-weight processes. Many of the members of that group had already proposed their own solutions, their own different light-weight process. These processes had little in common.
But, in less than a day they came to a common understanding.
They agreed on the term “Agile” … They drafted the “Manifesto” … They wrote down the twelve guiding principle behind the manifesto.
No committee was formed. No pre-work had been done. There was no prior “plan” to create a manifesto. There is no motivation to “sell” anything. It happened spontaneously.
Subsequently others have tried drafting manifesto for many other topic but non of them have been spontaneously and have never matched the universal appeal of the agile manifesto.
Once the manifesto was in place it slowly went viral. Today, everybody agrees that agile is the way to go.
What makes the manifesto so enduring?
Apart from useful advice explicitly stated in the manifesto, there is an unstated message which comes across clearly.
It provides the reader a sense of freedom.
It is protest against rigid and inflexible planning.
It urges the reader to break free of shackle imposed by processes.
It advocates trust and cooperation.
It begs you to think.
Manifesto reads like a declaration of independence
It is about the freedom to choose your own method of working … a process that works for you … your team … your project … your organization.
It is about having the flexibility to make changes to how you work … keep those practices that work for you and reject those which do not work … adopt that which you think may work with the knowledge that you can discard it if it does not work.
Points to Ponder
Having said that the agile manifesto gives you the permission to reject the rigidity of the so called heavy-weight processes, does it mean that you should reject everything that is a part of heavy-weight process? Do you really think that there was no practice of any value to be found there?
Maybe some of those practices where designed for a specific situation where it worked well. Maybe the people who designed them where intelligent, experienced and knowledgeable software engineer. Maybe the practices became ineffective because they were lumped together and applied for all situations.
So, having earned the freedom to choose your practices, should you not look at some of them and evaluate it for suitability?