Waterfall is one of the most used methodologies in software development. So what are its strengths and how can it help you with your project?
In a 2017 Project Management Institute survey , more than 37% of completed projects used Waterfall as their method of choice, making it the most widely used methodology for project management across the world. If we take into account the 20% that reported hybrid methods, then more than half of the projects surveyed use Waterfall in one form or another – hardly the number for a dying technology.
So, should you follow the masses and adopt Waterfall as a methodology? Well, if the answer was just yes or no, we wouldn't be having this conversation.
Defining waterfall structures
In its most basic form, Waterfall is an approach to software development that is sequential and discrete. Teams are expected to follow a set of rigorous phases that begin with requirements gathering and end with project delivery and maintenance.
We call it sequential because the phases form a sequence of steps that must be transitioned in a specific order, like water falling from a waterfall. There is no turning back, no detours and no quick exits.
Each phase is discrete in that they are independent of each other (or at least as independent as possible) and that phase cannot begin unless the previous steps are completed. You can't start testing your work until the system design and implementation are complete.
Although there is a bit of variation, most waterfall frameworks have the same basic steps:
Requirements collection: The team gathers information about the nature of the project, for example, expected features, the type of data it will work with and the environment where it will be deployed, among others.
System design: The team formulates an approach plan and makes strategic decisions, for example, which technologies will be used in the project.
Implementation: The team starts working on the project based on your design choices.
Testing: The team runs a prototype of the project and checks it for bugs or errors.
Delivery/implementation: The project goes into operation and is handed over to the owner.
Maintenance: The team provides support and fixes bugs reported by users.
Keep in mind that although this may seem quite strict, there is some wiggle room. For example, the team may go back to system design to rethink its approach or go back to implementation and work on the project, depending on the nature of the errors found during testing. Of course, the idea is to avoid this type of setback as much as possible.
Waterfall structures and you
To find out if Waterfall is right for you, you first need to understand its strengths and how it solves certain types of problems better than other methods.
Waterfall methodologies use a very clear structure, which can drive developers crazy, but for clients or colleagues in other areas it is much more palatable and easier to digest. For example, it's easier to justify a budget when you have a clear goal and timeline.
Therefore, if your project involves external investment, needs to be approved by other departments, or will influence other areas in unexpected ways, a waterfall approach tends to be more attractive to people outside the project. Tasks seem more organized and easier to explain.
Because requirements are defined from the beginning and remain constant throughout the process, waterfall structures establish very clear goals from the beginning and dissuade teams from straying too far from them.
Small projects and small teams have a lot to gain from a focused approach. Projects are completed faster and developers are less likely to spend resources and time on secondary features that may not be critical to the product. If your team is small and your projects are predictable, Waterfall can provide the ideal structure.
Waterfall is highly methodical, so it should come as no surprise that the framework emphasizes very clear communication procedures at each step.
Because each process is carefully documented, it is easier to share information between different teams dealing with different stages of the development process. Additionally, new members can consult documentation and follow the project more quickly.
If you think your team might change at some point or you might stop adding new members, Waterfall provides a good communication framework to keep everyone informed.
While group behavior is difficult to predict, new teams often have difficulty getting to know each other and understanding their workflow. Rigid structures like Waterfall create work routines that are easier to establish and negotiate, facilitating teamwork, at least in the early phases of the project.
Finally, Agile requires a certain amount of management overhead that not every project manager is trained to handle. The notion of project management is very different in Agile from what we are used to.
As such, Waterfall, for all its quirks, may be an easier methodology to understand and manage for a beginner – unless you have a manager trained in agile or your team has a project manager who is not a software developer. software.
In the end, no 2 projects are cut from the same cloth. Therefore, thinking that a single methodology can be a solution to any problem you are facing is at best hopeful and at worst naive.
A careful approach to software development that helps diagnose the nature of your problem is critical to choosing the right methodology for your project. It's not a question of what's popular, it's a question of what works.
Source: BairesDev
