Unlike waterfall, which seeks to control and constrain the realities of software development, agile methodologies embrace them. Change in business is inevitable, and software development methodologies must be able to adapt. A key failure of the large up-front plan is that estimates by their very definition are always wrong. If they were correct, they wouldn't be estimates; they would be “the number.” An iterative process shows promise, but the iterations themselves, and the methodology as a whole, must be flexible and open to change.
In February 2001 several proponents of new methodologies such as Scrum, Extreme Programming (XP), Pragmatic Programming, Feature Driven Development, and others met and drafted the Agile Manifesto. It reads as follows:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
That is, while there is value in the items on the right, we value the items on the left more.”
The Agile Manifesto itself is not a development methodology. It doesn't prescribe how software should be developed. It simply states a set of key values that can be used to create and describe lighter and faster application development ...