In this article, my focus is to the bring out the differences between Waterfall and Agile methodologies based on my experience as a PMP® and Agile Coach.
What will you learn in this article?
In this article, you will learn the definition of Waterfall and Agile, key differences between the two, advantages and limitations of each, how to make the right choice for your project and an example on Waterfall and Agile methods.
What is Waterfall Methodology?
“The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce, although Royce did not use the term waterfall in that article….The earliest use of the term "waterfall" may have been in a 1976 paper by Bell and Thayer”
This methodology describes a linear and sequential approach to Software Development. It is termed “Waterfall” as the life cycle phases in the Software Development cascade from one phase to another systematically from top to bottom. After the completion of every phase, the subsequent phase is expected to start and there is a stage-gate or kill-point review at the end of each phase. Progress of the project is evaluated during this stage-gate review and the decision is made to continue to the next phase or cancel the project. For example, the entire requirements for the project are elicited by the project team from the stakeholders and documented. The team can proceed to the next phase –Design- only after the evaluation of the requirements during the stage-gate review is completed, and a “Go” decision is made.
This is also known as Traditional or Predictive approach in project management, as it applies a predictive planning strategy which uses baselines and milestones to control the project.
What is Agile Methodology?
“The appearance of Agile methods has been the most noticeable change to software process thinking in the last fifteen years , but in fact many of the “Agile ideas” have been around since 70’s or even before. Many studies and reviews have been conducted about Agile methods which ascribe their emergence as a reaction against traditional methods”
This approach of software development is also known as Adaptive approach. Agile Methodology promotes an iterative & incremental approach throughout the entire software development life cycle of the project. This focuses on the values and principles defined in the Agile Manifesto which states
- Individuals and Interactions over processes and tools
- Working Software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace, indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Key differences between Waterfall and Agile Methodology
In traditional approach, an extensive business analysis is performed (typically by the business analyst) in order to meet the requirements of the product, service or result. Requirements are fully documented and signed off by the key stakeholders. The business analyst walks through the requirements to the project team which then performs the design, development and testing of those requirements.
Since requirements are elicited at the beginning of the project and subsequently baselined, it is possible that requirements may decay over a period as the business dynamics keep changing in today’s world.
In Adaptive approach, the requirements are progressively elaborated and stored in the requirements backlog or product backlog. They are stored in the form of Epics/Features/User Stories in the product backlog. The entire agile team collaborates on grooming the requirements later.
Responding to Changes:
Waterfall methodology tries to control the amount of change within a project. It is very rigid to any change in the project and has to go through a process of change requests. Change management plan is well defined to handle any change in a systematic manner to avoid scope creep or gold plating (doing something extra for the customer without them actually asking for it).
Welcome change is a powerful tool in adaptive approach. The agile approach to planning, executing, prioritizing, grooming etc allows the agile team to respond to change quickly. Changes are considered as opportunities to provide value to the customer. Please note “responding” to changes does not mean “accepting” all the changes. It is rather “welcome changes” as the agile team collaborates with the customer more from the value perspective.
There is no specific team size limit in the traditional approach. It can go from a few team members to hundreds in a huge project. This limits the collaboration between the individuals involved in the project, especially in a big-sized team. Team members may be allocated from different functional units and may not be seated together.
In Agile methodology, team size is limited to achieve high collaboration through co-location (team sitting together in the same workspace). Each agile team comprises of a cross-functional team who can produce a working software increment in every iteration.
Development Life Cycle:
In Waterfall methodology, the software development life cycle goes through a series of phases like requirements, design, coding, testing and UAT, sequentially. The entire product or working software is available at the end of the project phase.
In Agile methodology, the development happens in iterations/sprints, and the duration of the iterations ranges from two weeks to a month. The phases of analysis, design and development happens within an iteration and the team is able to produce a working software increment in every iteration.
In Waterfall methodology, the feedback of the project is received at the end of the project when the customer conducts the validate scope process (UAT).
In Agile methodology, feedback of the increment is received by the team at the end of every iteration. Multiple feedback loops provide opportunities for the team to learn quickly.
In waterfall methodology, testing cycle or phase starts after the development phase is completed. Test plans are finalized at the beginning of the project and test cases are written for the product of the project while the development is in progress. Development and test teams are looked at separately within a project team.
In Agile methodology, every iteration planning includes planning for test and test cases are written for those prioritized features or stories for every iteration. Testers and coders work in an integrated manner to deliver the product increment.
In waterfall methodology, the focus is more on producing the project deliverable as defined and baselined.
In Agile methodology, the focus is more on collaborating with the customer and welcoming changes that provide value to the customer.
In waterfall methodology, due importance is given to formalized documentation which helps in monitoring and controlling of the project for the project manager.
In Agile methodology, minimal documentation is prescribed as working software is preferred over comprehensive documentation (as per Agile Manifesto).
In waterfall methodology, there can be many roles defined like Project Manager, team lead, developer, tester, business analyst, design architect, quality analyst etc.,
In Agile methodology, roles are very limited. Especially in Scrum framework, there are only 3 roles. Scrum Master, Product Owner and Development Team (cross functional team).
In Waterfall methodology, project manager is responsible for managing the project and is accountable for the entire project. Project manager manages the project team by assigning work to the team members and getting the task done. In other words, project manager “pushes” the work to the team.
In Agile methodology, the team manages the project themselves as they are a self-organizing team. The team “pulls” the work from the product backlog into the iteration backlog.
In waterfall methodology, the project manager is directly answerable for the outcome of the project and team members are not empowered to take decisions.
In Agile methodology, the agile team is empowered to take decisions and hence they are collectively accountable for the outcome of the project.
In waterfall methodology, the project team measures the project progress using techniques like Earned Value Management and Schedule compression to compress the schedule in case of any deviations.
In Agile methodology, the metrics are derived in terms of velocity (how many story points the team produced during an increment cycle) and other metrics like sprint burndown/burnup charts to monitor daily progress within an iteration.
Advantages and Limitations of Waterfall Methodology
- Ability to apply due diligence in planning for well-defined requirements and scope
- Dependencies are managed effectively as the entire requirements are known well in advance
- Well defined processes pave the way for quality deliverables
- Phase-gate reviews allow stakeholders to eliminate any ad-hoc changes and unplanned additions to the project
- Works well for small projects for a well-defined requirement that is very well understood, and is not likely to change over the duration of the project
- Avoids scope creep with systematic implementation of change management process
- Simple and easy to understand
- Scope, time and cost baseline helps the management to monitor and control the project accordingly
- Requirements are expected to be defined well prior to development which delays the project
- Less flexibility in changes makes it difficult to manage
- Feedback is received from the customer at the end of the project and hence any negative feedback or defects proves costly for the team to fix
- Does not accommodate any changes due to market dynamics and its rigid approach to changes
- Cost of change is more as the defect is identified by the customer at the end of the project
- Ineffective team collaboration as the team works in silos (dev, testing etc)
- Integration is considered at the end and that prevents identification of any technical or business bottleneck
Advantages and limitations of Agile Methodology
- Focusses on business value as developers and business work together
- Stakeholders are engaged effectively in every iteration
- Motivated and self-organizing teams that manage themselves
- Predictable and ensures less variations in the project
- Harnesses change and is more customer centric
- Working software is the measure of progress. Feedback is received from the key stakeholder during every iteration and the cost of change is very less
- Teams retrospect every iteration to look at improvement areas and finetune themselves
- Provides transparency through the process
- Focuses on Minimum Viable Product to release to the customer
- Due attention is paid to specific customer needs and changes are accommodated even late in development
- Not suitable for all types of projects
- May not work well in a large traditional organization due to its flexible and less formal processes
- Minimal depth in requirement analysis and frequent planning may derail the end project goals
- Self-organizing and empowering teams solely depends on team’s maturity level at handling decisions and may backfire
- Working software over comprehensive documentation is misunderstood and hence teams may not focus even on necessary documentation that is required
Waterfall vs Agile Methodology – Which is right for your project?
A typical question that is raised before the software development starts is “which approach should we follow, Waterfall or Agile?”
The following table can be used to determine the approach (please note all the factors do not carry equal weightage)
|Waterfall (works)||Agile (works)|
|Well defined scope and changes are very limited||Scope/Features||When scope is not known in advance or changes are expected as the project moves on|
|When uncertainty is low and low-level risk||Risk||When uncertainty is high and high-level risk|
|When market is stable||Market dependency||When market dynamics change/evolve frequently|
|When customer involvement is required only at certain milestones||Customer Feedback||When customer is available and requires involvement throughout the project|
|When the focus is on planning, monitoring and control and predictability||Focus||When the focus is on innovation|
|When conforming to requirements as agreed upon in the contract||Product Features||When minimum viable product (which gives more value to the customer) is implemented first and we can implement the low valued features later|
|When a large sized team with minimal collaboration or handoff is required||Team||When small team with high collaboration is required|
|When the budget is fixed||Funding||When the budget is not a constraint|
|When it is less important and not urgent||Time to Market||When it is critical, important, and urgent to meet the desired outcome|
Examples of Agile vs Waterfall: How is the software developed?
Waterfall Methodology: (example)
Scope: To provide an employee timesheet software having the following features:
- Ability to login
- Ability for the employees to describe the task and enter the number of hours spent
- Ability to submit for approval to the manager
- Ability to login
- Ability to add a resource to a project
- Ability to link project to a resource
- Ability to assign task to a resource
- Ability to approve/reject the timesheet
- Ability to login
- Ability to add/modify/delete users
- Ability to add/modify/delete projects
- Report on individual user timesheet data for a specified period
- Report on project timesheet data for a specified period
- Report on approved/rejected timesheets for a project for a specified period
Let us assume the above is the scope and timeline for completion is given as 6 months.
Requirements Phase: Detailed requirements on individual features are discussed and elicited from the stakeholders until they are well understood and documented. The requirements document is then signed off by the customer. Scope is identified and baselined during this phase.
Project manager comes out with the detailed plan for the entire project and assigns team members accordingly to perform the task. The scope, schedule and cost are baselined considering all the other project constraints like resources, quality, risks, stakeholders, communication etc.
Design and Development Phase: Development team works on design and coding all the requirements stated above and delivers to the testing team.
Testing phase: Testing team validates the deliverables to see whether they conform to the requirements. They raise defects and the development team works on them. Testing team signs off on the deliverables once they work as per the requirements.
UAT Phase: Customer validates the deliverables and signs off. Raises defects in case there are issues or requirements are not meeting the expectations
Agile Methodology: (example)
Scope: To provide the following features for an ATM
- Cash withdrawal
- Check balance
- Change ATM Pin
- Print statements
- Deposit Cash
- Deposit Cheque
Product owner elicits high level requirements from the stakeholders and documents them in the form of features/user stories in the product backlog. Product Owner then prioritizes the features based on value that can be realized by the customer. Minimum viable product is finalized. 80/20 rule may be applied to find which 20% of the features give 80% value to the customer. In this case, Cash withdrawal and Check balance features are selected as the first increment to be implemented.
Agile dev team along with the Product Owner sizes the features and stories and comes up with the release planning for the MVP identified.
Product owner grooms and prioritizes the user stories in the product backlog. Agile team pulls the work in the iteration backlog and starts defining goals for every iteration until the features are completed. Meanwhile Product Owner continues to progressively elaborate the requirements for other features.
Key business stakeholders, along with the Product Owner review the product increment created by the agile team and provide feedback. The team retrospect after each iteration with respect to people, process and product and finetunes accordingly. This iteration cycle goes on until the first implementation is complete and then the agile team takes up the next available set of features.
As we have seen, Waterfall and Agile methodologies have their own set of advantages and limitations. While waterfall approach is more methodical and predictive, agile approach is more adaptive and dynamic in nature. Depending on the project circumstances and using the table provided under Waterfall vs Agile Methodology, the project team can decide which works better for them.