DevTeam.Space Product Development Blog

Explore our in-depth product development tutorials and new technology announcements published by our software development experts

All articles

Waterfall vs Agile: Which Methodology is Right for Your Project

A schematic representation of the difference between waterfall vs. agile

The world of business has changed dramatically since the advent of the internet. Traditionally, giant-sized businesses tried to corner most of the market while smaller ones tried to retain their often local customers. Technology has leveled the field considerably.

Big businesses with their deep pockets still levy significant strength in the marketplace. However, technology now allows small businesses or start-ups to reach out to entirely new segments of customers. Websites, mobile apps, and the cloud computing have been at the heart of this change.

Technology has driven this change but has also created a more dynamic and fast-moving business environment. If, for example, one company can innovate faster then this company will be able to gain a lions share of the market. This new dynamic has meant that all companies need to try to compete in the online marketplace in some form or another.

Part of this break-neck pace of change is centered around the ‘Systems of Engagement’ (SoEs), i.e. systems that face customers. A Statista report shows that 25% of mid-market businesses in Europe updated their mobile apps every month, whereas 23% updated their apps every week! This is an amazing statistic.

On the other hand, traditional software systems, such as those used in accounting, don’t have this frequency of change. These are ‘Systems of Record’ (SoRs), i.e., businesses rely on these to run their core operations. It is often not financially viable or indeed necessary to update these systems regularly.

What is clear is that companies need to remain at the cutting edge of technology if they are to thrive. This is why this article will examine the difference between Waterfall vs Agile. This comparison should help you decide which methodology is right for your project.

Contents

What is Waterfall methodology?
How does Waterfall software development work?
Waterfall software development pros and cons
What is Agile methodology?
Notable characteristics of the Agile methodology
Pros and cons of Agile
Agile vs waterfall project management
The transition from Waterfall to Agile

What is Waterfall methodology?

An illustration of the waterfall development process

Long before IT software development projects started, Waterfall methodology was born out of practical necessity. The methodology has its’ origin in construction and manufacturing industries. The reality of those industries is the sequential nature of project phases.

You can’t do one phase of a construction project before you complete the earlier phase. It’s impractical. These industries needed a sequential, linear project management methodology. The Waterfall methodology provided exactly that.

The methodology uses phases like requirements gathering and documentation; system design; development; testing; deployment; and maintenance. One phase can only start after the prior phase has completed. Read more about this methodology in “What the Waterfall project management methodology can (and can’t) do for you”.

Herbert D Bennington first propounded these phases for software development in June 1956. Winston W Royce described the model in a paper in 1970, however, a 1976 paper by Bell and Thayer used the term “Waterfall” for the first time.

How does Waterfall software development work?

The Waterfall project management methodology works sequentially. If the requirements are not gathered completely, design can’t start. Starting the development phase is possible only after the end of the system design. Each phase has its’ entry and exit criteria. Read more about it in “What is SDLC Waterfall model?”.

A successful waterfall software development project places heavy emphasis on accuracy. If requirements were not correctly documented, then the system design wouldn’t reflect the customer requirements. A system developed based on such a design will certainly not deliver the value to the customer.

If during the development phase we find that the requirements were captured incorrectly, it becomes a costly error. One must go back to the requirements gathering phase. The team must modify every document there, subsequently, they must correct the design.

To avoid costly errors found later in the lifecycle, waterfall projects mandate stringent processes. For e.g., each phase must produce outputs in a manner determined prior. For the requirements gathering phase, it could be the requirements definition. The design document is the outcome of the design phase.

The output of each phase needs review. The subsequent phase can start only when the output of the prior phase meets the quality standards. These reviews use checklists and questionnaires built up over the years by learning from earlier projects. Reviewers document their findings and prioritize them. The project team needs to resolve issues if any. Read more about these phase gate reviews in “Accelerating product developments via phase-gate processes”.

Waterfall software development pros and cons

Let’s review the advantages and disadvantages of the Waterfall project management methodology.

Following are the advantages of the Waterfall methodology

  • Early in the history of the software development industry, there was no known alternative to the Waterfall method. Naturally, it was adopted. As a result, most software development professionals have familiarity with it. This certainly is an advantage.
  • Due to its’ long history of use, the methodology now has matured standards, processes, and tools. Deliverables after each phase, templates, review checklists, etc. are easily available. There is also a large body of knowledge about the project phases.
  • When requirements are clear, the team can easily baseline them up front. The known methodology then expedites the development.
  • Managing dependency is easy.
  • If the organization needs to transition the project to another team, they can do so easily. Most teams know the methodology and documentation involved.

Read more about these in “Waterfall Vs. Agile: must know differences”.

Disadvantages of the Waterfall methodology are as follows:

  • This methodology can’t handle a project with frequently changing requirements. The amount of rework is high.
  • Requirement changes when later phases are already underway can cause challenges. It’s hard to move back to earlier phases.
  • Testing starts only after development is over. Bugs found during testing can cause project budget overrun since, in this methodology, defects found later are expensive.

 

What is Agile methodology?

An infographic explaining how the Agile methodology works

The origin of the Agile methodology lies in the events of 1990s. The software industry faced the “Application development crisis’, and it was the time lag between a validated business need and a production-ready application. Experts estimated that this time lag was often three years, or even more. Read about this in “To agility and beyond: The history—and legacy—of agile development”.

By the time a project was implemented, the technology changed. Businesses now needed different features and functionalities that the technology innovations could support. The project, conceptualized with earlier technology, didn’t meet the new needs anymore.

I am talking about successful projects here! You can imagine how businesses feel hearing the news that the project is a failure, after three years. In some industries such as defense and aerospace, the time lag was higher. Complex technologies used in these industries often resulted in a decade or more between project conceptualization and implementation.

Rigid requirements and long development times caused concerns among thought leaders in several industries. In the early 2000s, thought leaders like Jon Kern, Kent Beck, Ward Cunningham, Arie Van Bennekum, Alistair Cockburn, etc. had a series of informal meetings in Oregon and Utah.

They zeroed in on a fast delivery approach. The user will get a functioning product faster. This enabled the user to try it and get some benefits. The development team gets valuable feedback from users. They are ready to change the product based on the feedback. These two traits gradually gave birth to the Agile methodology.

Thought leaders and enthusiasts gradually built upon these ideas. Agile methodology was thus born with 4 specific values and 12 principles. Visit the “Manifesto for Agile Software Development”, or “Agile manifesto” as it’s commonly known, for more details.

Notable characteristics of the Agile methodology

Agile methodology has a few distinctive characteristics, as follows:

  • Agile teams anticipate and proactively scan for changing requirements. The ‘Minimum Viable Product’ (MVP) is tried by the customer, who provides feedback. These result in changed requirements.
  • The development is necessarily iterative, instead of one linear sequence.
  • Agile teams focus on delivering tangible value to the customer and get continuous feedback.
  • A lot of decision making happens at the team level since Agile teams are empowered. Teams are cross-functional, with regular interaction with customers. This makes the entire team realize what customers exactly want.
  • Agile encourages processes, tools, metrics, etc. However, an Agile team only focuses on what’s needed to deliver value to customers.

Read more about these in “Agile vs Waterfall. What should you use for your project?”.

Pros and cons of Agile

There are quite a few advantages of the Agile methodology, as follows:

  • The development team works closely with the customer, therefore, they gain a better understanding of the requirement.
  • An Agile project involves testing from the beginning. This improves the quality.
  • Measuring the number of features built successfully gives a greater visibility to the real status of the project.
  • Customers can frequently change requirements, which enables to capture the latest business needs, which often change.
  • A continuous feedback loop reduces the project risks.

Read more about the advantages of Agile in “Agile vs Waterfall”.

There are also disadvantages to Agile, as follows:

  • The team should be well-versed with the business context and Agile processes. The team makes several decisions. Decisions may go wrong without sufficient expertise.
  • The interaction with the client is key. There are no elaborate processes like the phase gate review of the requirement. If the client isn’t clear what he/she wants from the project, the chances of failure are high.

 

Agile vs waterfall project management

Let’s now compare the Waterfall methodology vs Agile methodology.

When to use agile vs waterfall:

This is the most fundamental difference. When you are developing a high-priority core enterprise ‘system of records’ (SoR), you know such a system will not need frequent changes. In fact, if the CRM or accounting systems in an enterprise require frequent changes, then there’s something fundamentally unstable with the business!

Note that I am talking about core requirements here when I say ‘change’, and not just adding new parameters. Waterfall, with its’ stringent quality processes, is appropriate for this.

A mobile app, on the other hand, must remain up-to-date with the latest industry trends. It requires frequent changes. Iterative development is the name of the game here, hence, go for Agile! Read “Which is best – Waterfall of Agile?” for more information.

An iterative vs a linear approach

Everything in an Agile project is iterative. This includes requirements gathering, design, development, testing, and review. An iteration, which can be a ‘Sprint’ in case of the ‘Scrum’ technique, i.e., an Agile technique consists of all tasks like design and development. New iterations are executed time and again, with incremental changes to the application software.

This is markedly different from the Waterfall, where requirements are baselined, and only then the design can follow, and so on. Unlike Agile where a functional product is delivered after each iteration, the Waterfall approach delivers the complete product at the very end of the project. Read “The pros and cons of Agile and Waterfall” for more insights on the comparison between the agile methodology vs waterfall.

Degree of flexibility

The difference in candidate systems, for e.g., SoE vs SoR, also drives the flexibility required in a project. A SoE like a mobile app will see frequent changes to requirements, consequently, Agile allows flexibility to change requirements. Read about an example in “Agile project management, from agile to waterfall”.

On the other hand, a SoR requires extensive discussion with stakeholders before baselining the requirements. It’s natural that in Waterfall projects the IT team requires commitment from the business that requirements will not be changed afterward or will follow a change control process. The up-front heavy-duty work of gathering requirement will be futile if the requirements can be easily changed later.

Functional teams vs. cross-functional teams

In a Waterfall project, people with different functional skills certainly work together. For e.g., business analysts have a hand-off process to follow before they can hand over requirements to the technical design team or IT architect.

Developers certainly coordinate with testers. This can take several forms. For e.g., testers might have a question on the test data for one test case, or a defect might need close collaboration between developers and testers.

However, the functionalities are decidedly different. There is a ‘separation of duties’, and a developer doesn’t deploy code or test. A waterfall project also has a distinct pattern of resource loading because of this. Typically, the development and testing phases need more man-hours.

This is fundamentally different in case of Agile, where typically a cross-functional team is built. There is interchangeability of duties, and the team works together fully. There isn’t a spike or a trough in resource-loading. In fact, key Agile principles actively promote self-organizing teams where business and IT work together. Read “12 Principles Behind the Agile Manifesto” for more details.

Risk mitigation approach

The agile methodology relies on getting direct face-to-face feedbacks from customers during every iteration. This immediately highlights any bugs or misinterpretations of requirement. Risk mitigation is instant. On the other hand, the Waterfall methodology employs elaborate reviews, audits, and sign-offs to gauge risks.

This is due to the inherent difference between the project types. Agile allows, even anticipates changes in requirements. That’s strikingly different from the emphasis on baselining requirements in Waterfall.

This difference in risk mitigation also has an interesting manifestation! Agile works will with time-and-material contracts where scope change is a norm. Waterfall works well with fixed-price contracts where the IT team needs a contractual protection against scope creep. Read about this in “Waterfall Vs. Agile: must know differences”.

The transition from Waterfall to Agile

Waterfall to agile transition is more than just onboarding a cross-functional team or using the ‘Daily stand-up meeting’ prescribed in the scrum technique. Here’s what you need to do for a smooth transition from Waterfall to Agile:

Recognize when to use Agile

The Agile methodology isn’t suitable for every project. Certain projects require requirements be frozen up front. In some other cases, clients insist on a fixed-price contract.

Agile, with its’ emphasis on iterative development and openness to the fluid requirement is not a good option for such projects. Read a case study in “When Agile can’t be used on projects”.

Adapt to the Agile culture

Agile requires a distinct culture. Organizations that have operated in functional silos may find it strange. Developers and testers who have had hardly any contact so far will need to work in one team, furthermore, their roles and responsibilities will be interchangeable.

Where only business analysts interacted with customers for the requirement, suddenly the customer is part of the team. This is a new way of working and requires a cultural shift. Complete commitment from management is necessary. Read “Three steps to transition from Waterfall to Agile and keep pace with digital transformation” for more insights.

Training, enablement, and tooling

Agile projects use different metrics. Storyboard, ‘Sprint retrospective meeting’, etc. are news concepts for teams that aren’t familiar with Agile. The team needs sufficient training and coaching.

Frequent release management as part of iterative development requires a good understanding of DevOps and related tools. The team also needs effective project management tools. Read a comparison of Agile PM tools in “The 10 best Agile project management tools in 2018”.