The Agile Manifesto, created in 2001, is an attempt to describe a better set of values and principles for developing software. This may sound a bit Zen, but the Agile Manifesto does not actually describe the best way to develop software. Or, if you prefer, it does not describe the best principles to develop software. It is only the attempt to describe the way or the principles.
Another way to describe this is to look at what Agilists say about requirements documents. Written requirements do not actually describe the best product for the customer, they only attempt to do so. In fact, the best product for the customer can only be found via the constant feedback of discussion and delivery. I believe that one of the core values of Agile is the constant search for better software development techniques and thinking. What is the Manifesto if not a user story that attempts to describe the needs of software development itself?
Therefore, doesn’t the Manifesto imply, no demand, that it be constantly reviewed and, if needed, updated? Isn’t that the whole point of Agile? Doesn’t the fact that this is not happening point out a major problem that needs to be immediately addressed?
What happened to changing requirements? The requirements of software development itself haven’t changed since 2001? Nonsense! How can we face the skeptics if we don’t even believe in the Manifesto enough to change it? Shouldn’t we be embracing the idea of updating and revising the Agile Manifesto?
You could take the position that all of the books and blogs and seminars that have been produced since 2001 have turned the Manifesto into merely a historical document. But in practice the Manifesto is much more than a historical document. It is the first footnote or reference in most books, papers, and articles on Agile. Journalists and other media folk refer to it directly and often by URL all the time. As a result, many people read it.
It is perfectly reasonable for somebody new to Agile to assume that Agile Manifesto 1.0 is what we mean when we say “Agile” and that it will be one of their first stops on their trip to understanding Agile. New people read it every day. There are new signatories every day. Consider the impression that people have today when they visit the Manifesto and see a dusty web page that hasn't changed in seven years. Now consider the impression that people would have if they saw a revision history, a forum for proposing and discussing proposed updates, and the date for the next meeting to produce the next iteration of the Manifesto.
I personally have visited the manifesto at least 10 times in the past year including today to see if maybe it was versioned. It isn’t. Each time I visit the Manifesto I think “I’ve changed my thinking on this or that, am I ready to sign it yet?” The answer is still no. I realize now that one reason is that it doesn’t take its own medicine.
The idea for writing this post came as a result of participating in the proposal submission system for the Agile 2008 conference. There is a proposal to discuss revising the Agile Manifesto (account creation required). I have to say that the resistance to revisiting the manifesto is a bit shocking to me. It reminds me of many of the things that I thought that Agilists don’t like such as requirements documents that are set in stone, resistance to change, long iterations, rigidity, etc.
I can’t speak for others, but it doesn’t matter to me if I’m personally involved in the review and revision process itself. For me, it is about practicing what we preach and setting an example for those that are still doing traditional development or doing Agile poorly (in my experience most projects still fall into one of those two camps, unfortunately).
Let’s say the existing Manifesto is a historical document. Let’s enshrine it, put it behind glass, do some sort of ceremony etc. But to me, the fact that there is no version 1.1 or 1.0.1 or 2.0 or anything other than “the document” says to me that something is wrong here. Or conversely, creating a new version, regardless of the size of the change would be a good thing and indicate that we are in fact practicing what we preach.
For those that think it is futile or noise, why comment at all? Why does it matter? Worse case: the folks that want to see this happen go and waste their own time and the signatories say “we aren’t changing it.” So what? What’s the big deal? Is it somehow sending a bad message that some folks think that it is a bit odd that the Manifesto itself isn’t responding to change?
The treatment of this document as some sort of holy artifact feels to me like non-Agile thinking. It feels like a discussion that one would have with somebody about a giant standards document or process document. That reminds me, I did just hear such a discussion at Deep Lean in which somebody in the audience was saying “the coding standards document can’t change! It is a standards document.”
Let’s respond to change instead of following a plan. Let’s talk about if and how the Agile Manifesto should change to take into account all that the Agile community has learned since 2001 and set a good example for those that have not yet discovered the benefits of Agile. What do you think?
You may also be interested in a recent post on Deconstructing the Agile Manifesto.
No comments:
Post a Comment