I am writing a paper for the 2007 PMI Global Congress in Atlanta on Agile Transition.  Part of the paper covers the Agile Manifesto.  As I began researching and writing about it, I found that I had gaps in the historical data on the web.  I was fortunate enough to interview Jim Highsmith, Ward Cunningham and Ken Schwaber via telephone to get a better understanding of how the Agile Manifesto came about.  Here it is.

The Agile Manifesto (Beck, K., et al. 2001) describes a set of values and lists a set of subsequent principles (Beck, K., et al. 2001) that focus on a different way to build software.

In response to the popularity of heavyweight methodologies, such as RUP and CMM, in the late 90’s and early 2000’s, Dave Thomas, Robert Martin and Jim Highsmith proposed a working session to a group of follow lightweight methodologists. The group was comprised of 17 individuals, including Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas.

The working session organized by Dave, Robert and Jim had two objectives.

  • Each person will present to the group his lightweight method approach to building software
  • Discuss the surge of heavyweight methods and how to address them

The working session started with each person presenting his approach to development. As the presentations progressed through the day, a pattern began to emerge, but there was something in each presentation that was not aligning. It was the middle of the first day and people were becoming less focused. There were several informal breakout sessions occurring. A group of four or five individuals were working next to a whiteboard and one of them said “hey, let’s try a ‘this over that’ format and see what we get”. These people used the existing ideas that were written on the whiteboard and began re-writing the words in the new format.

After a period of about 15 minutes, four lines were written. The group had a lot of energy and others in the room began to notice. The rest of the people began coming over to see what was written. As each person read the four lines, they agreed – it was how each person felt. They had a unanimous decision that what was written was the alignment that was needed.

What was written was titled the Agile Manifesto. It states the following:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The group did not set out to create a document of common values and principles. They were the right people together at the right time and the Agile Manifesto was the outcome.

The following day, the group began work on the principles. The principles were refined over a period of two to four months. The principles state the following:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity--the art of maximizing the amount of work not done--is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

These words mean different things to different people and there is no right or wrong way to interpret them. The values and principles conveyed by the Agile Manifesto are simple, yet take a high level of discipline to follow.