773RE: [scrumdevelopment] Waterfall and Dr. Winston Royce
- Dec 14, 2002Absolutely, 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.
From: Adriano Comai [mailto:comai@...]
Sent: Saturday, December 14, 2002 1:31 PM
Subject: R: [scrumdevelopment] Waterfall and Dr. Winston Royce
your Scrum introduction strategy is another great example of what I mean
"agile". A tangible, out-of-experience way to overcome obstacles and
constraints (organizational, cultural) to be effective, to avoid risks
But. Even if it's true that every iterative process can be unrolled to
sequential (if you look at a portion of it with a microscope), obviously
real difference with waterfall thinking is in that little statement of
yours: "I stress that they don't need to "finish" requirements capturing
analysis/design during those sprints, just get enough done that they're
ready to code".
> -----Messaggio originale-----only
> Da: Mike Cohn [mailto:mike@...]
> Inviato: sabato 14 dicembre 2002 20.48
> A: email@example.com
> 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
> got two hands so I just half to do things sequentially.agility
> When Boehm first introduced the spiral model (a big step toward
> 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 oris
> more likely hours) we could say Scrum is a series of waterfall
> -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
> 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
> a waterfall to some extent: find a requirement, write a test (thatthey
> fails), write the code, retest, refactor. All repeated on a scale of
> 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
> are also happening all at once. And the feedback from the chaoticevents
> are influencing the activities you're just starting. I've talked witha
> number of managers about Scrum and they claim to get it and thengroups.
> 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
> If I have a group that thinks they "get it" but are still thinking aThen
> 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.
> we do an "Analysis and Design Sprint" (2-4 weeks). By now the team isduring
> 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
> those sprints, just get enough done that they're ready to code. Imuch
> 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
> what Scrum is meant to be. By now the team is usually very accustomedto
> this way of working and the project rhythm is established. We plan todo
> a couple of Implementation Sprints and then another Analysis & Designteam
> Sprint and that gives them comfort. But when something comes up the
> usually decides they can handle the analysis/design work within theor
> context of an Implementation (normal) Sprint.
> This all works because it starts out feeling like there's a waterfall
> 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 aTo Post a message, send it to: scrumdevelopment@...
> little requirements, a little design, a little coding, all together at
To Unsubscribe, send a blank message to:
Your use of Yahoo! Groups is subject to
- << Previous post in topic Next post in topic >>