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

R: [scrumdevelopment] Waterfall and Dr. Winston Royce

Expand Messages
  • Adriano Comai
    Mary, thank you for this great post. You are able to put new lights upon things. Adriano Comai www.analisi-disegno.com ... Da: Mary Poppendieck
    Message 1 of 24 , Dec 14, 2002
    • 0 Attachment
      Mary,
       
      thank you for this great post. You are able to put new lights upon things.
       

      Adriano Comai
      www.analisi-disegno.com

       
      -----Messaggio originale-----
      Da: Mary Poppendieck [mailto:mary@...]
      Inviato: venerdì 13 dicembre 2002 4.50
      A: scrumdevelopment@yahoogroups.com
      Oggetto: RE: [scrumdevelopment] Waterfall and Dr. Winston Royce

      Ken,

       

      Although I agree that Winston Royce’s paper doesn’t describe an Agile process of today, I think it is not such a bad paper if you take into consideration the following:

       

      1.       In figure 7, Royce proposes an early ‘simulation’ done by a small skilled team, to prove the concept.  Thus he says that a complete iteration through, testing and usage, is the most appropriate form of feedback.  He notes that going only one level up is not adequate.

       

      2.       I certainly disagree with Royce on the usefulness of the extensive documentation he recommends.  But note – you can substitute tests for most of Royce’s documentation, and if you do this, the paper is not so bad.  Royce didn’t have access to the testing capability we do today, but if he did, I’ll bet most of his documentation would be changed tests in a 2003 paper.

       

      3.       At least Royce admits that everything besides analysis and coding is waste. How many people have been insulted when I called all that other stuff waste!  Now I can quote Royce at them and have someone with real credibility back me up.

       

      I have a suggestion that comes from product development.  In the 1980’s, product development in the US was decidedly sequential.  Nobody had a clue how to do it any other way.  You’ve got to excuse the software development writers of the time for their sequential bias – it was everywhere (in this country anyway).

       

      In the late 1980’s, Kim Clark studied the product development practices of automakers world-wide.  The results are in his book “Product Development Performance” (1991) and Womack’s book “The Machine that Changed the World,” (1990). They noted that Japanese product development practices saved 1/3 in development time and 1/2 the development effort, and resulted in better products – consistently, across the industry.  They called Japanese practices concurrent development.  Most US automobile companies have moved from sequential to concurrent product development, as have many other companies.

       

      Clark points out that the fundamental difference between sequential and concurrent development is the information flow between people.  It is high bandwidth, bi-directional, and concurrent (ie, information gets transferred as soon as design starts, not when its done).  The feedback provided by this approach is enormous, and accounts for the large, consistent improvement in performance.

       

      I vote for a redefinition of terms:  Waterfall becomes sequential.  Agile becomes concurrent. 

       

      Sequential is a true description of what is considered traditional software development, and is not a pejorative.  Concurrent captures the essential difference of Agile, especially since it requires broad communication and feedback.  (I know you said the heart of agile is creativity, but who’s to say that a sequential process has no creativity?)

       

      Mary Poppendieck

      www.poppendieck.com

      952-934-7998

    • Mike Cohn
      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)
      Message 2 of 24 , Dec 14, 2002
      • 0 Attachment
        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@...]
        Sent: Saturday, December 14, 2002 1:51 AM
        To: scrumdevelopment@yahoogroups.com
        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@...]
        > Inviato: venerdi 13 dicembre 2002 1.30
        > A: scrumdevelopment@yahoogroups.com
        > 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@...
        To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...

        Your use of Yahoo! Groups is subject to
        http://docs.yahoo.com/info/terms/
      • Adriano Comai
        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
        Message 3 of 24 , Dec 14, 2002
        • 0 Attachment
          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@...]
          > 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
        • Mike Cohn
          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
          Message 4 of 24 , Dec 14, 2002
          • 0 Attachment
            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@...]
            Sent: Saturday, December 14, 2002 1:31 PM
            To: scrumdevelopment@yahoogroups.com
            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@...]
            > 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


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

            Your use of Yahoo! Groups is subject to
            http://docs.yahoo.com/info/terms/
          • Martin Fowler
            ... I often say that the only problem with waterfalls is when they are too large. It s reasonable to kayak the Rogue River, it isn t wise to Kayak over Niagara
            Message 5 of 24 , Dec 14, 2002
            • 0 Attachment
              Mike Cohn wrote:
              > I think the popularity of waterfall is that everything degrades into
              > waterfall model to some extent.

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

              I often say that the only problem with waterfalls is when they are too
              large. It's reasonable to kayak the Rogue River, it isn't wise to Kayak
              over Niagara Falls

              Martin
            • Mike Cohn
              Great example! -Mike ... From: Martin Fowler [mailto:mfowlerlists@thoughtworks.net] Sent: Saturday, December 14, 2002 6:24 PM To:
              Message 6 of 24 , Dec 14, 2002
              • 0 Attachment
                Great example!

                -Mike

                -----Original Message-----
                From: Martin Fowler [mailto:mfowlerlists@...]
                Sent: Saturday, December 14, 2002 6:24 PM
                To: scrumdevelopment@yahoogroups.com
                Subject: Re: [scrumdevelopment] Waterfall and Dr. Winston Royce



                Mike Cohn wrote:
                > I think the popularity of waterfall is that everything degrades into
                > waterfall model to some extent.

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

                I often say that the only problem with waterfalls is when they are too
                large. It's reasonable to kayak the Rogue River, it isn't wise to Kayak
                over Niagara Falls

                Martin


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

                Your use of Yahoo! Groups is subject to
                http://docs.yahoo.com/info/terms/
              • Robert Henley
                ... Which is exactly the point of lean production: small lot sizes work better. And an excellent example; I laughed out loud. Thank you! Robert Henley Software
                Message 7 of 24 , Dec 14, 2002
                • 0 Attachment
                  Martin Fowler wrote:

                  > I often say that the only problem with waterfalls is when they are too
                  > large. It's reasonable to kayak the Rogue River, it isn't wise to Kayak
                  > over Niagara Falls

                  Which is exactly the point of lean production: small lot sizes work better.
                  And an excellent example; I laughed out loud. Thank you!
                  Robert Henley
                  Software Architect & Engineer
                • Kevin McIntosh
                  I m sure you couldn t convince this guy that going over Niagara Falls is such a bad idea... http://www.taoberman.com/
                  Message 8 of 24 , Dec 15, 2002
                  • 0 Attachment
                    I'm sure you couldn't convince this guy that going over Niagara Falls is such a bad idea...
                     
                    http://www.taoberman.com/ <---- Nothing to do with PM.
                     
                    -Kevin.
                    -----Original Message-----
                    From: Robert Henley [mailto:rhenley@...]
                    Sent: Sunday, 15 December 2002 2:44 PM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: Re: [scrumdevelopment] Waterfall and Dr. Winston Royce

                    Martin Fowler wrote:

                    > I often say that the only problem with waterfalls is when they are too
                    > large. It's reasonable to kayak the Rogue River, it isn't wise to Kayak
                    > over Niagara Falls

                    Which is exactly the point of lean production: small lot sizes work better.
                    And an excellent example; I laughed out loud. Thank you!
                    Robert Henley
                    Software Architect & Engineer


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


                    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                  Your message has been successfully submitted and would be delivered to recipients shortly.