Agile methodology vs waterfall
You can think of agile and waterfall as two opposing ends of a spectrum. Agile focuses on speedy progress based on constant communication with the customer, and uses a working product (such as software), as its measure of progress.
Waterfall is a much more traditional methodology, relying on extensive planning, then follows a linear development method that only delivers a working product at the end of the project.
Both approaches have their advocates and critics, and here we’ll go into some more detail on their advantages and disadvantages below – again using software development as an example.
While most developers lean one way or the other, many choose to be less dogmatic and tweak the approaches as they see fit.
Agile methodology focuses on building software quickly based on customer requirements, then adjusting it according to customer feedback before moving on to the next step in development.
An agile project starts by defining the key features of the software the customer wants. These are called ‘user stories’ and developers group them into ‘iterations’, based on priority. Working in sprints, the team aims to complete each iteration within a set timespan, usually measured in weeks. The aim of each sprint is to produce working software the user can try out, then recommend adjustments so it better 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.
Pros and cons of agile methodology and waterfall
Agile’s biggest advantage is that it involves customers at every stage of development. With users constantly providing feedback on working software, the project is much more likely to end up meeting their needs, which may develop as the project progresses. Unlike waterfall, if a customer requests a change, agile developers can easily make it.
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 methodology is the concept of continuous improvement, in which lessons learned in one iteration inform work on the next iteration.
Agile methodology cons
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 about 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 methodology, 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.
Related: Top 5 Agile tools