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 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)
- 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.
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.
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.
- 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. 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) 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).
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 allows 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
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.
In this case, again, if we wish, we can achieve a lot of uniformity.
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.
What is project management?
The article defines project management and explains what a project is. Popular project management theories, practices, standards, and tools.
Waterfall or Agile? What methodology to choose for your project?
The article describes the details of Waterfall, Agile, and Scrum, explains the differences and similarities, pros and cons, and helps in choosing a methodology for a new project.
- Waterfall and development teams in the Software development context
Kaizen: 20 Keys to Workplace Improvement explained with examples
In the 1990s, Professor Iwao Kobayashi announced his work 20 Keys to Workplace Improvement and designed a functional improvement framework named “the 20 Keys”.
Project Change Management Plan, a real example and template
Creating a Project Change Management Plan is a step in project management planning practices when planning all project initiatives.
- Previous article Waterfall and development teams in the Software development context
- Next article What is project management?