The Pros and Cons of Agile and Waterfall
Waterfall (V) Model:
(click to enlarge)
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 and then may be subject to change control through all following phases. A “Waterfall” type of approach is common on major projects especially in large-scale engineering projects where physical design is a critical activity itself and the implications or cost of changing the design will be very significant.
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 is not a PM method – it is an approach to delivering mainly software (2) projects. The biggest difference between the two is that typically in Agile the deliverable is produced and accepted incrementally, around short iterations or equivalent (usually 2-4 weeks). Additionally, requirements are normally developed around each iteration, rather than at the start of the project in a single requirements phase. One key aim of Agile is to retain as much flexibility as possible throughout the development cycle. Certain type of projects will never suit a true Agile approach. For example, if the main project deliverable cannot be defined, produced (and accepted) incrementally, then 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.
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 commitment and time from the business.|
|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.||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 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 chose 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. Most of these conditions relate to the working environment and practices that can and cannot be employed by the whole project team, not just those responsible for the development. There also needs to be flexibility around requirements together with the capacity to develop and deliver product 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, was intended for software development. However, the central principles of Waterfall (i.e. sequential/overlapping phases) were borrowed from Engineering and 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 do for a long time to come.
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 incrementally or where requirements can evolve throughout the development phase. A phased delivery of any project does not mean it is Agile (despite the claims by some that it is). It is simply a phased delivery.