The Agile Manifesto Revisited

The writing of the Manifesto for Agile Software Development was a watershed moment. We didn't know that at the time, of course, although there were a number of prolific authors in the group. The rapidity with which people around the world undersigned the manifesto on the web site surprised me. Even more surprising was that within six months conferences already had panels on the subject. In 2006, I saw "requiring an agile approach" written into a co-source agreement between two very large companies, and the Software Engineering Institute was developing ways to help its examiners evaluate agile projects.

Many people ask what it was like to write the manifesto and, in particular, what our meeting process was. I'll offer my own personal observations of that meeting, why it was unusual, and perhaps why it worked. There isn't need or space to go into great detail, so I shall just pick out what has seemed in the light of subsequent experiences to be interesting observations.

Bob Martin called the meeting, saying, "Is it just coincidence that so many of us are saying things that sound alike?" He added that he was interested in writing a manifesto. (I, for one, was completely uninterested in writing a manifesto, so the reaction to the manifesto was perhaps more surprising to me than to him.) Bob invited a wonderful set of people to the meeting, proponents of the "lightweight process" view as well as some others. Noticing that we had people only from North America, we asked for a representative of the UK-based DSDM consortium to be present. Ari van Bennekum flew in from Holland just for the meeting. We ended up with representatives for XP, Scrum, Crystal, Adaptive, Feature-Driven Development, DSDM, and generally light and pragmatic development (Andy Hunt, Dave Thomas, and Brian Marick).

After the round of "Hello; Who Am I?" we sat around and stared at each other for a minute, and someone said, "How do we make an agenda?" Someone suggested writing agenda items on index cards, and because the XP people in the room of course had index cards in their possession, they immediately pulled some out, started writing on them, and threw them into the center of the floor. Suddenly there was a critical mass of people casting index cards onto the floor. The rest, whatever they thought, started doing the same, until we ran out of ideas and had a pile of index cards on the floor.

Someone asked, "How do we organize those cards into an agenda?" Someone said (you will notice that by this time, I had already lost the ability to note who was suggesting what), "All those who care about the order of the agenda, sort them out, and the rest can leave us to it." Because I didn't care about the sequence of topics, I took a break. When I came back, the index cards were being taped to the wall.

Later, someone said, "I just thought of another agenda item. What should I do with it?" Someone answered, "Find the place in the agenda you'd like it, and put it there."

I spend time on all this because two things strike me as very significant about this group so far:

• Respect. There was enormous trust in the room of each person for each other. No one tried to hijack the meeting; everyone listened very closely to every other person, giving at all times greatest credence to what that person was saying.

• Self-organization. This was self-organization of the highest caliber. Under other circumstances I have been in, one person, or worse, multiple people, have tried to "run" the meeting. With senior people in the room, many of whom don't know the others, it is easy for a power struggle to show up in the first minutes. That never happened.

We spent time on a round of "What am I recommending, and what do I stand for?" by way of introduction. I noticed that each of our processes, when described in only 15 minutes, seemed strange to some of the others in the room.

We quickly decided that it was not an accident that our recommendations sounded so similar, that there was something underlying that similarity, and that we should discover what it was. The reason this is important to mention is that we disagreed back then on how to run projects on a day-to-day and minute-by-minute basis, and we disagree still. Notwithstanding those disagreements, there is a very strong commonality that separated thenand still separatesour views from many others.

Someone said "I don't like the word 'lightweight'; it doesn't sound like we're serious." Someone else said, "Lightweight is a reaction against something. I want a word that stands for something." So we spent an hour searching for a tag word to capture what we were after.

I found the process of doing that word search interesting:

• First, we brainstormed 20 or 30 names and wrote them down.

• Second, we picked out a few names and discussed for each why we didn't like it.

The latter tactic helped us understand what we stood for and what we stood against. Writing down why we didn't like a word didn't disqualify the word; it merely helped us understand what was inside our heads.

For example, for one word, an objection was, "I'd have to be wearing pink tights to say that word. I refuse to wear pink tights." We were looking for a strong word to match Musashi's "Whatever guard you adopt, do not think of it as being on guard; think of it as part of the act of killing" (or, for us, delivering a useful system).

Agile development is aggressively delivering what is needed, not merely avoiding paperwork. Hence my selection of the Bengal tiger for the cover of this book, as opposed to a gymnast or a dancer. My other agile mascot is this wicked-looking deep-sea monster I found on a T-shirt.

Figure A.1-1. This T-shirt shows my favorite agile mascot. (Photo with and courtesy of Jonas Kongslund.)

Both the tiger and the deep-sea monster look certain to eat dinner. They are not merely avoiding paperwork or practicing flexibility.

• Third, having clarified our thoughts, we voted for our top three words and ranked the results.

• The top two words were agile and adaptive. We had a round of discussion and a final vote, settling on the word agile. As I mentioned earlier (p. 266), although adaptive has certain advantages, agile is the word we were looking for at the time. These days, we expect our methodologies to be both agile and adaptive.

Then someone said, "Well, now we have a word. What stands behind it?" What followed was interesting. Lunch was served, and various people sat in front of the whiteboard, discussing ideas. The space in front of the whiteboard was too small for all 17 people, so people moved in and out, intermixed with eating lunch. Somewhere along the line, someone suggested contrasting this against that, and the value comparison showed up. Someone else suggested that it had to be a more or less fair value comparison so that people could disagree meaningfully on one value at a time.

When it took shape, we sat in front the whiteboard and wordsmithed it. Anyone could say why they couldn't support a particular wording, and we worked to understand their view until someone came up with a better wording. When we were done, each of us could sign for the full manifesto without reservation.

Having the name agile and the four value statements, we then moved to create the 12 principles. Here is where things started to break down, because it is at this level that the individual differences start to show up.

For example, does the customer or user have to be there daily, or is weekly good enough, or perhaps some mix of hours per week plus being available for questions? Should we write that the system gets deployed daily, weekly, monthly, quarterly? Is self-organization the crux of the approach, or is management allowed to play?

Compounding these complications, it was getting time for people to get on planes (we budgeted only two days for this whole thing, after all). When people started to leave, we recognized that we would not be able to get closure on finer-grained recommendations. This is, indeed, what happened.

Someone pointed out that we still wanted to be able to disagree at the detail level because we were all still exploring development methods. To use the term precision (p. 158), we agreed with each other on precision level 0the single catch-phrase agile. We agreed on precision level 1the four values. We (barely) agreed on precision level 2the 12 principles. We agreed to allow ourselves to disagree at the next level of precision.

Finally, we reviewed why we had been able to cover so much territory so quickly. The answer was right in front of us: We had paid attention to individuals and interactions, we had worked face-to-face, we had worked collaboratively, we had focused on our product. In other words, we had just lived what we had just written.