Traditional software project used a waterfall approach. In this scenario, project stages come one after another... ie, analysis then design then development then test then deploy - and the stages cascade like a waterfall. The further the project is through the phases, the more expensive it is to change direction. But business environments can change quickly these days. New regulations may necessitate a price change; a competitor may catch you off-guard; a window of opportunity may open up. In today's business climate you cannot wait six months for an existing project to finish before you address the change. And if your software approach doesn't support emerging requirements and change then you may fall behind the competition.

Agile is an umbrella term for a set of software management and software engineering disciplines. Agile has emerged as an alternative to the traditional waterfall based software management. Rather than a single project consisting of cascading phases — analysis, design, development, test, then deploy — agile adopts an evolutionary approach. 1-4 week 'mini-projects' are undertaken in order to incrementally build the required solution. The agile approach is built upon the guiding principles of continuous feedback from the customer, face-to-face communication, short daily status updates, simplicity, and team member 'commitment' rather than 'involvement'.

It's actually quite simple. At the beginning of each development cycle, the team takes the highest priority items from the business customer's list of requirements. Since the development team are only committed to the requirements in their current cycle, the business customer and others are free to add, remove, and reprioritise the remaining requirements as they see fit.

On most software development projects, certain tradeoffs need to be made. There are countless best practice standards and engineering techniques that can be applied during development, and there is sometimes a tendency to apply all of them. Application of these standards and practices cost time and money; therefore it is important to ensure that developers do not over or under-engineer the solution in regard to engineering techniques, architecture, aesthetics, and documentation.