This document reviews the waterfall software development methodology, highlighting its historical significance and contrasting it with modern agile practices. While waterfall's relevance has diminished with the rise of agile, it still holds value in context-dependent scenarios where compliance to specifications and quality are paramount. The document suggests that waterfall is most applicable in stable environments where clarity of requirements and completion are critical for success.

1. Revisiting Waterfall:
a Post-Mortem

2. Production
Development
Engineering
Is an approach to production
Is an approach to development
Generates a product
A quick introductory glossary…
What use it is made for, per:
How it is made to be used, by:
What usefulness is gained, from:
©2019 Malcolm Ryder / Archestra Research
Requirements: Purpose:

3. Seeing the end
In 2019 AD, the demonization of the “Waterfall” software development lifecycle methodology is
fairly complete in most circles of discussion about relevant present-day “development” practice.
What follows here is a brief review of what remains interesting about waterfall, in hindsight.
Waterfall was around before it was even given a name. Then it stuck around for so long that there
are variants of the variants of the original.
Most of the responsibilities for producing an engineered deliverable are now handed over with
increasing comfort by senior management to newer methodologies like Agile that report improved
business performance against today’s type of customer demand.
But the enthusiasm for doing so is still tempered by widespread reporting of how these alternatives
are (a.) difficult to implement, (b.) most frequently run in hybrid states, and (c.) at best generating
mixed (not guaranteed) results. Change is hard.
Although there is no groundswell of support for “returning” to waterfall methodology, we see that
the terms of rejection for Waterfall are not simply “negatives” of the terms of acceptance for Agile.
Rather, waterfall and Agile are not two ways of doing the same thing. And organizations have
different problems adopting Agile than they do adopting waterfall.

4. Goal of waterfall “projects” *
A typical organization could “adopt” waterfall fairly
easily, because most existing organizations* were
themselves formed largely on the basis of the same
key points of value in the waterfall model.
Those key points were, in effect, principles of
managing “construction”.
Certainly any intended recipient of a developed
product wanted reliability of use from the product.
Organizations are, literally, made to be reliably used.
Understanding that, waterfall’s emphasis within
development on complying with stated
requirements about product qualities is clearly
about managing risks to acceptance.
Almost everything else about waterfall boils down
to building techniques, where a vast world and
history of options has existed within the waterfall
model no less than elsewhere, including now.
* In fact, a “project” is essentially a micro-organization with an
intentionally temporary lifespan, created for generating a new
instance of a specific production output.
Picture: Github

5. Getting to “Done”
In other words, waterfall was never so much of a development management method
addressing a customer demand issue.
Rather, it was a build management method addressing a product management issue.
What changed around the world of waterfall production are mostly two things: acceptable
time to delivery (much less time), and strategies for dealing with complexity (much more
complexity).
Those changes reflect a difference in what a customer deems minimally viable for a
product.
Waterfall is rarely discussed in the terms of the Agile magic bullet: minimum, viable, and
usable.
But those terms make sense only when we know what the context is.
What is it that defines “minimum”, or “viable”, or the dividing line between what is
considered usable or not usable?
When we know what the context is, how frequently does delivery equal improvement?
Occasionally? Continuously?

6. Getting to “Value”
The answer to the above is Requirements. And the context of the above is whatever issues are
making things “required”.
Waterfall usually responds to a context in which “effective” is defined by intended use, and that
definition includes a prerequisite of “completeness”.
Something that is not “complete” could not be expected to have enough reliability to be effective.
Therefore, “viability” is defined in terms of prescribed completeness. Minimum is conceived in
terms of completeness as well.
The root of the matter, however, is that sufficient type of value is the variable concept that has more
permanently changed.
In stable, slow-changing environments, intended use means something different than it does now.
Built-to-last has high value for something expected to be used the same way indefinitely with the
same expected benefit.
But the experience of faster obsolescence makes just-in-time and good enough for now more
valuable if it can be readily superseded when necessary.
That difference does not make waterfall itself categorically obsolete. Instead it makes it suitable or
unsuitable according to the type of value needed externally from the use of its output. Under those
circumstances, waterfall still has the same inherent limitations as always.

7. Engineering
discipline
Quality control
Systems
architecture
Waterfall assumed that all
systems are “built”, so more
building is naturally appropriate
as a way to add something into
a system. But a natural
boundary of benefit
encountered is the complexity
of putting new elements into
pre-existing and already
independent systems
(mechanisms) that didn’t expect
them.
Waterfall assumed that, in exchange
for quality assurance, product
consumers will be reluctant to
change their own requirements. But
a natural boundary of benefit
encountered is the readiness of
competitive suppliers to provide
choice.
features support
fit
Using Waterfall assumed that
development is affordable because
of a sufficient $$ return on the
investment of expenditures into its
“build” technique. But a natural
boundary of benefit encountered is
the amount of time allowed to
reach sufficient confirmed value,
versus the cost driven by
engineering difficulty.
Constraints
on Waterfall
©2019 Malcolm Ryder / Archestra Research
The primary objective of
waterfall is not to “develop”
but to build. But that happens
against difficulty, complexity
and competition.

8. Covering scope
One of the key strategies for dealing with complexity is the division of labor into collaboration.
Depending on circumstances, collaborative development may be one of the strongest arguments in
favor of waterfall.
This is due to waterfall’s explicit model of managing risks-to-requirements, which identifies what
activity generates given terms of acceptance regarding the incorporation of constructive
contributions to the whole.
The explicitness makes it easier for separate (independent) contributors to predict how to engage
and disengage the planned effort.
That in turn can increase opportunity to source the effort by putting internal and external sources
on equal footing, making external sourcing a viable solution to issues of variable capacity as needed
to address variations (decrease or increase) of scope to be built.
• protocol: a system of rules that explain the correct conduct and procedures to be
followed in formal situations.

9. Different kinds of product value
The logic of waterfall does not pertain only to software. The best way to think about its
logic is to not even start with “software”.
Rather, waterfall may still be the best way to make tools, even if it is highly inadequate for
the production of services.
If this makes sense, it relies on understanding how there are real differences between tools
and services.
For example, “software” per se is neither a defacto tool nor a defacto service. Something
causes software ( or any resource) to be used as either a tool or a service.
We might even argue, as a contrasting example, that the natural aspiration of “Agile” is to
create services, not to create tools.
In contrast, waterfall aspires to create what works best as tools.
To clarify that difference, it helps to show the inherent distinction between tools and
services, as well as from other things.

10. Basic Types of Products
TOOL
SERVICE
Is a single item of any kind that is used to amplify and apply certain specific abilities
to directly manipulate other materials or objects in a specific way
MACHINE Is a single entity that coordinates energies and objects in specific actions on the
basis of assuring desired persistence, consistency and repeatability
Allows a self-selected consumer to obtain, on the consumer’s demand, a given
output of some operation’s execution, by making an appropriate request.
CRITICAL DEFINITION
The idea that these products are “developed” includes any means and mode that intentionally
generates the distinctive defining result. However, any one of the products can be used in a role that
matches the description of one of the others. For example, a “service” in one context can be used as a
“tool” in another context.
TYPE
©2019MalcolmRyder/ArchestraResearch
The three types of products shown below are logically different from each other. Their differences mean they can depend on each
other (top down) or support each other (bottom up) – but still, by definition, do not require each other in order to succeed.
The critical influence (measure of success) that defines any one of them can occur in terms that do not involve the other two.

11. Products Recognized by Uses
TOOL
SERVICE
Application
MACHINE
Purpose-built
to be applied to an
unchanging purpose.
System
Facility / Channel
Infrastructure
Platform Operation
NetworkProcess
Function
Organized to support
community demand for certain
experiences or activity
Pre-defined to be
recognized as a change
of state
As ENVIRONMENTAs EVENTAs UTILITY
For a Tool or Utility (lower left), quality and risk are the high priority aspects, normally managed by
engineering. Going from bottom left in the above chart towards the top or towards the right increasingly means
depending on other types of production success factors; aspects such as responsiveness or being reconfigurable
become the more important distinguishing success factors, regardless of any underlying engineering.
©2019MalcolmRyder/ArchestraResearch

12. Summary: a continuing value of waterfall
Waterfall’s distinctive value erodes in lockstep with the increasing unpredictability of
customer types and customer priority in demand.
The authority of customers to change and dictate the immediate terms of acceptance
amplifies the above challenge to waterfall’s value.
However, while waterfall’s main contrast with Agile is usually described in terms of how
they handle scope, the logic of waterfall still applies where the most important values
within scope (product definition) are high compliance to specifications and high quality for
utilization.
Continuous improvement of quality is not antithetical to continuous delivery of value.
Rather, there is more than one type of significant value.
At any given time, the definition of value will prioritize the required degree of quality and
risk necessary to be managed within the most important current scope of deliverable
product.
Depending on the type of value needed from production, the logical model of waterfall is an
abstraction that can still apply, according to the product management requirements.

13. Archestra notebooks compile and organize decades of in-the-field and ongoing empirical findings.
All presented findings are derived exclusively from original research.
Archestra notebooks carry no prescriptive warranty.
As ongoing research, all notebooks are subject to change at any time.
©2019 Malcolm Ryder / Archestra Research
www.archestra.com
mryder@archestra.com
Archestra research is done from the perspective of strategy and architecture.
With all subject matter and topics, the purpose of the notes is analytic, primarily to:
* explore, expose and model why things are
included, excluded, or can happen
in given ways and/or to certain effects.
* comment on, and navigate between,
motives and potentials that predetermine
decisions about, and shapings of, the observed activity.