The Manifesto for Agile Software Development was created by a group of like-minded developers at a Utah ski lodge in February of 2001. Calling themselves the Agile Alliance, the manifesto these developers put together summarized the core tenets of the Agile Development methodology. The Agile Manifesto goes like this:

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.

Kent Beck   James Grenning   Robert C. Martin
Mike Beedle   Jim Highsmith    Steve Mellor
Arie van Bennekum    Andrew Hunt   Ken Schwaber
Alistair Cockburn   Ron Jeffries   Jeff Sutherland
Ward Cunningham   Jon Kern   Dave Thom
Martin Fowler   Brian Marick

© 2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.

Individuals and interactions over processes and tools

A scrum dashboardWhile processes and tools are great, a lot of development outfits tend to overemphasize the processes and tools. Put your development into the hands of individuals and allow them to interact to get the software done. Ask your development team what they think of the project in question, how they should get it done, and how much they believe they will be able to get completed in bite-sized chunks (sprints). Then, allow them to use the processes and tools that they find most effective to completing the job.

Working software over comprehensive documentation

A lot of companies tend to over-document before even touching a line of code. The Agile Manifesto indicates that it’s better to create working prototypes of software rather than to over-document before hand. In this manner the needs of the user will come out over time – before the code base of a project has been developed to such an extent that it is too late to make changes to the infrastructure.

Customer collaboration over contract negotiation

Instead of having an us-versus-them process of negotiating the finer points of a wordy contract, a development effort should be a collaborative effort between the developing organization and the client. Agile favors the discovery of the “final needs” over time, by developing working prototypes of software programs, over demanding that the client has a complete 100% understanding of their needs before a line of code is written. The customer and the developers should work together to come up with the right software to meet the client’s needs.

Responding to change over following a plan

Microsoft Project is a great tool for creating huge, complicated waterfall project schedules. However, Project may not be the best tool to use in an Agile Development software project. Agile projects need to be able to adapt to change, and therefore should not be planned out to the letter months in advance in a waterfall-like schedule. With such schedules changes tend to be feared and protested; in Agile Development, changes should be expected, welcomed and understood.

Using the Agile Manifesto

The Agile Manifesto is more than snappy prose; it indicates a way of thinking when developing software. If you’re an Agile shop, regardless of your methodologies and how you adapt them to your needs, when subjecting your development team to a change in process or even your corporate culture you should ask yourself: Does this change line up with the Agile Manifesto? Are we adding too much documentation – or even too much process – to our practices?