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

772R: [scrumdevelopment] Waterfall and Dr. Winston Royce

Expand Messages
  • Adriano Comai
    Dec 14 12:31 PM
    • 0 Attachment

      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

      > -----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 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
    • Show all 24 messages in this topic