Wednesday, March 05, 2008

Updating the Agile Manifesto is Required by the Agile Manifesto

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.

4 comments:

Rob said...

I think you misunderstand the meaning of a manifesto. The Agile Manifesto, like all manifestos (manifesti?), is intended to be a concrete statement, a line in the sand, a rallying cry. It's not a "this week we think this, next week we might think something else" kind of document.

Supposing you did change it. What would you do with all those signatories? You can't claim that they signed up to the manifesto you've just published - they didn't - so you'd have to start again and ask them to re-sign having read the changed document. Not only would this be a logistical nightmare even in cyberspace, you'd then have people discussing their views with respect to different versions of the Agile Manifesto "I was a signatory up to version 1.103, but after that they got too specific about TDD" vs. "I didn't sign until version 2.0, which was the first version that stated you can't have a hierarchical team strucutre" - are these two people Agile, or not?

The only way is to keep it simple and unchanging. The Agile Manifesto not only does not need to be "versioned", it SHOULD not be versioned. By all means, if you think there's something missing, then post your own manifesto up and ask people to sign up to that.

Damon Poole said...

Hi Rob,

I'm not sure that google would completely agree with you that Manifestos don't change, but it could certainly be argued that Manifestos tend to change less than other types of documents.

In fact, I think you've sort of added a point to my argument. Perhaps calling the document a Manifesto was not (in retrospect) the best term to use for a document intended to promote a way of thinking that is all about embracing the idea that requirements frequently change.

No matter how you slice it, I find it kind of funny to be having a discussion about how I misunderstand that a document about embracing change is not supposed to change. :-)

As to your question about the logistics, I'm not really sure how to respond. You seem to be arguing that even if changing the document was the right thing to do, it shouldn't be done because it is too hard to do.

The only thing I can think of to say on the subject of the logistics is that revising important documents is managed quite successfully on a regular basis by many people for many documents. I'm not sure why this document is somehow different in that regard.

bjorng said...

How would you like to see the manifesto change? To my mind it's too succinct and spare to change much without completely altering its meaning, or making it harder to understand. As it is, people often mistake it for a rejection of the "things on the right", even though the last sentence specifically indicates they're valuable.

Anonymous said...

You raise an interesting point, and I find it a bit troubling because it reinforces my own concerns. I agree with the general principles of agile development, and I find them quite useful in my work. However, my interactions with the authors and proponents of the manifesto have left me feeling as though I had engaged in a religious debate. I get the sense that these individuals are so wedded to their views so as to be totally closed to anything different. It is thus not surprising that they would be against changing their principles. After all, if something is free to change, it implies it may be wrong.

I'm reminded of the philosophy of Karl Popper. I'm paraphrasing, but he essentially said that science is that which lies between contradiction and tautology. The former is illogical, and the latter is bigoted.