RE: Waterfall and Dr. Winston Royce

Absolutely, Adriano. A problem though is that many people are so used to
thinking that they do need to finish (or get 90% finished) that they are
uncomfortable making a conscious decision to change that way of working.
I used the sprint types to subtly show them that they can move more
toward doing it all simultaneously.

--Mike

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

Mike,

your Scrum introduction strategy is another great example of what I mean
for
"agile". A tangible, out-of-experience way to overcome obstacles and
constraints (organizational, cultural) to be effective, to avoid risks
and
achieve success.

But. Even if it's true that every iterative process can be unrolled to
seem
sequential (if you look at a portion of it with a microscope), obviously
the
real difference with waterfall thinking is in that little statement of
yours: "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".

Adriano Comai
www.analisi-disegno.com

> -----Messaggio originale-----
> Da: Mike Cohn [mailto:mike@xxxxxxxxxxxxxxxxxxxxxxxx]
> Inviato: sabato 14 dicembre 2002 20.48
> A: scrumdevelopment@xxxxxxxxxxxxxxx
> Oggetto: RE: [scrumdevelopment] 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


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/