Writing The Agile Manifesto
In February 2001 a group of seventeen software pundits got together in Snowbird UT to discuss the growing field of what used to be called lightweight methods. We decide to use the term agile to describe this new breed of agile methods. We also wrote the Manifesto for Agile Software Development , setting out the values and principles of these agile processes. I was one of these self-elected visionaries and have since come across many questions about this group's origins and the subsequent founding of the agile alliance. This is my recollection of those events.
09 July 2006
I can fairly accurately ascribe the origins of the Agile Alliance get together to a retreat held for various leaders in the Extreme Programming community in the Spring of 2000. Kent invited a bunch of active XPers to his rural part of Oregon to discuss various issues in XP. As well as confirmed XPers he also invited a number of people who were interested but separate to XP: such as Alistair Cockburn, Jim Highsmith, and Dave Thomas.
At the meeting we discussed the relationship between XP and other methods of a similar ilk - at the time referred to as Lightweight Methods. We agreed that XP was best as a specific process: "a stake in the ground". We also agreed there was a lot of common ground between XP and some of these other methods. As a result of this (Uncle) Bob Martin decided to try to put together a meeting of people interested in this broader range of methods.
A wide range of people were contacted, basically whoever we thought was interested and active in this field. I'm sure we missed some people who would have been interested and valuable had they come, but we did try to cover as wide a ground as we could. After much discussion we settled on a meeting at Snowbird Utah from February 11-13 2001. Several of the people who were keen to come couldn't make it - in the end those that did were the 17 whose names appear on the manifesto.
The Snowbird Meeting and the Manifesto
We came to Snowbird with limited and varying expectations. Mine were very limited - I just hoped that we would get to know each other better and that greater communication would lead to something interesting, although I didn't expect much at that meeting. I've gone to small retreats like this (such as the WOOD series in Snowbird in the mid 90s) and found them very valuable. Contacts are made that turn into all sorts of stuff. Indeed I first got to know many people at those WOOD retreats, and without them would probably not found myself part of the birth of XP.
We actually found that we quickly had a lot in common and agreed on many important aspects of software development. So we decided to go further than just talk. We liked the idea of writing a document that would both capture the common ground we felt we were discovering and act as a rallying cry to the software industry.
The first part of this was to find a good name. Informally the various methods we used had been called "lightweight methods". Few of us felt that was a good name. Some saw it as vaguely insulting, but all of us felt that it missed the point. Light in weight wasn't the point of these methods, it was just a symptom - as I've argued in The New Methodology.We considered a bunch of names, and agreed eventually on "agile" as we felt that captured the adaptiveness and response to change which we felt was so important to our approach.
It's important to remember that we have no copyright on the word "agile". I've seen a few people write articles saying that agile methods aren't really agile according to some definition of the word agile. Naturally this is true, like Humpty Dumpty we've appropriated the name agile to describe what we do - and certainly that isn't the only use of the word agile. But we need some word to describe the common views that we hold, and felt agile was probably the best to go with.
The next part was to write the document. We decided to call it a manifesto since it was a call to arms and a statement of our beliefs. We worked primarily on our statement of values during the meeting and I'm very pleased with the result. I think the values really capture the core of the ideas that we shared during the meeting.
In the latter part of the meeting and in the following couple of months we worked on the principles. Once we were separated progress was much slower but we did find a good combination of emails and wiki to do the job. I don't think the principles have quite the same punch as the values - but they are still a good record of what we stand for.
Since Ward (the inventor of the wiki ) does a lot with web servers, he volunteered to set up a web presence for the manifesto. He got the domain name agileAlliance.org which we used to originally publish the manifesto, although it was later given to the agile alliance. The manifesto site holds just the manifesto itself, a short article by Jim Highsmith that gives some background, links to the authors, and a place for people to sign up their support.
The manifesto is a rallying cry: it says what we stand for and also what we are opposed to. Several items were worded to clearly make a distinction between our views and that of many others in the software industry. I think this is important to get past the fuzziness that has clouded so many things in the last few years. I've seen the terms incremental and iterative abused into all sorts of strange project shapes. I hope the manifesto will make clear what is and isn't agile.
An on-going organization
There is nothing particularly special about the seventeen of us who happened to be at Snowbird. We aren't the only people to share the values and principles that we wrote about in the manifesto. We all expect to be working hard in the next few years to promote these principles and values, both through the specific processes and with a broader agenda. However we don't have any special status in the this movement, and no desire to set up ourselves for a such a status.
Most of the seventeen had our first opportunity to get together again at OOPSLA 2001. The meeting, which involved quite a few others who are interested in agile development, made it clear that the seventeen manifesto authors had "launched the ship", but saw no reason to have any special say in agile software's future.
However several people, both amongst the seventeen and new additions, wanted to see a more permanent organization set up. So in late 2001 they formed the Agile Alliance as a non-profit organization to act as a center for furthering agile methods. You won't be surprised to find that the arrangement of the Agile Alliance is very chaordic. All work in the alliance is done by programs that run very independently. There is a board which oversees the programs at quarterly intervals, but other than this checkpointing mechanism the programs have a lot of independence as to what they do.
Since then the Agile Alliance has developed into a stable on-going organization that organizes a bunch of work to promote and understand this new field. The showcase of this work is the annual agile conference. Anyone can join the alliance, subject to a membership fee, and membership allows you to elect the board who run the organization. I served (unelected) on the very first board to help start things off but since then have kept out of the way - I'm allergic to boards. Indeed one of the good things about the agile alliance is how much the leadership has spread far beyond the seventeen authors - a good endorsement of our decision to just 'let the ship sail'.
Agility and ThoughtWorks
You may wonder how agility fits in with our work at ThoughtWorks. My take on it is that the basic essence of agility was deeply embedded in ThoughtWorks's corporate culture from the beginning. That's a large part of what attracted them to me and vice-versa. The manifesto was well received at ThoughtWorks because it's something public that explains these values. Over the years our agile DNA is strengthened as we've naturally come to attract people who want to work in an agile way. We've also developed more experience in using agile methods, as I like to say, we've made more mistakes than most anyone else. We prefer to do all our work in an agile manner, a desire that's often constrained by our clients, although increasingly we tend to try and only do work when clients will let us use the approaches we've found successful. We also have many clients that specifically engage us because of our agile expertise, often because they want us to teach them about agile working.
Having said that, we don't like to think of ourselves as an 'agile consultancy'. For us agile methods are the way we like to work, but not really the essence of what we're about. If we discover a better way to work, we'd adopt it. It's just that, thus far, agile methods seem the best way for us to build useful software.
For articles on similar topics…
…take a look at the tag:
09 July 2006: Changed the title to "Writing the agile manifesto", added links to other accounts and other minor changes.
July 2006: Some minor updates
February 2002: Talked about the forming of the Agile Alliance non-profit.
November 2001: Updated section on future
August 2001: Updated section on future
June 2001: Initial Publication under the title "The Agile Manifesto: where it came from and where it may go".