What Are The Advantage of Agile And How Does It Differ From Waterfall?

Let’s take a look at eight advantages of Agile Development and maybe how it differs from traditional Waterfall:


Stakeholder Engagement


With Agile, stakeholder engagement is key. The many changing areas of the project are communicated and signed off on by the people who need and are responsible for the end deliverable. The seemingly ever-flexible scope and the actual deliverable can only be accepted if stakeholders are directly involved and kept informed. Within a Waterfall process, stakeholders place an order and are given a project plan: essentially a recipe is provided for the end product. Within this model, stakeholders don’t have the direct involvement that Agile provides. Stakeholders get updates and change orders, and from that they are kept abreast of the project. Thus Waterfall can create a natural disconnect between the stakeholders and the true state of the project, and Expectations diverge from the Actual.




This relates closely to Stakeholder Engagement, but stretches further to encompass the entire team. Within Agile development, everyone from developers to project sponsors are invited to participate in regular communication sessions. Regularly scheduled Scrum meetings are held to discuss and share progress, problems and future plans. Development Sprints are planned, executed and results shared from top to bottom so that everyone has an opportunity to contribute to considerations of both the project and the end deliverables.


In Waterfall, it is common for teams or sponsors to review reports or attend status meetings and react. That’s the key word. Waterfall is itself a reactive methodology, where Agile is proactive since each sprint is planned with knowledge from the previous sprint. To borrow construction terminology, Agile is “Design/Build”. In Agile development, construction on a bridge could begin without the details being completely defined: you know it will need supports and connection to the each endpoint. Design stays ahead of Development, but does not drive it. What really drives an Agile project forward is the knowledge the team gained in prior sprints. Changes are visible, as are problems and progress. As long as a member is involved in the process, they have the opportunity to know it all. With the transparency Agile affords, there should be few surprises.


Earlier Results


While it is certainly not an absolute, Agile does often provide earlier results. What makes turnaround quicker in Agile is the cadence of the sprints, each providing their own tangible deliverable to evaluate at sprint close. To return to our earlier bridge metaphor, one might plan construction of supports and framework during one sprint, the decking during another, and railing installation during a third. Within Agile, the design and execution of the supports will help define the design of the decking, which in turn defines the railing design. While it is certainly not uncommon to schedule additional sprints which change the final delivery date, the further benefit of Agile over Waterfall is that if changes occur during a Waterfall project the plan must be modified, reset and approved. The execution of those processes can often take more time than a one or two additional development sprints.


Cost and Schedule Predictability


This is often pointed out as an advantage of Agile development, but in my opinion it would be clearer to call it “Predicted Unpredictability”. Predictability within Agile comes via cyclic review, where knowledge gained is used to refine task estimates for future sprints. Through iterations of “t-shirt sizing”, burndown chart review, and retrospectives, the team is often reminded of the finish line and how much distance remains until it is reached. What’s more, this understanding is continually refined with every new week of progress. Contrast that with Waterfall development, where teams often don’t have immediate clarity (and predictability) until the cost burn has gone askew. Waterfall development lacks the intermediate checkpoints defined in Agile.


Allowing for Change


This is a big difference, and worth considering seriously. It’s often said that “change is inevitable”, and so it is. Why would we act otherwise? Agile provides the flexibility for change to occur and the engagements to discuss and approve those changes. Because each sprint is constructed on the knowledge of the last, you see positive and informed change after nearly every sprint. While this can result in an end product that differs from what was initially planned, the reality is that those differences also occur in Waterfall projects. The difference within Agile is that with open communication and regular participation stakeholders, expectations can be adjusted in advance.


In theory, Waterfall gives you what you asked for. If things change, those changes must be documented and approved with considerations to scope change and budget concerns. The approver may not be aware of details and intricacies that are in play and may only be looking at the cost instead of the appropriateness of the deliverables involved. Agile gives teams opportunities to avoid this trap.


Business Value and Quality


Within Agile, business members have a say in the priority of execution. As the project progresses, they are involved with any additions, removals or changing of tasks or priorities. Traditional Waterfall only allows for an initial phase of involvement, with little or no check-in during development. This results in the phase disappointed stakeholders hear all too often: “Well… you got what you asked for!”


In addition, better product quality is nearly guaranteed because of the numerous cyclic reviews and testing associated with the Agile sprint process. Within Waterfall, teams can miss opportunities to positively affect quality through a review process.


In the end, Agile’s increased involvement (beyond traditional Waterfall requirements gathering) helps deliver an end product that is both of higher value to business members, and greater quality overall.

Tim Michalski

Written by Tim Michalski

Tim Michalski is the founder & CEO of Lighthouse Software, a legacy software support and modernization firm that specializes in the delicate transition from older, reliable software systems to newer, modern technologies.

For nearly 30 years since that day, Tim has passionately devoted most of his conscious hours towards becoming an expert software engineer and experienced entrepreneur. In that time, Tim built Lighthouse Software from the ground-up and championed the cause of restoring existing technology investments with iterative modernization over time to lower risks and gain a competitive advantage for his clients. Clients include numerous Fortune 500 companies to small technology firms in banking, healthcare, and government.