RE: Waterfall and Dr. Winston Royce

I think the popularity of waterfall is that everything degrades into
waterfall model to some extent.

I've only got one brain (and it only works half the time) and I've only
got two hands so I just half to do things sequentially.

When Boehm first introduced the spiral model (a big step toward agility
at the time) it was criticized because one could "unroll the spiral" and
be back at waterfall. At an extreme (perhaps at the level of a day or
more likely hours) we could say Scrum is a series of waterfall
activities:

-Meet in the morning and chose work
        --talk to Product Owner and fill in missing knowledge
                --design it (in your head perhaps)
                        --code it
                                --unit test
                                        --etc.

Depending on how you think about it and do it, though, these steps
happen hourly, daily, or maybe month-long (the full sprint).

Even a fairly extreme shift like Kent Beck's Test-Driven Development is
a waterfall to some extent: find a requirement, write a test (that
fails), write the code, retest, refactor. All repeated on a scale of
minutes.

Waterfall retains its popularity because at some level ALL other
processes look like a waterfall. I hate the over-used "paradigm shift"
but there really is a shift in one's thinking that has to occur before
really seeing that yes, of course, things happen "sequentially" but they
are also happening all at once. And the feedback from the chaotic events
are influencing the activities you're just starting. I've talked with a
number of managers about Scrum and they claim to get it and then
implement it as a series of waterfall steps. For example, spend the
first week of a sprint "refining requirements", then two weeks coding
then one week testing.

I've actually used this to my advantage in introducing Scrum to groups.
If I have a group that thinks they "get it" but are still thinking a
little too sequentially I phase Scrum in. We'll start with a
"Requirements Capture Sprint" (2-4 weeks). This is just like a regular
sprint but we're really after finding out more about requirements. Then
we do an "Analysis and Design Sprint" (2-4 weeks). By now the team is
getting into the rhythm of sprints and are starting to see
self-organization and a little bit of emergence. I stress that they
don't need to "finish" requirements capturing or analysis/design during
those sprints, just get enough done that they're ready to code. I
promise we'll do another Requirements Capture or Analysis and Design
sprint later if necessary (it almost never is!). Then we start an
Implementation Sprint. Finally, that's the real thing and is pretty much
what Scrum is meant to be. By now the team is usually very accustomed to
this way of working and the project rhythm is established. We plan to do
a couple of Implementation Sprints and then another Analysis & Design
Sprint and that gives them comfort. But when something comes up the team
usually decides they can handle the analysis/design work within the
context of an Implementation (normal) Sprint.

This all works because it starts out feeling like there's a waterfall or
sequentiality to the work that makes many managers feel comfortable. By
the time they notice though the rug is pulled out and they're doing a
little requirements, a little design, a little coding, all together at
once.

--Mike

-----Original Message-----
From: Adriano Comai [mailto:comai@xxxxxx] 
Sent: Saturday, December 14, 2002 1:51 AM
To: scrumdevelopment@xxxxxxxxxxxxxxx
Subject: R: [scrumdevelopment] Waterfall and Dr. Winston Royce

Ken,

this is a concrete example of what I mean for "agile".

In my opinion, agile means not only small releases and timeboxing, not
only
frequent feedback, not only creativity and self organization.
Yes, in most cases direct communication is better than documentation (to
simplify a complex problem).

But the core of agility is: given a concrete situation, with concrete
constraints (as the presence of existing management reporting practices
in
an organization), which is the best way to effectiveness, to achieve the
success of the project? How to overcome those constraints?

We are seldom in ideal situations, where all the agile practices can be
used
without any constraint (Paul's is certainly one of these non ideal
situations). But we must deal with them, in the best realistic way.

I think most of "agile" comes simply after "experience". Of what works,
of
what does not work.
Waterfall is simple, and sounds effective to those who have not had the
experience of its drawbacks. Now we know it's not effective, after
experience. After the experience of 32 years of software development,
and of
waterfall problems, I guess Winston Royce in 2002 would not write the
same
paper. (You are anyway right, it's nonsense to say that the 1970 paper
from
Royce "contained many of the elements and, perhaps, even the essence of
agility").

Adriano Comai
www.analisi-disegno.com

> -----Messaggio originale-----
> Da: Ken Schwaber [mailto:ken.schwaber@xxxxxxxxxxx]
> Inviato: venerdi 13 dicembre 2002 1.30
> A: scrumdevelopment@xxxxxxxxxxxxxxx
> Oggetto: RE: [scrumdevelopment] Waterfall and Dr. Winston Royce

[...]
> minimize the disruption. For instance, management
> reporting. Absolutely a difficult item to tackle. I usually recommend
that
> existing management reporting be kept totally intact, overhead
> and all, and
> that Scrum reporting be added to it. During review meetings, review
the
> "real" progress on the Scrum reports. Eventually, management gets
> comfortable with these reports AND the actual progress demonstrated at
the
> Sprint reviews. But this is a "win them over" not "kill them with
> how right
> I am" approach. Management is threatened enough by ScrumMaster and
them
> "helping" the teams rather than telling the teams what to do. And then
we
> turn them out of their offices and turn the office into a team
> design room.
> Wow! That's difficult change!
> Ken



To Post a message, send it to:   scrumdevelopment@xxxxxxxxxxx
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@xxxxxxxxxxx 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ 





To Post a message, send it to:   scrumdevelopment@xxxxxxxxxxx
To Unsubscribe, send a blank message to: 
scrumdevelopment-unsubscribe@xxxxxxxxxxx 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/