Waterfall vs Agile Comparison

Water fall model vs Agile Model

There are many aspects that come up when we do a Waterfall or traditional vs Agile models comparison. All of the drawbacks of the traditional model of software development led to the emergence of Agile software development and the underlying various Agile methodologies for software development. In this article we shall do a Waterfall vs Agile  comparison and list out the major reasons Agile software development model is better than traditional software development.

Some of the most important reasons that many projects moved and are moving from Traditional or Waterfall model of software development to Agile software development are below…

In traditional model, Requirements changes cannot be made after  the end of requirements phase, In Agile model, requirement changes are welcome throughout the project duration.

In the traditional model of development, all requirements are gathered upfront from the customer, generally by a business analyst. This is based on a flawed assumption that the customer fully knows what he/she exactly wants and he is  in a position to provide you exactly all the requirements. However, in reality no customer fully knows what he wants. Further, the traditional model of development demands freezing of all the requirements at the end of the Requirements Phase.

There are two possible implications of freezing the requirements 

  1. Customer may end up providing the requirements partially and the final product will not have all the features that the customer intends to have.
  2. Customer may give too many requirements, which he may not necessarily want to have in the final product. He does so because of the fear that he may not be able to include those extra requirements at a later point of time.

Both these situations are disadvantageous to customer, who ends up loosing time or money or both.

In Agile model of development, there is no fear of freezing of requirements, and it is in the interest of customer to provide accurate and optimal requirements. In Agile mode, changes to existing requirements and inclusion of new requirements is always welcome till the end of the project. So, when we do a traditional vs agile comparison, this is certainly a major advantage to move to Agile model of software development.

Big Upfront Planning is not practical – Requirement changes are inevitable during the course of a project

Why requirement changes are inevitable ?

Software teams generally build something unique and something that doesn’t exist for their customer.

While gathering requirements, Customer tries to describe what he imagines of the non-existent product he intends to have. Then, the software teams interpret what the customer described and develops the final product.

Step 1 – Customer imagines what he wants and tries to describe his imagination

Step 2 – Development team interprets this imagination

There is substantial imagination and interpretation present, so there is a definite room for ambiguity in case of requirements elicitation. Thus changes to requirements is inevitable.

Further, In almost all projects in real life, requirements change/evolve as the project progresses. So, big upfront planning is not practical.

The traditional model or Waterfall model of software development requires big upfront planning and changes to requirements are not allowed after the end of requirements phase. In the agile model of development, big upfront planning is not required and changes to requirements are always welcome throughout the project duration.

AGILE DEVELOPMENT 

This model of development believes and accepts that all the requirements cannot be collected at the beginning of a project. So, requirements are never frozen in agile development. They are collected throughout the project, and are prioritized continuously according to the business value.

Changes to requirements are welcomed in agile development. Agile Development understands that requirement changes are inevitable and help customers gain competitive advantage.

Customers are happy to review a working Software than to review documents

Customers are always uncomfortable in providing signs-off to requirement documents, but are always happy to see and review a working software. They will be more than happy to provide their suggestions and any required changes  to suit their needs.

In Waterfall model of development, requirements are frozen after the customer signs-off the requirements document, and the customer will get a chance to see the working software only at the end of the project.

In Agile Development, the final software is developed in multiple increments. Each completed increment is presented to customer for review. Customer’s feedback is obtained and incorporated in the development of subsequent increments.

Thus, in traditional model of development the customer will only be able to see the final working software at the end of the project, on the other hand in Agile model of development, customer will be able to review the software multiple times as increments, and most importantly, his feedback is also obtained and incorporated during the course of software development.

Iterative and Incremental Development is better than sequential and waterfall development

In traditional model of development, Project delivery is done at the end of the project cycle, and the customer will not be able to see anything in between. Most often, When the final project delivery is done, the deliverable may be very different from what the customer imagined or intended to have, and it is too late to change anything then. This leads to disappointed customers. All the customer’s changes and concerns are addresses separately in the “Maintenance phase”, for which the customer has to sign a new contract. All this is very disadvantageous to customer.

In Agile Software Development, Delivery is made to customers in short iterations. Customers get pieces of prioritized working software every 2-4 weeks. Customer will have less waiting time, and he can plan to get the most essential and important things (features) ready and can start using it at the earliest.

Retrospection meetings are done maximum twice or thrice in a traditional project, while in Agile projects it is done a number of times

Retrospection meeting is where the whole team and customer sit and retrospect what went right and what went wrong, and come to decisions to improve the final deliverables.

In Waterfall software development, this meeting is done only twice or thrice during the course of project, while in Agile development, retrospection meetings are done at least 10-12 times during the course of a similar project.