Agile Versus Waterfall?
The Pros and Cons of Agile and Waterfall
Agile and Waterfall (1) are potentially two very different ways of delivering projects. Firstly we will describe them both and then compare their respective advantages and disadvantages.
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:
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:
| Pros | Cons |
|---|---|
| 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:
| Pros | Cons |
|---|---|
| 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.
Notes:
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.
Share this:
20 Comments
Leave a Comment
Contact Us Now
EMAIL us today.
Or call ++44 (0)1865 784040
Terrific article with practical, objective insights..! It’d be great at some point to learn about any examples where you/PMIS have had success in combining principles from both waterfall and agile into a workable approach for a large capital-intensive (e.g. non-software/IT) project. In my experience, even the most progressive of companies (large or small) often have trouble leading cross-functional work to a successful outcome. Certainly there are many factors on a situational basis that contribute to success, but I suspect a hybrid waterfall/agile approach can have an outsized positive impact in many circumstances. Keep up the effort!
Dennis – many thanks for your comments. Yes we have worked with large-scale engineering companies who have adopted cross-functional teams with great success, in some cases. The industry/end product will dictate to some degree how close they may get Agile but that is not the key question. The key question is to speed up development and reduce risk, re-work and issues.
Kevin Thanks for sharing this page. Its a wonderful explanation.
Very well written easy to understand explanation.
Thanks for sharing.
– You can have a waterfall methodology/project without using requirements.Requirements is not an obligatory technique.
– Once the Analysis is done requirements are supposed to be rather stable. The purpose of the analysis is to come to a good insight in the problem and a defined solution. After that, it should be stable. However, we can never exclude a subsequent change. If a change occur later in the project, usually they are rather minor changes… not big influence on project anymore.
But indeed, a lot depends of the quality of the analysis.
– There are techniques like proof of concepts, prototypes, mock-up screens and so to represent the product in early stages of the project.
– Waterfall projects “fail” because estimations of time and budget are done early in the project and not reviewed during the project. This is a project management issue. Normally, better estimations should be done after the design phase. Then the product is known.
You can find more about the waterfall here: https://goo.gl/bDI5Z1
Axel – thanks for your comment. Assuming some form of user functionality is involved, I do not agree that you do not need to use some form of ‘requirements technique’. Examples like prototyping have real value but are not enough on their own. My reasons for saying this are that the projects I have seen that have relied upon this alone have been often disastrous from a delivery perspective and have produced a very poor end product. I do agree about common issues around estimating on many projects, not just Waterfall.
You don’t have to gather requirements but then you probably won’t have a successful effort. Gathering requirements just means that you document what the users need and want and make sure that the system does all of those things in a logical way. If you don’t do that how do you know what to build?
Waterfall, which is characterised by upfront planning, is not an all-or-nothing proposition. While the client knows from the start what to expect in terms of time, cost and benefits, the Waterfall project plan is not fixed, but is a baseline for change. Rolling wave planning originated in Waterfall. Also, providing new requirements add value they can be included at any time.
100%
very useful article
Great article to understand difference between these methodologies.
Would be great if you include more of sprint planning and iterations.
Hi Megan – thanks for your comment. The article is not a ‘how to’ as such, more of a comparison, but I may do one on sprint planning quite soon.
Hey,
Thanks for putting together this post on the pros and cons of agile and waterfall.It is a great read. I particularly find your thoughts about pros/cons interesting.
Keep up these insightful posts.
Cheers!
Hi Geoffrey – thanks for your comments. Very glad you enjoyed the post.
The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,[3][4] although Royce did not use the term waterfall in that article. Royce presented this model as an example of a flawed, non-working model; which is how the term is generally used in writing about software development—to describe a critical view of a commonly used software development practice.
that is very nice and well informed. A complete demonstration is given. I bookmarked this page.
If you are confident and experienced and have to apply for CAPEX funding then the Waterfall approach is best for all stakeholders, best approach is to define the requirements to what is known and include a PoC stage to confirm that development team are on track with spec, sign off of PoC may initiate a change request for spec and\or funding, and then the project can be set firm.
If you are in an innovative and learning stage or environment (e.g gaming) and the funds can be raised with an element of risk then Agile is best, allows for change of direction and can be exciting with pulling the best out of a creative workforce. However there is a major risk that towards the end of the project you may have to rewrite something completed at early stage because you may need to change the core\fundamentals to complete the last stages.
Very helpful comment! You explained the difference of Waterfall and Agile, and most importantly the different scenarios for these two approaches. Thank you for your sharing!
Terry – agree – the concept of “emergent design” (some would argue no design), as is often found in Agile, can be a very high risk approach indeed.
Great Post! Keep sharing I am also looking for this kind of blog post.