The Manifesto
The Manifesto for Agile Software Development, commonly known as the Agile Manifesto, is very concise. Here is the full text:
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.
A group of well-known software architects wrote the Manifesto to describe their priorities when building software systems. Many were book authors and bloggers, and all had experience designing complex systems.
Its simplicity is its strength. One can memorize it and apply the principles to their current work, adapting their processes as needed.
It also benefits from its flexibility. The Manifesto doesn't proclaim dogma; instead, it states the relative importance of software development concepts.
The Principles
Individuals and interactions over processes and tools
Processes and tools are important. But do not lose sight of what you are trying to accomplish. Communication between individuals and teams is crucial to building anything of moderate complexity. Tools and processes are simply a way to facilitate that communication.
Working software over comprehensive documentation
This is the most obvious of the principles. I am a big fan of documentation. It helps users understand how to use software, and it helps onboard new developers. But let's face it. Given a choice between broken software with excellent documentation and excellent software with no documentation, the former is the better choice.
Customer collaboration over contract negotiation
This principle rejects the idea that software developers and their customers are adversaries. They have the same goal - creating quality software - and they should drive toward that goal together. The parties involved are less likely to point fingers and place blame if they view their relationship as a partnership.
Responding to change over following a plan
This is the most revolutionary part of the Manifesto. Before the development of Agile methodologies, Waterfall was a popular methodology for designing and building software. In a Waterfall system, all design is completed before writing any software, and all software is written before testing it. This approach was slow, expensive to fix, and did not consider changing requirements. This principle encourages teams to break work into short "sprints" and frequently evaluate what tasks belong in each sprint. This principle makes it much cheaper to adjust to changing requirements.
Conclusion
Many books describe methodologies with specific actions to take to become more "agile." But these are just applying the principles above. How you implement these principles is up to you. Daily standups, 2-week sprints, and pair programming can help make you more agile, but they are not required to adhere to the Agile Manifesto.