Loading ...
Sorry, an error occurred while loading the content.

773RE: [scrumdevelopment] Waterfall and Dr. Winston Royce

Expand Messages
  • Mike Cohn
    Dec 14, 2002
      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.


      -----Original Message-----
      From: Adriano Comai [mailto:comai@...]
      Sent: Saturday, December 14, 2002 1:31 PM
      To: scrumdevelopment@yahoogroups.com
      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
      achieve success.

      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".

      Adriano Comai

      > -----Messaggio originale-----
      > Da: Mike Cohn [mailto:mike@...]
      > Inviato: sabato 14 dicembre 2002 20.48
      > A: scrumdevelopment@yahoogroups.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.
      > When Boehm first introduced the spiral model (a big step toward
      > at the time) it was criticized because one could "unroll the spiral"
      > 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
      > 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
      > are also happening all at once. And the feedback from the chaotic
      > are influencing the activities you're just starting. I've talked with
      > 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
      > 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.
      > 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
      > 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
      > what Scrum is meant to be. By now the team is usually very accustomed
      > this way of working and the project rhythm is established. We plan to
      > a couple of Implementation Sprints and then another Analysis & Design
      > Sprint and that gives them comfort. But when something comes up the
      > 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
      > sequentiality to the work that makes many managers feel comfortable.
      > 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@...
      To Unsubscribe, send a blank message to:

      Your use of Yahoo! Groups is subject to
    • Show all 24 messages in this topic