There are structured stages, in a specific order.

       The Waterfall model is familiar to many, it has been around for a long time.

       The Waterfall model is sequential, one stage is completed before moving to the next, and there are often gatekeepers at each stage.

       Documentation is produced at every stage of the product’s development.

       Developers and customers agree on what will be delivered early in the life cycle which should make planning, monitoring and design easier.

       Progress should be more easily measured, as the scope of the work is known in advance.

       Requirements should be fixed and complete before production begins; this could involve a lot of time spent up front before any lines of code are written. This could be problematic for systems that have a specific delivery date, time limit or fixed price contract.

       Rigidity of requirements and therefore of the product being built. Because the requirements are gathered ‘up front’ any changes needed may be difficult to add later.

       Changes to requirements may cause confusion, wasted effort or a project restart.

       The working software can only be seen at the end of the process. This means that if there is a change in business practices or a fundamental change needed in the way the product works it may not be spotted until right at the end.

       The product is unknown to the customer until it is delivered at the end. This means that feedback from the customer is not received until the product has been built, meaning that changes will be more expensive to add.

       There can be a lack of visibility – teams don’t realise they are behind schedule until later in the life cycle.

       The amount of time given to the later stages (e.g. testing) is often squeezed by overrunning timescales in earlier stages.

       Emphasis on getting information right up front, which puts pressure on people to decide early and to remember ‘everything’ they want in the new product in the beginning.

       Projects that require fixed stages and deadlines, accountability or legal auditing.

       Short, simple projects where theoretically, little can go wrong.

       Projects with changing project teams that depend on extensive documentation.

       Projects with stable, known requirements, for example, projects that may have been done before, where chances of surprises or changes during the development process are relatively low.

       Projects where change is complex and expensive: this could be because a change may result in a large amount of wasted time, work or money or because a change of direction would not be possible, for example if the hardware had already been bought and installed. This is distinct from Agile projects which are designed to deal with changing requirements. If change is complex or expensive the project will not allow deviations from the original plan, requirements or design.

       Early and continuous delivery of valuable software.

       Welcoming changing requirements, even late in development.

       Delivering working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

       Business people and developers working together daily throughout the project.

       Building projects around motivated individuals. Giving them the environment and support they need, and trusting them to get the job done.

       Conducting face-to-face conversation as the most efficient and effective method of communication.

       Using working software as the primary measure of progress.

       Sponsors, developers and users maintaining a constant pace indefinitely.

       Continuously paying attention to technical excellence and good design, which enhances agility.

       Working with simplicity in mind – the art of maximising the amount of work not done.

       Utilising self-organising teams, from where the best architectures, requirements and designs emerge.

       The team reflecting, at regular intervals, on how to become more effective, then tuning and adjusting its behaviour accordingly.

       Rapid and flexible response to change. In a dynamically changing business world, being able to change direction or deliver products before your competitors may be the difference between survival and closure.

       Timely and regular delivery of business value through short sprints (these are the time-boxes in which development takes place).

       Feedback from stakeholders and the team developing the system.

       Collaboration among stakeholders and system development team.

       Prioritised functionality, meaning the features that are most important are delivered first. This can be particularly helpful if the product is part of a trial or a prototype.

       Adaptive software development (ASD), created by Jim Highsmith.

       Agile modelling, created by Scott Ambler.

       Dynamic systems development method (DSDM), created by the DSDM Consortium.

       Extreme programming (XP), created by Kent Beck, Ward Cunningham and Ron Jeffries.

       Feature-driven development (FDD), created by Jeff De Luca.

       Kanban (development), created by David J. Anderson.

       Lean software development, created by Mary and Tom Poppendieck.

       Scrum,