Ken,
Although I agree that Winston Royce’s paper doesn’t
describe an Agile process of today, I think it is not such a bad paper if you
take into consideration the following:
1. In figure 7, Royce proposes an early
‘simulation’ done by a small skilled team, to prove the concept. Thus
he says that a complete iteration through, testing and usage, is the most appropriate
form of feedback. He notes that going only one level up is not adequate.
2. I certainly disagree with Royce on
the usefulness of the extensive documentation he recommends. But note –
you can substitute tests for most of Royce’s documentation, and if you do
this, the paper is not so bad. Royce didn’t have access to the
testing capability we do today, but if he did, I’ll bet most of his
documentation would be changed tests in a 2003 paper.
3. At least Royce admits that
everything besides analysis and coding is waste. How many people have been
insulted when I called all that other stuff waste! Now I can quote Royce
at them and have someone with real credibility back me up.
I have a suggestion that comes from product
development. In the 1980’s, product development in the US was decidedly sequential. Nobody had a clue
how to do it any other way. You’ve got to excuse the software
development writers of the time for their sequential bias – it was
everywhere (in this country anyway).
In the late 1980’s, Kim Clark studied the product
development practices of automakers world-wide. The results are in his
book “Product Development Performance” (1991) and Womack’s
book “The Machine that Changed the World,” (1990). They noted that
Japanese product development practices saved 1/3 in development time and 1/2
the development effort, and resulted in better products – consistently, across
the industry. They called Japanese practices concurrent development.
Most US automobile companies have moved
from sequential to concurrent product development, as have many other companies.
Clark points out that the fundamental difference between sequential and
concurrent development is the information flow between people. It is high
bandwidth, bi-directional, and concurrent (ie, information gets transferred as
soon as design starts, not when its done). The feedback provided by this
approach is enormous, and accounts for the large, consistent improvement in
performance.
I vote for a redefinition of terms: Waterfall becomes
sequential. Agile becomes concurrent.
Sequential is a true description of what is considered
traditional software development, and is not a pejorative. Concurrent
captures the essential difference
of Agile, especially since it requires broad communication and feedback. (I
know you said the heart of agile is creativity, but who’s to say that a
sequential process has no creativity?)
Mary Poppendieck
www.poppendieck.com
952-934-7998
From: "Ken Schwaber
<ken.schwaber@xxxxxxxxxxx>" <ken.schwaber@xxxxxxxxxxx>
Subject: Waterfall and Dr. Winston Royce
At recent conferences, especially OOPSLA, I and others in
the agile
community were taken to task for not learning from history.
Specifically, we were castigated for creating a them/us
divide
between prior delopment processes and agile processes. We
were
advised that we could only have done this division through
ignorance,
since the previous efforts contained many of the elements
and,
perhaps, even the essence of agility.
At OOPSLA, we defined the essence of agility as the ability
to be
creative, to determine the right thing to do and then do it.
Other
aspects, such as iterations, increments, self-organization,
emergence, collaboration were important supports, but
without the
creativity, agile
loses its heart.
So, when I was directed to the seminal papers on waterfall,
I was
quite hopeful to learn from my mistakes. After all, I had
implemented numerous waterfall methodologies, including
SADM, SSDM,
SDM, Navigator, ForeFront, Method/1, and Summit. And none of them
were agile or had the attributes of agile. But, I was
advised that
these were improper implementations of the paper that Dr.
Winston
Royce published in 1970, which included such agile mechanisms
as
iterations and complete freedom to move up and down within
the
waterfall.
So I read the paper, "Managing The Development of Large
Software
Systems" which is available in the Session 9 ISCE ACM
archives. Dr.
Royce wrote the paper based on his 9 years of experience in
spacecraft planning, command and post-flight analysis
systems. His
first comment was that "analysis and coding" are
the essential steps
to an development effort "which involve genuinely
creative work which
directly contributes to the usefulness of the final
product." He then
goes on to undercut this by saying "Many additional
development steps
are required, none contribute as directly to the final
product as
analysis and coding, and all drive up the development
costs."
Dr. Royce then goes on to describe a very extensive
waterfall model
for development. Iteration is allowed, but only
"iteration with the
preceding and succeeding steps (phases) but rarely with more
remote
steps in the sequence. The virtue of all of this is that as
the
design proceeds the change process is scope DOWN to
manageable
limits."
Documentation - Dr. Royce, "My own view is quite a
lot...the first
rule of managing software development is ruthless
enforcement of
documentation requirements ... Management of software is
simply
impossible without a very high degree of
documentation." Dr. Royce
indicates that a 1000 page spec document is appropriate for
a $5m
project, mostly because "a verbal record is too
intangible."
Dr Royce's paper brings forth many sound concepts, such as
get a
formal structure, clear delineration of types of work, and
roles.
However, his paper is the mother of all waterfalls and the
mother of
all of the things which agile is intended to remedy. Great
for the
time, an important step forward, but not appropriate for
most
applications that I know about at this time.
Ken
