I started my career as a young intern in a big telecom company. Back then, software development projects would span months, if not years. Project managers had long Excel sheets and complicated dashboards to track the completion of the project. At that time, every project manager used the waterfall method.

Waterfall was classic and time-tested. With its specific structure and well-defined phases, big and small companies relied on the method for the completion of their projects. It dominated the software development industry for many years.

Then in 2001, a group of 17 developers met in Utah to ski and discuss new ways to develop software. They no longer wanted to wait years for a project to complete. Instead, they brainstormed ways to deliver products to customers faster. At the end of their meeting, they created a new methodology: agile. Preferring flexibility and rapid iteration, the agile method took the world by storm. Among startups especially, this method quickly gained popularity.

Today, both methodologies are still used and often compared. Having the choice between two approaches, teams need to make the right one as changing can take a lot of time.

What are the waterfall and agile methodologies? What is the most appropriate for your team? What are the pros and cons? This article will cover both methodologies along with the advantages and disadvantages of each.

The Basics of Waterfall Development

The waterfall methodology is the traditional approach to software development. It has a very linear approach and consists of specific and well-defined phases that a project follows one after the other. Each phase depends on the completion of the previous one.

Some of the phases can include:

• Analysis
• Business and functional requirements gathering
• Design
• Development
• Testing (this phase can be further split up in system vs user acceptance testing)
• Bug fixing
• Deployment and delivery to the customer

”)

Between every phase, there is a review process and a sign-off. The review process ensures all requirements are met. Once the review is done, key stakeholders sign off and the project can proceed. Each phase has key deliverables, specific deadlines along with an expected end date. As a result, the next phase cannot start until the previous one has been completed and sign-off has been done.

Teams tend to be defined in advance and only brought on the project when it’s their turn. For example, developers are only required during the development phase. During other phases, they can work on other projects.

The Basics of Agile Development

Agile prizes flexibility over the rigid structure of the waterfall method. The key goal of agile is to provide value to customers as soon as possible and as a result, gather feedback quickly. This allows teams to iterate and change their priorities based on that feedback.

As a result, projects are broken down into sprints. The team can decide how long they want the sprints to be, but generally they tend to be between one to four weeks. Every sprint starts with a planning session. Companies typically have a backlog of items. This backlog consists of a list of features that they want to deliver to their customers. During this planning session, the team reviews the backlog to decide what they want to deliver at the end of the sprint. After the meeting, the team gets to work.

To keep the team updated on their progress, daily stand-ups take place. During these meetings, the team gathers together, and the person in charge gives everyone the opportunity to give a quick update on the status of their assigned tasks.

Sprints end with a retrospective where team members go over their wins and areas of improvements. If the sprint went well, features are then launched to customers and a new sprint starts.

”)

Comparison Between Waterfall and Agile

As the new shiny methodology, many may assume that agile is better than waterfall. However, the real answer is one of them is not better than the other: it all depends on which methodology is a better fit for your team. Many factors need to be considered.

Some of the advantages of waterfall include:

• Works well for large projects. With its detailed planning, waterfall is especially helpful for complex projects. These typically involve specific pieces that have to be designed with the interactions mapped off. By creating a technical design of the solution from the beginning, problems can be anticipated and resolved.
• Clear requirements. These are defined and documented from the get-go. Everyone involved in the project is made aware of them. If those requirements are not expected to change, the waterfall can be a great solution.
• Detailed and careful development process. Knowing all the deliverables, it’s also easier for developers to code and plan for any edge cases or tricky situations. The same thing applies for the tests created by the quality testers.
• Limited customer involvement. Customers are only involved in the requirements phase and the delivery of the final product, which is less time-consuming for your customers.
• Set budget. The waterfall methodology scopes the whole project from the beginning. This lets companies define a budget early on, which can be very helpful for contract-based projects.

Of course, there are disadvantages to the waterfall methodology:

• Correcting course is very difficult. It’s not uncommon for requirements to have been misunderstood or even forgotten about during the requirements stage. Unfortunately, these issues will often only arise at the end of the project. The customer then realizes that the product delivered is different from what he anticipated.
• Changes are costly in terms of time and money. This is largely due to its rigid linear process and how difficult it is to correct course.

Agile, on the other hand:

• Can correct course far more easily. By gathering feedback from customers quickly, the team can assess whether or not they are delivering what is to be expected. If the customer is not satisfied, agile teams can quickly adjust during the next sprint. This allows them to adapt and iterate when necessary.
• Agile teams tend to be self-organizing and collaborative. They often have frequent contact with customers, and development in agile teams tends to be very user-focused as a result.

As to be expected, there are also drawbacks to the agile methodology:

• Requirements not well-defined and planning is loose. Because of the iterative nature of agile, the backlog can change between two sprints. Whether a feature is added or updated, the list of deliverables can change often. If teams don’t pay attention, the finished product may be different than they anticipated.
• High involvement from customers. Agile teams rely heavily on feedback from their users. Unfortunately, not all users will have the time or the energy for it.
• Sprints have a specific cadence. Unlike waterfall which has phases with different lengths of time, a sprint is time-boxed. Whether the work is finished or not, sprint finishes at a specific date and work is sometimes to be carried over or postponed to a future sprint.
• Less rigorous testing. Because it’s broken down by the different sprints, if teams are not rigorous about their testing, more bugs can make it to production.
• High focus from the team. Because of the short sprints, the agile methodology demands complete focus and dedication on the project from the team.

Conclusion

Choosing which methodology is right for your team depends on many factors.

The rigid structure of the waterfall methodology with its detailed planning and set phases has been used for decades. Many big companies, in particular, have preferred it as waterfall allowed them to scope out entire projects that could span many months or even years. Having very detailed planning from the beginning lets companies plan budgets and resources. This also gives developers and testers a view of the complete solution allowing them to work more effectively. For example, companies who have a lot of contract-based projects, say with the government, tend to prefer the waterfall method as a result.

Agile, on the other hand, is a great fit for startups who don’t necessarily have strict and well-defined requirements. They might not have a specific vision of their product yet and might need to test. By iterating quickly and often, they can gauge the value of their product and improve accordingly. By getting customer feedback as soon as possible, agile teams are able to correct course when necessary. As a result, the agile method works very well for smaller companies with a self-organized and dedicated team looking to quickly test their solution.

Big companies have started experimenting with the agile methodologies by creating specific agile teams within the workplace. Only time will tell whether those companies will continue leaning into agile or stay with a more hybrid approach.

Regardless of which approach you adopt, take in consideration all the factors listed—requirements, team, clients—to make the best choice for your team.

By Marie Starck. Marie is a freelance software developer. She helps entrepreneurs and designers by bringing their ideas to life. She also writes tech tutorials on her free time.