In February 2001, at the Snowbird resort in Utah, 17 software engineers met to discuss lightweight development methods. The result of their meeting was the following Agile Manifesto for software development −
We are uncovering better methods of developing software by doing it and helping other people do it. Through this work, we have come to value −
- Individuals and interactions over Processes and tools
- Working software over Comprehensive documentation
- Client 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.
Customer Satisfaction − Highest priority is given to fulfill the requirements of clients through early and consistent delivery of valuable software.
Welcome Change − Changes are inescapable during software development. Ever-changing requirements should be welcome, even late in the development stage. Agile processes should work to increase clients' competitive advantage.
Deliver a Working Software − Deliver a working software frequently, ranging from a few weeks to a few months, considering shorter time-scale.
Collaboration − Business people and engineers must work together during the whole life of a project.
Motivation − Projects should be built around motivated people. Provide an environment to support individual colleagues and trust them so as to make them feel responsible to get the job done.
Face-to-face Conversation − Face-to-face conversation is the most proficient and effective way of conveying information to and within a development team.
Measure the Progress as per the Working Software − Working software is the key and it ought to be the primary measure of progress.
Maintain Constant Pace − Agile processes aim towards sustainable development. The business, the engineers, and the users should be able to maintain a consistent pace with the project.
Monitoring − Pay regular attention to technical excellence and good design to upgrade agility.
Simplicity − Keep things basic and use basic terms to measure the work that isn't finished.
Self-organized Teams − An agile team should be self-organized and should not depend heavily on different teams because the best architectures, prerequisites, and designs emerge from self-organized teams.
Review the Work Regularly − Review the work done at regular intervals so that the team can reflect on how to become more effective and adjust its conduct accordingly.