Waterfall and Agile are examined as two methodologies for project management, but independently, Agile should be perceived as a product management and development approach. Nowadays, most of these methodologies are related to software development, but in the article, we will also mention the typical applications and uses of Waterfall and Agile. It is important to note that each methodology has its pros and cons.
Waterfall methodology
Waterfall methodology is a linear methodology and is characterized by the fact that each subsequent stage begins after the completion of the previous one. From there comes the name of the methodology. This word most clearly demonstrates the idea behind this methodology, in which case the development process is compared to running water that only goes in one direction.
In this methodology, the sequence of actions could be described as follows:
Waterfall example phases and steps
- Customer Specifications (represents a detailed description of the product with all the expected functionality)
- Design (Architecture, UI / UX)
- Development (Programming, Unit Testing)
- Product Testing (Internal QA Department)
- Client Testing Provision (CAT / UAT)
- Corrections
- Finalizing and handing over the product
Pros of Waterfall methodology
There are clear criteria that the product must meet in its complete form (changes are not allowed; the entire scope of work is pre-set).
The progress of the project is easily measurable because the amount of work is clear from the beginning. Reference: "Waterfall and Incremental model in project management", https://wikipedia-lab.org/waterfall-and-incremental-model-in-project-management/
The work of the different teams is consistent, and their commitment to the project is only when they are needed.
No client involvement is required throughout the work.
Cons of Waterfall methodology
The result is only visible at the end of the process - the customer is not always able to judge what the product will look like in its final form based on its requirements. This is also the biggest problem with this method because the end product is not always satisfying for the customer, even though all the requirements are met. Often, this requires additional changes, which is not always possible to make subject to an already existing product with some functionality. This most commonly affects all aspects of the product (price, quality, duration). In the worst-case scenario, the product can never be used, and this will result in major wastage of customer resources. Reference: "Agile vs Waterfall: The Difference Between Methodologies", (2020 Businesspad.org) author: Samantha Rhine, https://www.businesspad.org/agile-vs-waterfall-difference-between-methodologies/
Agile methodology
Agile methodology is characterized by the fact that it is flexible and iterative with the primary purpose of rapid product development. The team or teams involved in product development play a central role and focus on prioritizing functionality. The sequence of actions is repeated at short intervals (Sprints), the purpose of which is to provide the product with ready functionality.
At the end of each development interval, the result is reviewed by the teams involved in the development and the client (Demo). This means that the Agile methodology requires ongoing client engagement in the development process, and especially at the time of approval of the finished functionality.
This sequence is repeated repeatedly until the product is completed.
Pros of Agile methodology
- Clarity - the customer gets a clear idea of the product as it is being developed. This allows for changes and judgment in the next stages and minimizes the risk of dissatisfaction.
- Agile provides the ability to provide a working product, albeit with incomplete functionality, in a shorter timeframe. This is especially important for products where time to market is critical (such as a betting site).
- Development is driven by priorities, first of all, developing the basic functionality so that the product is ready for use by consumers as soon as possible and then supplementing the secondary functionality. This, to a certain extent, ensures that even if there are unforeseen events (suspension of funding), the product could be put into use, although without full functionality. This also guarantees the client's investment to some extent.
- Reduces the risk of complete failure of the project due to customer dissatisfaction.
Cons of Agile methodology
- Client engagement - The client is not always able or willing to spend so much time on the project.
- Team / Team Engagement - This model only works if all teams are engaged throughout development. Reference: "Agile Project Management", https://agileprogramming.org/agile-project-management/
- Product Recycling - Since the scope of the project is not clear at the outset, and not all the functionality is provided in the design, and the architecture needs re-engineering (Refactoring). Failure to do so may reduce the quality of the product.
Waterfall or Agile approach? Conclusion
From the above information, I would say that the choice of a management system depends mainly on the type of project we have, the client's desire to be involved in the development process, his product requirements, and our ability to delegate teams to the client in question.
If the client does not want to participate in the development actively, there is a fixed functionality and budget I would recommend the use of the Waterfall model, as in Agile, the client plays a key role, and this could delay the project in his inability to participate. Reference: "Comparison of Agile, Scrum and Waterfall project management", https://eduwiki.me/comparison-of-agile-scrum-and-waterall-project-management/ In this situation, I would recommend a thorough review of the documentation with its requirements to make sure that both the development team and the client have a clear idea of what is required of the final product. This, of its passion, takes more planning time than in Agile methodology. On our part, this option would be more convenient in cases where we are not able to delegate entire teams of people to work on this project because at different stages, different units are involved, and at the time when these teams are not needed, they might work with another customer.
If the client has the opportunity and desire to participate in the development process actively, I would recommend using the Agile methodology as it allows for a quick start of the project with the basic product functionality and does not require as long a planning period as in the Waterfall methodology. An additional benefit is that the customer will have a clear idea of the product at an early stage, and this will prevent errors related to inaccurate planning and early correction of design and concept errors. Agile gives confidence and information to the customer about the quality of the product and its development. From our point of view, in this model, we need to provide teams that will work with the customer until the product is completed because of the iterative nature of the methodology, which involves all teams at approximately the same time for short periods.
I would personally prefer the Agile methodology in more cases because of the dynamics of development and the reduction of the risk of customer dissatisfaction with the end product. For this reason, the methodology mentioned above in the table is gaining popularity and is an increasingly preferred development model these days.
Waterfall, Agile, and Scrum in practice
In practice, many products can be developed without restrictions on the type of project or product.
Agile (and most of all Scrum framework, Reference: https://bvop.org/learnagile/scrum/) implies that it has more "transparency". Transparency is a pretty popular term.
At Waterfall, we can achieve transparency again if we wish.
Again, with both methods, we can also reduce transparency. Kanban, for example, does not proclaim customer involvement in development. The team can safely work "closed" for a long time, and no one knows what is going on. Sprints and demonstrations are not required. This is optional, and many companies and teams are practicing hybrid ways of working to achieve more results.
In practice, in every model, we can achieve transparency and break it. Doctrines and practices have no strict conditions except Scrum, where transparency is clearly expressed and strongly focused.
With Scrum, frequent client inspections and research are done to reduce the risk of problems and to demonstrate that work for the period (sprint) is complete. The Scrum team can safely know about a defect, but not express it to other parties and go unnoticed for a long time. Only the culture and attitude of the team members can guarantee this.
At Waterfall, we can have ready-made phases of work, often called releases (set intervals for launching part of a project). Reference: https://www.kosovatimes.net/agile-vs-waterfall-management-methodology/
At Scrum, we have sprints (fixed time intervals to demonstrate the finished work).
There are no conditions in any practice for the duration of the phases.
In Scrum, the only condition for a sprint is to be no more than one calendar month. The minimum sprint time is not officially mentioned. All that is needed during this period is to achieve some increment (increase).
In Waterfall, if we have tasks that are broken down into small parts and the product and technology allow it, we can have a release period of two weeks, for example. If we use Scrum, and our sprints are also two weeks away, we have the same results.
- The result of Sprint 1 can be the same as the result of Release 1
- The result of Sprint 2 can be the same as the result of Release 2
- etc.
In classic project management, we have a practice called change management and change request. This means that the client may request a change to any part of the project.
Each change request is planned and calculated in terms of cost and time and is evaluated as to whether it will be implemented. The popular pervasive spread of the idea of the scope and the inability to change is over-emphasized and spread from site to site and from book to book without any competence or intent. The root of this idea is that if you pour 200 tonnes of concrete into your project, then it would be challenging to make "design changes" if the concrete slab were to be 20 cm narrower.
However, many types of projects easily allow for easy changes.
At Scrum, we have the Product Owner role (in other Product Manager workflows), which decides which change from the last iteration, when it will be made, prioritizing the work, and again, whether it will be made by evaluating its value. Reference: Managing business organizations and adding business value. An Agile Manager’s Guide to the Theory of BVOP.org by Marta Cooper Posted on November 27, 2019, PolicyMatters.net ISSN: 1941-8280
In this case, again, if we wish, we can achieve a lot of uniformity.
Important
All similarities and similarities can be valid if the nature of the product allows it.
If we develop a product with multiple components that can be built on top of one another and can exist on their own, and the result is a partially finished product, we see the high similarity.
However, Agile practices will not help us if our project is a space station that, to understand how it works, must be out of orbit. Iterations and adaptations are also challenging to implement.
The conclusion we can make after this very detailed analysis is that in reality, the two approaches have much more similarities than popular literature points out. The differences are small but significant. The nature of the product, the knowledge of the requirements, and the ability to iterate with real feedback are the most objective factors that influence our choice of method. Everything else is subjective factors.
- Previous article Waterfall and development teams in the Software development context
Waterfall
The Waterfall is a project management approach where the project is implemented in separate stages until it is successfully completed. A big plan is made in advance with all possible details, and then linearly, it goes from the first to the last stage. After passing from one step to another, it is not possible to return to the previous stage, so the move to the next stage is made after the stage we are in is fully completed.Features:
Sequential process - Everything is executed sequentially. Pre-planned process. We know exactly what we want to get as a final product and how it will look Quality is more important than the speed of project completion. A process is dependent on the requirements laid down at an earlier stage. The scope, time, and cost are estimated for the whole project from the beginning. So the company knows what to expect, how long it will take to complete the project. Usually, it takes more than a year to complete such projects. It is quite challenging to make changes. Even in most cases, it is impossible because, in the beginning, it was decided what the project would be and what steps would be taken. Everything is documented.
Agile
Agile is a flexible project management approach. This approach allows large projects to be broken down into more manageable tasks to be handled more quickly by the people working on the project. Thanks to Agile, the team can adapt faster and deliver faster performance. It was originally designed to address the drawbacks of Waterfall in software development. It is not clear precisely what the final product will look like, and we know just what it will be used for. More important is the speed of project creation than quality. A much simpler project that becomes clearer during development. Changes are very easy to make because they are expected at any time. It is created in parts that can be shown to clients so they can see where the project has come from and how it goes. Most commonly used in software development.From a purely practical point of view, I manage to find a few basic differences between the two techniques. The first thing that catches your eye is the organization. In Waterfall, all actions are divided into successive steps. Each comes after the previous one. The new one can start when the previous one is completed. While with Agile the processes can work in parallel. With Waterfall - we must have agreed in advance with the customer the details of the final product because everything must be included in the plan. On the other hand, the Agile technique provides constant contact with the customer.
Waterfall method would be useful for building small projects
The Waterfall method would be useful for building small projects. When the steps are small, the final vision of the product is also clear and everything can be planned precisely. For example, we can take the production of a metal part according to a drawing. The client gives us the final assignment, a drawing of a detail. The road is being built in clear steps and production and marketing are moving on. For its part, when the project is larger, the client still does not know exactly what result he expects in the end, it would be more appropriate to use the Agile methodology. This requires it, because most likely during the design of the final product additional requirements will arise, additional needs of the client will be discovered and if we are in constant contact with him we will be able to correct them immediately. As an example, I would give any end-user software. The client wants an application that does something basic but does not know what design it will have, what will be the main and additional options.
Another difference between the two methodologies is the documentation and reporting of project work.
Another difference I see between the two methodologies is how clearly and accurately we will be able to document and report on the project work. In the case of Waterfall, we have clear steps on which we can set clear deadlines and requirements. We can monitor the quality of each completed stage as well as review what has been done in it. All of these things would be a lot more complicated if we used the Agile methodology, in which things are constantly merging and changing. It would take much more time and energy to analyze the work of a particular team or the performance of a particular task. It would be much more difficult to find fundamental problems in the internal company processes (regardless of the unit/department), which if caught in time can be corrected.
In conclusion, I can say that strict adherence to either methodology would lead to difficulties and problems at one stage of the project. It would be logical to use techniques from both methodologies (and not only), and to calibrate for each specific project and client. Each project must be planned according to the nature of the final product while maintaining maximum flexibility when needed. Of course, the use of good practices from both methodologies does not limit us to use our personal experience, as well as to consult other less popular methodologies.
The word Agile has become very popular these days, but it should be borne in mind that not all terms derived from Japan refer to project management in general. These are rather a a production processes and product management. To be more precise, we can say that the distinguishing features of this type of project management system are flexibility and adaptability.
It has an iterative character and does not follow a specific pattern. It is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.
Agile is not a rigorous approach and any changes that can lead to improvement can be implemented even at the last minute of project development. An example of the use of this project management model can be software development.
Waterfall or the waterfall model is considered one of the main life cycle models for project development and it originates from the United States.
As the name suggests, the model of the waterfall is carried out sequentially from one stage to another. It is linear and consistent, which means that to move on to the next phase, the current one must be completed in its entirety.
The teams spend a lot of time at each stage so that there are no mistakes and it is easy to move on to the next stage, which could be the testing of the developed product.
Cases, where this management model is acceptable, are when no changes would have to be made when the project is smaller and simpler when there is no complexity in the technology when there are more resources available.