Waterfall Methodology vs Agile

Agile and Waterfall

The debate of Waterfall Methodology vs Agile is one of the longest running debate in the project management world. In 20th millennia people supporting waterfall were winning and in 21st millennia people supporting agile are winning.

What is the Waterfall Method?

The waterfall model is a sequential uni-directional step approach, in which progress of each phase of the project life cycle is seen as flowing steadily downwards like a waterfall, from top to down, through the phases of conception, initiation, analysis, design, construction, testing, production deployment, and maintenance. As this waterfall methodology is sequential, once a step has been completed, a development team can not go back to a previous step or earlier steps, because the cost of making correction/improvement in the output of the previous stage is very high. There’s no room for change or error, so a project outcome and an extensive plan must be set in the beginning and then followed carefully.

Positive Sides of Waterfall Model

Well Structured Processes: To manage projects using the waterfall model we need to have structured processes with clearly defined input and output of each process. There is no overlap of phases and processes, as they are in sequence. At the end of each project phase, a review takes place to check whether the project is on right track or not. But, many a time it is too late to know that we are not on right track.
Easy to understand: Being sequential processes with clearly defined output and responsibilities it is easier for the project team and different departments/stakeholders to understand the processes and expectations from them.
Documentation: Because this model is based on a well-defined structured process where every process needs to have a clearly defined input, therefore, this method highly relies on extensive documentation of requirements, design, project plan, test cases, etc. These documents can be used to support or improve the product in the future.
Defined Requirements: In waterfall projects starts with well-documented requirements or the first phase defines the requirement in detail and baseline the same.
Customer Expectation: With this methodology, the client knows what to expect. They have an idea what is the size, cost, timeline of the project.

Negative sides of Waterfall Model

No matter how much effort you put in defining the processes if a human has to follow those they bring their own dimension of interpretation at the time of implementation. It makes sense to have processes automated where human involvement is the least. In a business where human creativity and judgment are critical full automation is not possible.
In regular businesses, feedback and early feedback are the keys to success. Due to this reason processes are iterative in nature at the implementation level. Hence waterfall doesn’t make sense.
Once the project is in a testing stage, it is very difficult (if not impossible) to go back and change something that was not well thought out in the previous stages of product development.
This model is not suitable if requirements, technology, infrastructure, environment, productivity, or any of these factors are unknown or unstable.
If a project has a higher number of uncertainties then this method becomes useless.

What is Agile?

As the name goes Agile means flexibility, elasticity, bounciness, etc. An approach for managing a project which is responsive to the project environmental factors. That is why agile planning is also called Adaptive planning. Processes in this approach are not sequential and fixed but iterative and empirical. Agile is not only an incremental development approach but much more than that. This approach ensures incremental delivery, value-driven delivery, priority-driven delivery, feed-incorporation, stop early with minimal waste, easy expansion of the project scope. This approach works well when the problem you are solving itself may change during the development. Agile project management is based on the value and principles. These values are principles are defined in the agile manifesto. There are many methods that help to implement this approach for project management. Some of these approaches are engineering focussed, some are management focussed, some are business requirement focussed, and some others are focussed on risk management.

Positive Sides of Agile

Continuous Improvement: Agile method encourages feedback from team members and clients throughout the project. This feedback helps the team to learn from previous delivery and improve the product and processes.
Improved trust within the team: Agile is also notable for emphasizing the importance of motivated individuals who need to be trusted to get the job done.
Strong communication within the team: Agile highlights the importance of frequent communication and face-to-face interactions. Teams work together and people are able to take responsibility and own parts of the projects.
Change is welcome: Agile encourages introducing and accepting the change even at the last stage if the product is going to be ineffective or of the least value without those changes.
Continuous Customer Involvement: This addresses early feedback, product ownership by customers, correction at lessor cost, sense of team, and playing together to win.
Improved Quality: The testing at the end of each iteration ensures that the bugs are caught and taken care of in the development cycle. They won’t be found at the time of product release.
Fast delivery: In this methodology, the product is delivered much more quickly and successive iterations can be delivered frequently, at a consistent pace.

Negative Sides of Agile

I do not see any negative aspects of Agile but negative aspects of how agile is understood (misunderstood) by different stakeholders.

Documentation is neglected: The Agile Manifesto prefers working software over comprehensive documentation, so some team members may feel like it’s less important to focus on documentation. While comprehensive documentation on its own does not lead to project success, Agile teams should find the right balance between documentation and discussion. If you are not documenting then discuss enough, think through with other team members, product owner, and end-user. Documentation makes sense when people can forget, they are not available to discuss when they are needed, to track the evolution of an idea, to share something offline. Documentation doesn’t only word document. Audio/video recordings, photographs of the discussion board, references to other existing sources are also examples of documentation.
Highly Skilled Team: Since the agile teams are small, so they need to be highly skilled in various areas. They must be comfortable with the newly adopted Agile methodology (people with older work practices struggle to shift). Generally, highly skilled/experienced people like higher designation, and they do not want to be part of a delivery team but of the management team. This I have noted more in Asian countries. In these situations it becomes difficult to get a good quality matured, self-motivated, full stake developers for the project.
Generalized Skill Team: Every team member should be able to do everything needed in the project to make it successful. It is difficult to find these kinds of people.
A Product Owner (PO) is The Key: The project can easily get taken off track if the product owner is not clear what final outcome that he or she wants. The pivot of the project is PO. Finding a good PO who understands business, has the authority to make the business discussion, and available all the time for the team is not an easy task.
Time commitment from developers: Agile is most successful when the development team is completely dedicated to the project. Active involvement and collaboration are required throughout the Agile process, which is more time consuming than a traditional approach. It also means that the developers need to commit to the entire duration of the project. Many a time it is challenging for the organization to balance the commitment of team members between various other on-going projects. People leaving an organization or a project due to any reason is another issue. But luckily agile project durations are short so this is manageable to a great extend.
High-Level Planning can be Less Concrete: Because of the entire team’s focus on the delivery of immediate goal sometimes focus on the release date may not be there or extra iteration of work needs to be added to make a market release of the product. But this can be managed if senior management and release management are doing their planning based on regular input from the agile team.

Similarities between Waterfall and Agile

There are not many similarities between Waterfall and Agile. They both have the same goal to deliver quality products efficiently on time but their approach is completely different and sometimes opposite.

Difference between Waterfall and Agile?

	Waterfall	Agile
Sequential and Structured process	Yes	No
Flexibility	No	Yes
Defined Requirements before starting the project	Yes	No
Documentation of requirements are must	Yes	No
Deliver quality product	Yes	Yes
Best for those who want continuous improvements	No	Yes
Suited for situations where change is common	No	Yes
Big bang approach	Yes	No
Highly collaborative	No	Yes
Involves customers	No	Yes

When to use Waterfall?

Waterfall methodology is recommended when:

You have the complete picture of the final product.
Requirements should be well known before developing the product.
The project should be simple and the team has done it many time previously.
When clients won’t have to change the scope and requirements of the project after freezing those.
The project should be done in an orderly and predictable manner.

When to use Agile?

Agile methodology is recommended when:

The project is on new technology and there isn’t any clarity that how the final product will look.
The clients and stakeholders have the ability to change the scope of the project.
The team is highly skilled and adaptable to any kind of change and can think independently.
Rapid deployment is the goal
You want to do R&D
Early closure of the project is a possibility

Why Agile is Better than Waterfall

A better question can be, what is suitable for my project? Or can I apply the agile project management approach to all projects?

It is not about the approach itself. The answer lies in what I have and what I can offer to afford as a customer. As a customer, I want “quality product” “earliest possible” with “least cost” and “least involvement”.

In a project where requirements are not fully known or they are going to change, technology is not finalized, business environment and market condition can change, product is unknown it is not our choice that anything other than Agile is better so implement it. It is extremely difficult to do fixed cost, fixed time, fixed feature, fixed technology project in agile. This works only in waterfall but for that purpose those should be fixed.

Hybrid Model

At high level of the program or project have waterfall. At implementation of the project have agile practices. You should have high level plan and goal to know and track the direction. But deliver those using agile methods.