Learn the Truth About “Agile” versus “Waterfall”

Learn How to Get the Best of Both Worlds

What is Waterfall?

1
What is “Waterfall”?

Define
Requirements
Design/Develop
Solution
Test/Implement
Solution
Implement
Change Control
Key Characteristics:

Attempts to define and stabilize detailed requirements upfront prior to the start of the project
The goal is to try to achieve predictability and control
over the project costs and schedule
© 2014-2018 High Impact Project Management, Inc. 2

When people talk about a true “Waterfall” approach, they’re typically talking about an approach that
looks something like this.

• It typically starts by defining all of the requirements for the entire project upfront, and

• Some form of change control is typically implemented to manage and limit changes to the
requirements of the project once those requirements have been approved

The general approach is based on defining and stabilizing the requirements upfront before the
project starts to achieve a level of predictability and control over the project cost and schedule.

2
What is “Waterfall”? (cont.)

Phase Gate
Phase Gate

Define
Requirements
Design/Develop Phase
Key Characteristics: Solution
Test/Implement
May be broken up into phases with phase gates Phase
Solution
to approve phase transitions

© 2014-2018 High Impact Project Management, Inc. 3

In addition, the project may be broken up into sequential phases that may have phase gates to
approve the transition from one phase to the next.
It’s called “Waterfall” because the results of the previous phase generally flow sequentially into the
next phase like a “Waterfall”.

3
Problems with Original Waterfall Approach

Problems Many Times

Define Not Discovered Until
Requirements
Final Testing
Design/Develop
Solution
Test/Implement
Solution

Problems are many times not discovered Process for Correcting Errors
until final testing Could be Long and Expensive
© 2014-2018 High Impact Project Management, Inc. 4

There were a number of serious problems inherent in the original Waterfall process that even Dr.
Royce who originally created it in 1970 recognized.

The first big problem was that any problem in the requirements or design of the solution are many
times not discovered until final testing and the process for correcting errors found at that point
could be very long and expensive.

4
Problems with Original Waterfall Approach (cont.)

Define
Requirements
Design/Develop
Solution
Test/Implement
Implement Solution
Change Control

User
Very Limited Customer Acceptance
Feedback Until Final Testing
Control over requirements can User Acceptance Testing
create a very inflexible approach
that is not responsive to changes
© 2014-2018 High Impact Project Management, Inc. 5

An equally serious problem is that attempting to control requirements of the project in order to
manage the scope to stay within budgeted cost and schedule estimates can create a very inflexible
approach that isn’t responsive to changes. That might work well if you’re in a highly predictable
environment with a low level of uncertainty but it doesn’t work well in environments that are much
more uncertain where it is difficult or impossible for users to fully define the requirements of what
they need in detail prior to the start of the project.

There are also very limited opportunities for customer feedback and input until final user
acceptance testing at the very end of the project. In fact, in many cases, the customer doesn’t even
see what is being designed until the design and testing are already complete and by that time it is
very difficult or impossible to make any significant changes.

The impact of these problems is that there are many software development projects that may have
met their cost and schedule goals but failed to deliver the required business value.

5
Evolution of Iterative Approaches
More iterative project methodologies became more widely
used in the 1980’s and 1990’s

http://en.wikipedia.org/wiki/Rational_Unified_Process

These iterative methodologies replaced the use of the original

Waterfall model in many software projects
© 2014-2018 High Impact Project Management, Inc. 6

As I’ve mentioned, the Waterfall approach has some significant inherent problems associated with
it that even Dr. Royce recognized when he create it in 1970. More iterative project methodologies
that broke up the project into incremental functionality for delivery such as the Rational Unified
Process (RUP) and its variants became more widely used in the 1980’s and 1990’s. These iterative
methodologies replaced the use of the original Waterfall model in many software projects because
they solved many of the problems in the original Waterfall approach.

6
What Do People Really Mean By “Waterfall”?

The term “Waterfall” is used very loosely for any process that is not totally Agile.
© 2014-2018 High Impact Project Management, Inc. 7

It’s ironic that iterative software development processes largely replaced the use of pure Waterfall
methodologies in the 1980’s and 1990’s and a true Waterfall approach isn’t widely used any more
in many application areas, yet people still continue to use the term “Waterfall”.

That can be very misleading because it implies that there is a single discrete approach called
“Waterfall” that is still in wide use today and that is not the case. In most cases, the term
“Waterfall” is used very loosely for any process that is not totally Agile.

7
 NEXT LECTURE:
DEFINITIONS OF TERMS
WHAT IS “AGILE”?

© 2014-2018 High Impact Project Management, Inc. 8

The term “Agile” has been almost as widely misused as the term “Waterfall”. In the next
section we’re going to discuss how the definition of the word “Agile” has evolved and how
it is commonly used today.