03/26/2019
By
MJV Team

Agile vs Waterfall: what are the differences?

One of the first decisions that managers of development projects face is: which methodology to use? Waterfall Model or Agile model?

This is a choice that defines how the production of a software application will be managed, the resources that will be needed, among other things.

Scoring the differences between the two approaches is a good start. And that is precisely what we propose in this article. Keep reading to know them in detail and make the best choice!

The Waterfall model and its peculiarities

Traditionally, the Waterfall model is a linear approach that has a sequence of events somewhat like this:

  • To Gather and document requirements;
  • To draw;
  • Code and unit test;
  • To Perform the system test;
  • To Perform the user acceptance test;
  • To Correct any problem;
  • To Deliver the finished product.

In a project where the waterfall Model is used, each such point represents a different stage of software development, and each stage usually ends before the next stage can begin. Requirements are usually reviewed and approved by the customer before the project can be started.

There are good and bad things about this approach. Check them out.

The positive aspects of the Waterfall model

In the Waterfall model, developers and customers agree on what will be delivered early in the development lifecycle. This makes planning and design simpler; progress is measured more easily because the full scope of the work is known in advance.

Throughout the development effort, it is possible for several team members to be involved or to continue with other jobs, depending on the active phase of the project. For example, business analysts can learn and document what needs to be done while developers are working on other projects. Testers can prepare test scripts from the requirements documentation while coding is in progress.

Another advantage of the Waterfall model is that, except for reviews, approvals, status meetings, etc., the presence of the customer is not strictly required after the requirements phase.

And there´s more, because design is completed early in the development lifecycle, this approach lends itself to projects where multiple software components must be created (sometimes in parallel) for integration with external systems.

Finally, the software can be designed completely and carefully, based on a more complete understanding of all the products of the application. This provides a better design with less probability of “fragmented effect,” a developmental phenomenon that can occur to the extent that pieces of code are defined and subsequently added to an application in which they may or may not fit well.

The possible problems of the Waterfall model

One area that almost always falls short in this traditional model of work is the effectiveness of requirements. Gathering and documenting requirements in a meaningful way for a customer is often the most difficult part of software development.

Customers are sometimes intimidated by details; and specific details provided at the beginning of the project are required in the Waterfall Model.

Besides, customers are not always able to view an application from a requirements document. Wireframes and mockups can help, but there is no doubt that most end users have some difficulty in putting together these elements with written requirements to come up with a good picture of what they will get at hand.

Another possible development disadvantage in the Waterfall model is the possibility of the customer being dissatisfied with the delivered software. Since all products are based on documented requirements, a customer may not see what will be delivered until it is almost complete. At this point, changes can be difficult (and expensive) to implement.

The Agile model and its peculiarities

The Agile model is an iterative approach that emphasizes the fast delivery of an application to complete functional components.

Instead of creating tasks and schedules, the whole time is divided into phases called sprints. Each sprint has a defined duration (usually in weeks) with a scheduled delivery list at the beginning. Deliveries are prioritized by the value of the business, as determined by the customer. If all the effort planned for the sprint cannot be completed, the work is resized and the information is used for future planning.

As the work is completed, it can be reviewed and evaluated by the project team and the client, through daily builds and end-of-sprint demonstrations.

Agile methodology depends on a fairly high level of customer involvement throughout the project, but especially during the reviews.

Like the Waterfall model, there are also good and bad things in the Agile model. Let´s have a look.

The positive aspects of the Agile model

In the Agile model, the client has frequent and anticipated opportunities to see the work being delivered and to request changes throughout the project; he gains a strong sense of ownership by working extensively and directly with the team.

If the time to market a specific application is a greater concern than releasing a full set of features at the initial launch, the Agile method rapidly helps produce a basic functional version that can be built in successive iterations.

Finally, another advantage of this approach is that development is more user-focused, probably as a result of more frequent customer direction.

The possible problems of the Agile model

One aspect commonly seen as a disadvantage of this approach is that the high degree of client involvement, while great for the project, may be uncomfortable for some clients who simply do not have the time or interest in such participation.

The Agile methodology also works best when the members of the development team are completely dedicated to the project. And since it focuses on frequent delivery and redefinition, some items may not be completed by the due date. Additional sprints may be required, increasing costs.

Close work relationships in an Agile project are easier to manage when team members are located in the same physical space, which is not always possible. However, there are several ways to deal with this problem, such as webcams, collaboration tools, etc.

Finally, the iterative nature of agile development can lead to frequent refactoring if the complete scope of the system is not considered in the initial architecture and design. Without this refactoring, the software may suffer a reduction in overall quality. This becomes more stressed in larger scale implementations or with systems that include a high level of integration.

7 Agile and Waterfall model differences

After recalling the concepts and checking the strengths and weaknesses of Waterfall and Agile models, we now place them side by side to highlight their differences.

Let´s check them out:

  1. The software development process is divided into different phases in the waterfall model, while the Agile methodology separates the project development life cycle into sprints;
  2. Waterfall is a structured methodology that can often be quite rigid, while the Agile methodology is known for its flexibility;
  3. In the waterfall model, software development must be completed as a single project, which is then divided into different phases. However, the Agile methodology can be considered as a collection of many different projects, which are nothing more than the iterations of the different phases focusing on the general improvement of the software with feedback from users or the quality team;
  4. In the Waterfall model, there is no room to change requirements once project development has begun. The Agile methodology, on the other hand, is very flexible and allows for changes in project development requirements even after the initial planning has been completed;
  5. All phases of project development, such as design, development, testing, etc. are completed once in the waterfall model, while, as part of the Agile methodology, they follow an iterative development approach. As a result, planning, development, prototyping, and other phases may appear more than once throughout the development lifecycle;
  6. One of the main differences between Agile and Waterfall is its individual approach to quality and testing. In the Waterfall model, the test phase comes after the construction phase, but in the Agile methodology, the test is typically executed simultaneously with the programming or at least in the same iteration;
  7. The Waterfall model is an internal process and does not require the participation of clients; the Agile approach focuses on customer satisfaction and thus involves its participation during virtually the entire project.

Conclusion

As you may have concluded through reading, the Waterfall model can be considered as a rigorous sequential process, while the Agile model is a highly collaborative process, leading to better team participation and faster problem resolution.

The Waterfall model is best suited for projects that have clearly defined requirements and in which change is not expected, while Agile development supports a process in which requirements must change and evolve. So, if you are planning to develop software that would require frequent reviews and you have to keep up with the technology landscape and customer requirements, Agile is the best approach to follow.

Finally, we add that the waterfall model exhibits a design mentality and centers its focus strictly on completion of development, while the Agile methodology introduces a product mindset that focuses on ensuring that the developed application satisfies its end customers and modifies itself according to the requirements they change.

Back