When to use? Is Waterfall dead?
Did Agile definitely take its place? Is one better than the other?
When it comes to software development, it is always questionable which methodology to use, Waterfall or Agile? Both the agile and waterfall methodologies carry their own set of advantages and disadvantages. Overall, both can be beneficial to a software development team. Which one to choose is highly dependent on the project type and circumstances.
Starting from the very basics, we will clear the current state of both methodologies in software development, answering some of the most common questions regarding each.
The Waterfall methodology was named after its sequential phases arranged in a downward fashion (similar to actual waterfalls), representing the various steps of software development from one end to the other.
Waterfall ensures that each phase is completed before moving on to the next one.
The reason? To avoid starting development before the design work is completed, which could give way to possible incongruities on both ends.
Between each phase, there is usually a stage-gate; for example, before design can begin, requirements must be evaluated and accepted by the customer. This methodology can also be used to predict the total project cost and work required right from the start in the requirements phase.
The agile methodology has two core elements: teamwork and time. Instead of creating a timeline for one large software development project, agile breaks the project into individual deliverable pieces. These ‘time-boxed’ phases are called sprints and last just a few weeks.
Once each sprint is completed, the feedback from the previous phase is used to plan the next one. The sprints seek to cumulatively deliver value, being part of a bigger picture that leads to project completion. That is where it differs the most from the Waterfall method.
Different subsets adopt Agile as a philosophy - DSDM (Dynamic Systems Development Method), FDD (Feature-Driven Development), XP (Extreme Programming), and probably the most popular, Scrum, all draw from Agile to execute software development processes.
A Waterfall is an ideal choice for reliable projects since thorough planning is done at the start, accounting for all internal and external factors that can affect project execution. When the external environment is stable and unlikely to change during the plan,
a Waterfall is the best option, regardless of the project size.
Before Agile, the waterfall approach was the best approach for these types of projects, and it still is today. If you're working on a project that can be planned ahead of time and is low-risk, there's no real benefit in splitting to break it up into multiple sprints to give value each week. In that instance, it's best to concentrate on the end outcome right away.
Agile should be used for projects that require a more flexible process due to their naturally unstable and unpredictable character. In other words, if the product vision and respectively can change due to external factors (e.g., market dynamics), it is preferable to build and adapt the product using Agile. It's also the most effective way to ensure that the project does not stay in development for months before delivering any results. There will be a checkpoint by the end of each sprint where the product owner can test and approve the completed work.
Projects that are changeable and adopt a waterfall face a risk where, due to the lack of proper checkpoints, it's harder to fix possible issues found by the end of development. The extra time allocated for planning the whole project does not ensure that the design and development phases will run smoothly until the end, as most issues are as undesired as unpredictable.
Deciding between Waterfall and Agile should be more than a marketing decision.
It should consider all of the factors that can influence a project, as well as how well-defined a product is a priori. Choosing the wrong tool for the job could lead to extra costs of time and effort.
Overall, why do we favor Agile over Waterfall?
We tried Waterfall for a long time before switching to Agile when we realized it was the best fit for the majority of our projects.
We used a Scrum technique, a subset of Agile, in our Agile Development Process and adjusted it to match the needs of our clients. We believe that this is the better option for our projects because we can either finish with an MVP (Minimum Viable Product) - which would fall under the Proof of Concept phase - or continue with a set of sprints that will add incremental value to the product. Creating universal solutions, on the other hand, is a concept that will never exist in software development.
It's evident that Waterfall isn't dead, and Agile isn't necessarily the best option.
It all comes down to your individual requirements and the most effective means of achieving your goals. Any further debate about it will only add to the noise.
In recent years, being Agile has come to be considered as a benefit. A notable characteristic that a business can get associated with that instantly proves its quality.
The best way to go beyond looks and actually make a difference with a software development process is to truly understand each project's requirements, choose the method that best suits them, and adapt accordingly.