Agile Versus Waterfall?
The Pros and Cons of Agile and Waterfall
Waterfall (V) Model:
Waterfall (1) projects go through a number of sequential or overlapping phases. This defines the life cycle of the development effort of the project. The principal difference with Agile is that in Waterfall, requirements are defined near the start of the project. Then they may be subject to change control through all the following phases.
Waterfall was adapted from Engineering. On large-scale physical projects, design is usually a critical activity and the impact of changing the design after it has been approved (on cost and schedule) can be very significant. This is why requirements must be addressed before the design is produced, hence sequence and phases.
Some people state incorrectly that in Waterfall if an error is found in the later stages of a project, it will need to be scrapped and started again. While this is not impossible, it would have to be a very significant issue to cause this level of impact. In truth, this will only occur if there is very poor control of a project.
It is also not true that Waterfall projects never involve iteration or feedback. They certainly can but some project teams choose not to.
Agile itself is not a PM framework and it is not a “methodology”. It is a set of principles and values relating to product development, specifically producing software (2). There are, however, methods based on Agile principles, and these are Product Development methods, not project management frameworks.
The biggest difference between Agile and Waterfall is that typically in Agile the deliverable is produced and accepted incrementally, around short iterations or equivalent (usually 2-4 weeks). Also, using Agile, requirements are normally confirmed within each iteration, rather than at the start of the project in a single requirements phase.
Prior to this, higher-level items such as features will usually be identified. These will then be broken down into discrete items to be fully defined and developed within iterations.
One key aim of Agile is to try to retain as much flexibility as possible throughout the development cycle.
Certain types of projects will never suit a truly Agile approach. For example, if the main project deliverable cannot be defined, produced (and accepted) sequentially and incrementally, it is unlikely that the core of Agile can be used.
However, any project can benefit from some of the practices commonly found in Agile, notably communication.
Clearly, the two approaches are very different and will have completely different pros and cons.
So let’s look first at Agile:
|Agile promotes some of the best practices found in development environments. Some of the risk in a project should be reduced as the output of developers is reviewed early and constantly during development.
|Agile is simple to understand in principle but hard to do well in practice. It requires real commitment and first attempts are not likely to go very well.
|When projects are genuinely new they usually require creativity. Requirements can then emerge as understanding matures and grows.
|It is less predictable what will be delivered at the end.
|Flexibility can be higher than traditional methods - although this is not guaranteed. Changes (e.g. in prioritisation) can be introduced at almost any stage.
|Agile requires high levels of collaboration and very regular communication between developers and users (e.g. Product Owner). This is always desirable but may not always be feasible and requires continual commitment and time from the business and developers.
|Agile encourages or requires frequent communication between developers and those who will ultimately accept and use the deliverable. This should pay major dividends when effective. For example, feedback can be incorporated into future iterations as increments are delivered and reviewed by users or a Product Owner or both. False assumptions made by developers can be recognised very early reducing impact. Agile gives us continual opportunities to learn via this feedback.
|Agile is very intensive for both developers and users. There can be reasons that may prevent this for example if developers work on multiple projects at one time.
The only downside to the opportunities to learn is that people have got to be prepared to.
|It should reduce the 'silos' that too often exist within project 'teams' - something that always damages projects (as it should result in a collaborative style of working).
|There can be less of a blueprint of what the final deliverable will be. This can make it harder to gain commitment to the project by stakeholders at the early stage.
|It should result in far less re-work on projects as issues and changes should be picked up much earlier.
|Agile can be challenging when there is a supplier-customer relationship. Customers typically want to know what they are getting for their money as early as possible. It can be far harder to estimate timescales and costs as there is less 'definition' to base estimates on.
|Collaboration is usually much higher with Agile. Although not guaranteed, this can result in more successful development environments, in terms of product quality (i.e. fit for purpose).
|Agile can be very challenging on much larger projects or where co-location is not possible (between developers and the business).
|With the common use of visuals, (boards, charts, Kanban etc) it can be easy to see what is going on (literally) what is done and what is yet to do, assuming the visuals are well organised, presented and up-to-date. This in itself can be a major benefit.
|In Agile there can be a great reluctance (by some) to adopt or accept deadlines. Projects don't exist in isolation so when this happens it can be a real issue. Agile methods typically only address the product development and large-scale projects can be made up of many other elements.
Other obvious examples where Agile methods are not typically strong: dealing with lead times and major dependencies.
And now Waterfall:
|On well managed projects Waterfall may provide more confidence of what will finally be delivered earlier in the life-cycle.
|Many organisations and people really don't find defining requirements (up front) easy to do - especially early in some types of projects. The assumptions upon which early stage plans are based may be very flawed and too often are taken as being based on certainty.
|Project team members don't need to be co-located although the risks associated with this must be managed carefully.
|Communication can be a far higher risk - especially when there is limited early review of outputs and deliverables or when one-way methods of communication are used to convey requirements.
|Where large-scale design or analysis is required, or the impact of downstream changes to design is very high, this is likely to be a far more suitable approach.
|Risk in general can be far higher with Waterfall, for example as the scope for invalid assumptions is unlimited. If you add this to the high cost of making changes later in a Waterfall project, it is easy to see why some are very expensive, over budget and late. Too often, assurance of products being fit-for-purpose is demonstrated very late in Waterfall projects.
|Where there are many interfaces and dependencies outside of the basic product development, waterfall projects tend to have the tools to model and manage these.
|Waterfall projects don't have to be but tend to be made up of 'teams within teams'. This can be a major disadvantage to any project.
Summary and Conclusions:
Agile and Waterfall are very different and it will not always be possible to choose between them both. Waterfall could be applied to virtually any type of (IT) project. Agile requires specific conditions to be in place to be possible but is not applicable to certain projects – especially those of a large physical nature. Most of the conditions for Agile to be possible relate to the working environment and practices that can/cannot be employed by the whole project team. Not just those responsible for product development. There also needs to be flexibility around requirements together with the capacity to deliver and accept products incrementally.
1 – The term “waterfall” is used liberally and many would say incorrectly to describe all non-iterative (i.e. predictive) forms of project management frameworks. Waterfall, as defined in 1976, is a (rarely used) software development framework. However, the central principles of Waterfall (i.e. sequential/overlapping phases) were borrowed from Engineering. Therefore there is a clear parallel between IT development methods that follow a Waterfall type of approach and many physical and engineering projects, which still do to this day and will continue to do for a long time to come, due to the physical nature of those projects, meaning some things have to be done in sequence.
2 – We say “mainly software” as there are few types of projects outside of the software domain where the deliverable can truly be produced and accepted sequentially and incrementally or where requirements can evolve within the development phase. A phased delivery of any project does not mean it is Agile (despite some claims that it is). It is simply a phased delivery.