Insights | Agile vs. Waterfall – Software Development Methodologies

Agile vs. Waterfall – Software Development Methodologies

By Andy Hilliard | December 4, 2006

Agile_vs._WaterfallIn an informal survey, Accelerance Global Partners report that over 70% of their clients have little or no specifications at the beginning of an engagement.

And yet, good specifications are a key success factor for offshoring.

One shortcut is to have the vendor collaborate with you to write the specification. This can be very helpful if you don’t have a lot of experience in specifying software.

But you have to be committed to describing your software. You can outsource the design and development, but not the responsibility for defining what your software should do.

So let’s assume you will write the specification for your software, maybe sharing some of the work with your vendor. What do you write? How much detail do you need to provide?

The answer depends on your software development strategy.

There are two software development strategies that are popular today – Waterfall and Agile. Which one you use depends on two major factors:

(1) How many details you know upfront about the behavior of your software
(2) The consequences suffered if your software fails

Here is a table that shows where each strategy is best applied.

Painful Consequences Mild Consequences
Details Known Waterfall Waterfall or Agile
Details Unknown Waterfall Agile

Some software requires high reliability and accuracy, because of terrible and painful consequences if a failure occurs. In this case, you must use a very formal process to design and development your software (often real-time systems) that may be difficult or dangerous to test (launching a rocket, for example).

Finding errors in such systems at the end of development cannot be tolerated, and therefore great emphasis is placed on the front-end requirements gathering, specification writing, and detailed design. These design documents are reviewed thoroughly before coding begins.

Coding then uses peer reviews, code walk-throughs, string module inspections, module integration, and rigorous testing by the designers. Such a formal software development process proceeds with great ceremony.

The old Waterfall style of software design has separate sequential steps from Requirements to Design and so on down through Coding and Testing until you get to the end of the project.

The waterfall approach is still the recommended way to communicate the desired behavior of your software when you need to build extremely reliable software or you are re-implementing an existing system.

For example, if you are re-implementing an existing client/server application as a new Software as a Service (SaaS) with the same functionality, then your old software is an excellent example of what the new SaaS application should do. Screenshots and live examples from the old software can be used to support a Waterfall strategy.

But it is rare to know all the details of what your software should do when you are at the beginning of a brand new software application project.

Observant software engineers have realized that they jump back and forth between the different waterfall boxes during the course of developing new software. Enforcing the sequential Waterfall process of requirements, design, and then development is artificial and counterproductive for new software application development.

Therefore, development of new software, where all the details are not known upfront, is best suited for an Agile strategy. A few months ago, I wrote about using the Agile strategy for new software development. See “Over the Waterfall into Agile Outsourcing” at

But if your software needs extremely high reliability and/or most of the details are already known, then use of the old tried and true Waterfall method will improve your chances for success when using offshore resources.

So what do you write in your specifications?

The specification element that is key to both Agile and Waterfall strategies is the Use Case. I will cover Use Cases in more detail in the next issue of Runtime.

More from Accelerance

September 25, 2020

Spotlight on Belarus: “Project Rescue” A Digital Transformation Success Story

The company I was working with had made a smart business decision – to start investing in digital transformation to build tools and resources that would increase their connection with customers.  

September 25, 2020

Spotlight on Bulgaria: The Height of Software Development in the Balkans

You can drive up Vitosha mountain for a great view of Bulgaria’s capital, Sofia, spilling across the valley floor below.

September 25, 2020

Spotlight on Armenia: From Ancient Innovation to Cutting-Edge Software Technology

For a country of just under three million people, Armenia has made a remarkable impact on history. The Soviet’s MiG fighter jets? Designed by an Armenian. The brains behind Apple’s iOS mobile...


September 25, 2020

2020 Guide to Outsourcing in Eastern & Central Europe

Key Advantages to Outsourcing in Eastern & Central Europe 


August 15, 2020

2020 Guide to Software Outsourcing Rates

Gain insight into the latest rates for software development outsourcing resources with our proprietary benchmarking guide that offers:

July 27, 2020

2020 Guide to Software Outsourcing in Latin America

Qualified software engineering teams are not easily found. 

How can we help you succeed?

We make outsourcing successful with innovative partner selection services and tailor-made consulting solutions to ensure your desired outcomes.

Let’s Get Started