I continue to understand the theory of project management and study methodologies, techniques and methods. I have already told you about Agile, a flexible methodology. Now it’s time to talk about its opposite-the cascade methodology, which is also called the “waterfall model” or simply Waterfall.
What is the idea
They say that without knowledge of at least one development methodology, it is pointless to get into project management — everything will start to fall apart. Waterfall is the very good minimum from which you can start. We are used to thinking in sequential categories, so the cascade methodology seems closer, in contrast to the inconsistency of Agile.
Waterfall was first introduced in 1970 by Winston Royce, director of the Lockheed Software Technology Center, in his article. But not to say that no one knew about this approach before him — after all, the structure of the cascade methodology is largely borrowed from the Gantt chart, and, as I have already told you, it has its roots far into the past. It just so happened that Royce (intentionally or accidentally — it is not known) appropriated the glory for Waterfall.
According to Waterfall, the work on the project should go in several stages, following each other, from the first to the last. Their number may vary from project to project, from scheme to scheme, but the essence is the same.
- Requirements. The very first stage, during which the project requirements are determined and analyzed: system requirements, software requirements, customer wishes, etc., etc.On the basis of all this information, they create input documentation, where they describe what should turn out in the end (it does not matter what it will be — software or an aircraft carrier), but not how exactly it will need to be done. In short, at this stage, they write the first, generalized version of the TOR.
- Designing. When the first version of the TOR is ready and there is a general understanding of what needs to be done, the team starts designing-it details the TOR, coordinates the logic of the system with the customer, describes what will work and how. At the end of this stage, the issue of implementation is still not clarified, but it already becomes approximately clear how many people and hours are needed to work.
- Realization. Then the team finally clarifies exactly how the project will be developed, with the help of which tools (programming languages, equipment, services, etc.). The framework that was worked out at the previous stages becomes more complete, the appearance of the product is slowly being formed. This stage accounts for most of the work on the project.
- Check. At this stage, a full-fledged product testing is carried out to find and fix critical (and not so) problems.
- Deployment. And finally, when everything is tested and debugged, they proceed to the last stage, within which they hand over the project to the customer, install, implement — in general, put the product into operation. In addition, this may include subsequent support, and support, including technical support.
It turns out an ideal scheme: we thought through and agreed on the TOR, did everything exactly according to it, tested it, gave it to the client — everyone is happy. And a big, very detailed plan that you create at the very beginning, and which everyone must constantly follow, creates the illusion of security.
We have a clear plan. What could possibly go wrong?
And everything can go wrong.
Postulates of the cascade methodology
Like Agile, Waterfall has its own principles on which everything is built:
- documents and instructions are very important;
- the next stage should start only after the end of the previous one;
- you can’t skip through the stages;
- you can’t go back to the previous stages to change something;
- if the requirements have changed — we redo the TOR;
- errors are detected and corrected only during testing;
- the client does not participate in the work on the project after the creation of the TOR.
But not everything is so clear. Take, for example, the requirement for a rigid sequence of stages and the inability to go back. They say that this is the main difference between Waterfall and Agile, Scrum, etc. But if you look at the original document authored by Royce, it turns out that he quite assumed a return to the previous stages for the same adjustment.
I think the key difference between Waterfall and flexible methodologies and techniques is that, after all, there is only one iteration here. And no possibility to go back to the stage to correct something will not change this. But it is also impossible to say that the same Agile is definitely better than the cascade methodology.
What’s wrong with Waterfall
Now Waterfall is still popular, but for the same IT is less suitable for a number of reasons.
- There are a lot of documents that need to be constantly updated. Because of this, working on a project often turns into a real bureaucracy — until you agree everything with everyone, you will not write everything in the documents, nothing will move from the place.
- A detailed plan can create not only the illusion of security, but also false impressions about working on the project. There may be no useful result behind phrases like “60% of the project is completed”. This is just a manipulation. After all, “to do” does not mean “to do”.
- The user and the customer are completely isolated from the development process. As a result, the first one can’t gradually get used to the product, and the second one can’t make adjustments if something goes wrong. Therefore, products made according to the cascade methodology are not focused on the mass user.
- All the requirements should be immediately known. It is very difficult to do this, because the customer often does not know what he wants. In such situations, flexible methodologies are more convenient.
- Due to the fact that testing takes place in Waterfall only at the very end, incompetent specialists can deal with the project, and no one will notice it until it’s too late. And when a car and a small cart of problems are found at the testing stage, they are simply covered with patches, because there is no other choice. At the first stages, the model may be more or less flexible, but a lot of problems at the testing stage entail disastrous consequences.
What is good about Waterfall
In IT, more and more teams are switching to flexible methodologies for two reasons: the development teams are small, and deadlines can be easily moved. But for large projects, the cascade methodology is still relevant, because:
- It is resistant to frame updates. Thanks to the very detailed documentation of each stage, participants can come and go, but this will not affect the working time in any way.
- It is disciplined, thanks to a plan and a clear sequence of stages and strict management.
- Flexible in the early stages. Before the development stage, it is quite easy to make changes to the previous stages.
- Transparent. It is clear in advance at what stage what will happen, so it becomes easier to predict budgets and recruit a team.
Where is it better to apply
The listed pros and cons do not exclude the use of the cascade methodology (in some cases it is still more appropriate than Agile), but they narrow the space for application. Waterfall is suitable if:
- The customer understands well what he wants. He has a well-developed concept that will not change.
- The customer does not plan to participate in the project after the adoption of the TOR, but completely outsources it.
- The customer wants to know in advance the exact terms and results of each stage.
- It is clear in advance what, how and with what tools you will need to do.
- This is a complex product that requires a lot of costs, and which has a very clear development sequence (it is doubtful that submarines will ever do Agile software).
- The team has already done a similar project.
And in general, no matter how much everyone wants to “be Agile”, the human love for consistency and order is too strong. Especially for developers. Therefore, Waterfall will dominate in the field of project management for a long time.
Source: https://weeek.net/blog/waterfall
