While Agile has largely replaced Waterfall as the most popular, most used software development approach, that doesn’t mean that Waterfall isn’t, or shouldn’t be, used anymore. Waterfall was originally so popular because it was better than essentially using no project management at all.
Before the creation of Waterfall, all large projects were executed like heavy infrastructure-based projects – there wasn’t another known way to manage large projects at the time.
Since the specifications and designs of initial software projects didn’t change very much, this approach worked well. But, as software started to become commercialised, with more software being developed for business, and eventually end-users, the Waterfall approach began to cause issues. Consequently, the Agile software development approach was born.
- Developers have a more robust picture of what the software needs to achieve, which makes planning, design, and testing more straightforward.
- For large projects with bigger setups, Waterfall ensures all specifications, requirements and milestones, or due dates, are achieved. There is better adherence to the initial project plan.
- The software development plan is structured and can be lined up with a project plan for any infrastructure or hardware components also being made, e.g. a long-term Waterfall-style project plan that the car development or product (hardware) is going through. This ensures software components are ready for integration with hardware components.
- Easier to track overall project progress and time to completion.
- Easy handovers between each team as there is comprehensive documentation to guide each phase.
- Less customer involvement required after the initial stage.
- The linear, sequential approach leads to long coding runs and batching of work, which massively hampers productivity.
- There are fewer opportunities to do quality checks, so any quality defects are carried a long way through the system before being caught.
- Developers become attached to the coding work they’ve done and resistance to, or frustration from, rework increases. For example, developers may have spent two months coding before it finally gets reviewed and rework is ordered.
- The isolation of each stage in the software development process can lead to silos and teams ignoring other elements they are not directly responsible for. This can decrease the productivity of the other parts of the organisation.
- It can be difficult to gather and document the requirements if the customer does not have a clear idea of what they want in their head. Then, if they are unsatisfied with the final product because it looks different than what they imagined, it can be difficult and costly to implement changes.
- Long, drawn-out customer interactions of low value can be required to negotiate the specifications and requirements. Since the plan is not adaptable once it’s signed off, customers must ensure they include everything they want the software to do; they can’t add extra features or modules later to be developed in this project.
- The development process and plan are adaptable; the customer can make decisions and changes throughout the product, rather than having to make them all upfront.
- There are continuous communications and interactions with customers as to what’s going to get developed, how it’s going to get developed, feedback – it is a very end-user focused approach
- Developers complete smaller chunks of code, so reviews and iteration cycles are faster.
- Working software can be quickly produced to increase speed to market and allow the customer to gain value sooner.
- Many smaller iterations, frequently. Developers refine the software based on testing and feedback from the customer.
- Large organisations are broken down into highly communicative cross-functional teams. Each team contains everybody needed to complete that part of the product, from analysts to testers. This enables more communication between the people involved in the different stages of the process and creates a more holistic approach.
- There is less focus on the ‘final product.’ There is no design of a final product so developers and clients can lose focus on the original purpose of the software. For example, the developer can focus too much on what the client wants in the moment, “Oh, it’d be good if this drop-down was here, really good if we could just log in to this thing here…”
- Since Agile avoids hard due dates, and there are many iteration cycles, the length of the project can blow out; some parts of the software may not be delivered in the time frame needed.
- The focus on working software can lead to missing required specifications.
- Frequent changes or additional features can add to the overall cost and time of the project.
- Typically requires teams to be co-located. It can be difficult if members of the team are working remotely.
As you can see, there are advantages and disadvantages to both Agile and Waterfall. However, both methodologies are valuable in their own way. Agile and Waterfall are not extremes, either. Many businesses use a combination of both Agile and Waterfall when trying to achieve project outcomes.
For more information on Waterfall, Agile, and a way forward to get the best of both worlds, check out our upcoming one-day workshop by following the link below.