Agile methods significantly differ from the traditional waterfall-like methods. Agile teams don't need a half a year of requirement analysis and design before the coding phase, most of the tests are written by programmers and are automated, customers are asked to participate, try live software and provide feedback frequently. All these peculiarities as well as inability to commit to the concrete set of deliverables early sometimes make agile methods look fluid and unpredictable - something not valued by the business people.

However, agile methods have a reason for not committing to the end result in the beginning of the project. And the reason is a simple fact - despite all the possible analysis, it is virtually impossible to predict the final desired content in the beginning of the project. It is well known, that during the course development both customer wishes and customer business environment often change a lot and initial plans and requirements are not relevant up to the point, when much less, than half of software features are relevant. No thoughtful and profound analysis can produce as good requirements as one can iteratively get from the customer feedback on the already running software.

Agile methods recognize the poor ability to plan software one year ahead and approach the problem by building the software in completed, finished and ready for usage blocks starting from the blocks of the highest value to customer. The frequent "completeness" of software gives a significant business advantage of, namely, agility. Whenever the customer desires or financial situation change, the development course can change accordingly. Whenever the release is forced (e.g. by the competitor) to be made, it can be done. Whenever it is discovered that developers got customers desires wrong, the corrective action is applied the next month.