Agile vs waterfall
We explain the differences between these two development methodologies
Polarising arguments have been at the epicentre of different industries since the dawn of time: Picasso or Matisse, Mozart or Beethoven, Mario or Sonic, Star Wars or Star Trek we could go on. The software development community is no different with people gravitating towards either the agile or waterfall approaches of app building, but can there be only one winner?
The two approaches differ substantially in their methods and project goals and these are reflected in their respective ages. Waterfall is largely considered to be the more legacy approach, opting for a linear approach that focuses on creating an iron-clad plan to map out the project in stages, giving developers a clear view of a project's roadmap and how they should progress towards completing tasks in the correct order.
Agile, on the other hand, takes the task of development and focuses on getting the project done quickly with an emphasis on nailing the core goals of the project in no particular order. It's the younger sibling of waterfall and has seen a growing adoption amongst teams throughout the industry. It typically sees teams developing applications faster and then upgrading them in quick stages.
Although youth seems to be overtaking the aged, developers in both camps will fervently argue their corner and for good reason. Despite agile's uptick, waterfall still serves a strong purpose for teams with specific needs that favour one specific development methodology. So, read on to discover why the approaches to software development are so divisive.
Agile vs waterfall: Working methods
Agile development is concerned with getting the software developed quickly and to a recognisable state to where the customer wants it to be. The customer tests the software and then it is refined according to feedback, in a later development stage.
At the beginning of the development cycle, the project is outlined according to customer needs (features), known as user stories. Developers then develop "iterations" which are built to address these needs, in order of importance.
Teams work in sprints to finish each iteration within a set time span, usually measured in weeks. Each sprint aims is to create working software the user can trial, then advocate changes so it more suits their needs.
But the end of the project doesn't mean all features are built. Agile projects can run out of time, meaning developers must either agree with the customer to do without some features that remain incomplete or extend the project (and pay more money) to deliver them.
A waterfall development project follows a traditional, linear approach. The first stage is scoping out users' requirements, which can be an extensive process. Because developers won't produce working software for customers to try out mid-project, they want to understand up front exactly what users want the software to look like.
Then, the developers will design the software, giving themselves a detailed template to work from. By working from a plan, the idea is that the actual development process, which comes next, will be smoother and hit fewer obstacles.
Once they've built the system, developers enter the testing stage - this is where they make sure the software actually works. This sees developers debug the system, sometimes involving users who try it out. After that, the developers go into maintenance mode, installing, supporting and maintaining the software on behalf of the customer.
Agile vs waterfall: Pros and cons
The greatest benefit to Agile development is that it involves the customer or end user at all stages of development, and seeks their views to feedback into the project.
This, as a result, will lead to an application that is far more likely to fit the brief, or at the very least the initial picture, the customer provided. Developing under an agile methodology also means if the customer changes their mind about an element of the software, or requests any last-minute additions, it doesn't present too much of a challenge to incorporate these. Developing under waterfall, meanwhile, means this could be extremely tricky.
This approach also delivers software more quickly to customers, making it ideal for projects in which speed is of the essence.
Another advantage in agile is the concept of continuous improvement, in which lessons learned in one iteration inform work on the next iteration.
However, agile projects are intensive for customers. Their involvement is required throughout, so the customer must be able to spare stakeholders, who must be enthusiastic and engaged in the project. Agile projects can fall apart if the customer isn't interested in working closely with developers.
Agile's other disadvantage is that, because of the strict sprint deadlines, sometimes the overall project can end incomplete. Customers must either just accept the reduced scope of the project, or pay more to get the developers to finish everything they had planned to complete.
By focusing on quality over speed, waterfall is well-suited to less urgent projects with customers who know exactly what they want their software to do. The extensive testing period can result in fewer bugs when the project is complete.
Waterfall's strict linear process means a project is likely to be finished on time and within budget, and with regular milestones, it is easier for both developers and customers to track its progress.
In waterfall development, once the course is set there is no deviating from it. Unlike agile, waterfall doesn't involve customers every step of the way but scopes out their requirements only at the start of a project.
This means the waterfall approach works best when customers have clear ideas about what their software needs to do. If users have only a vague idea, or the project takes a long time to deliver, the finished software often won't need users' requirements, which may change over the course of the project.
Similarly, once a waterfall project hits the testing phase, it's very hard to make changes to the software. Customers will have to pay more money and wait longer if they want to make changes this late.
To avoid this, waterfall developers sometimes build in customer feedback points between the stages outlined above, to adjust the project as they go.
Navigating the new normal: A fast guide to remote working
A smooth transition will support operations for years to comeDownload now
Leading the data race
The trends driving the future of data scienceDownload now
How to create 1:1 customer experiences at scale
Meet the technology capable of delivering the personalisation your customers craveDownload now
How to achieve daily SAP releases
Accelerate the pace of SAP change to support your digital strategyDownload now