Waterfall vs. Agile (Part 1): Can They Be Friends?

Agile and Waterfall have a different set of characteristics that make them better depending on many external and internal factors related to every project: time to deliver, amount of change expected in the specifications, nature of requirements, type of technical employees…etc.

It is uncommon to find projects that should be purely Agile oriented or Waterfall oriented; that’s why companies usually have to combine practices from both of them.

In these series of articles we are going to clarify what the main characteristics of Agile and Waterfall are, and how they apply to the classic areas of software development: Development, QA, Management, and Business.

Agile

Agile’s most important practical characteristic is that it is based on iterations. An iteration in Agile is a small period of time, usually from one week to four weeks, where some functionality from the application is built from end to end.

Agile has its foundation in the Agile manifesto, which only focuses on how to implement Agile, but never mentions anything about its advantages and disadvantages, or what kind of software development it is better for.

Agile is best suited to projects that:

• Focus on time to market - Time to market measures how fast a company can have a product out in the market from the moment they start developing. A fast time to market allows the company to have its product available long before its competitors. Agile is a sure bet to achieve very fast times to market as at the end of each iteration the application should be production ready.
• May require a high degree of change - Requirements can and do change for projects as they progress. Agile provides a flexible process that optimizes feedback so changes can be introduced reliably during development.
• Have one unique important deliverable: the product - There are many projects that only have one important output, the final product. Agile focuses on the product, almost ignoring other artifacts, such as documentation.

Agile is not a well defined, closed process; it is more like a philosophy or a family of related specific processes. Some common Agile specific processes are:

• XP - Focused on engineering practices.
• Scrum- Focused on management practices.
• Lean - Focused on seven principles that mainly apply to management.

In summary, due to its characteristics, Agile is well suited for commercial applications where the focus is on moving from concept to software product without having to fully develop the original idea up front. 

Waterfall

Waterfall is the classic approach to software development. In Waterfall, the phases of software development are consecutive and always in the same order: Analysis – Design – Coding – Testing – Deployment.

Waterfall considers the analysis and the design the most important phases of them all. Waterfall is best suited for projects which:

• Are contract based - The customer requires the company providing the software to commit in writing to fulfil a series of requirements. Since Waterfall is document driven, it lends itself to contracts that are heavily based on requirements. This helps to guarantee that everything specified on the contract is complete.
• Are focused on analysis - Some software development projects require the analysis to be completed beforehand; this would be the case of very complex or critical systems that require many validation steps or approvals. Being a sequential process, Waterfall is naturally suited to this purpose.
• Have more than one deliverable - Not just the product, but also the user manual, the architecture …etc. Waterfall produces documents and artifacts other than the software itself. For some projects, these artifacts are considered almost as important as the final product.

Some examples of software development projects suited for Waterfall are:

• Heavy engineering projects, for instance NASA.
• Projects that require external certification.
• Closed requirements projects.

In summary, Waterfall is best suited for projects where the specification and the design are better created upfront. These could include: engineering projects, large public institutions, software that has to comply with strict regulations…etc.

Mixing Agile and Waterfall

The wrong thing to do in software development is to pick only Agile or Waterfall and completely discard the other one for your project. Given your circumstances and the previous considerations, you should be able to identify which you are going to pick as your main philosophy. But, there will be exceptions where it will be better suited to mix and match from both philosophies.

For example, many Agile projects still require a lot of documentation so you may have to tweak your Agile process and introduce some Waterfall principles to generate the documentation.

No matter if the project is considered an Agile or a Waterfall one, the main activities that are necessary to perform don’t change. What changes are “when” they are performed, and “how” they are performed.

In the next two articles (links below), we will continue to look at the differences between Agile and Waterfall from the perspective of the four classic structural areas of software development: Business, Development, Management, and QA. 

Further Reading

Waterfall vs. Agile: Development and Business

Waterfall vs. Agile: QA and Management