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

RE: [scrumdevelopment] Waterfall and Dr. Winston Royce

Expand Messages
  • Mike Cohn
    Good luck with the change, Paul. There is a lot of material at www.agilealliance.com/articles that can help. There are articles on transitioning and there are
    Message 1 of 24 , Dec 12, 2002
    • 0 Attachment
      Good luck with the change, Paul.

      There is a lot of material at www.agilealliance.com/articles that can
      help. There are articles on transitioning and there are case studies and
      background materials on all the agile processes. Naturally, my
      preference is Scrum but the other processes are sometimes a better fit
      (e.g., FDD if you're group likes UML, DSDM if they're prototyping fans).

      There are plenty of others pushing for similar changes within their
      organizations. Just let us know of anything specific we can do to help
      you sell the change and make the transition.

      -Mike

      -----Original Message-----
      From: Paul [mailto:horked_noodle@...]
      Sent: Thursday, December 12, 2002 5:11 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: RE: [scrumdevelopment] Waterfall and Dr. Winston Royce

      Well, I plan to attempt it. I'll definatly need help
      from you guys. I do work for a fortune 500 company.
      Our ways are bad for the new economy.
      My last position there the manager had a waterfall
      dream, and just kept pushing more documenting and more
      docmenting until I got fed up and left. There had to
      be documentation for HTML web pages. I really like
      the point of documentation as a tool for the team to
      do it's work, and nothing more. But the QA dept.
      wanted to put them in nice binders on the shelf so
      that any time a program was changed, the corresponding
      documentation would also need changed and refiled in
      the binders. After pulling out most of my hair, I had
      to leave the department.

      I think agile is the way and I am aiming at using it
      or being fired.

      -- Paul


      --- "David J. Anderson" <netherby_uk@...>
      wrote:
      > Still kidding for a moment - 1000 pages for a $23MM
      > project would still be OK.
      >
      > Now to deal with the real beast of Waterfall and why
      > it remains popular.
      >
      > I think it is to do with two things - a tangible way
      > to declare progress - and related to this a way for
      > accounts to show added value - some countries allow
      > the capitalization of development work in their
      > standard and acceptable accounting practices.
      >
      > The 2nd one creates a macro problem for managers -
      > they can have financial constraints or controls
      > imposed which make Waterfall optimal for solving the
      > problem of meeting their numbers. This would be hard
      > to overcome - maybe impossible in a big company -
      > Fortune 500.
      >
      > The first one is really to do with how acceptable
      > the
      > management finds reporting methods. I think that
      > getting out of the waterfall model can be overcome
      > with learning. For example, if in Scrum you could
      > build consensus that reporting on the burn down
      > chart
      > of tasks for a project (or as Ken does in the book)
      > report the hours remaining then this may be
      > acceptable.
      >
      > It occurs to me that the hours remaining against the
      > hours spent may be a suitable solution to the
      > financial problem too.
      >
      > Developers get asked to fill out timesheets becuase
      > of
      > management accounting methods such as Activity Based
      > Costing. If Scrum's time remaining (and time spent)
      > charts were enough for management then the Waterfall
      > thinking would be broken.
      >
      > In my experience, getting people to buy-off on new
      > ways of reporting progress is very hard - very hard
      > indeed.
      >
      > David
      >
      >
      > --- Paul <horked_noodle@...> wrote:
      >
      > <HR>
      > <html><body>
      >
      >
      > <tt>
      > Kidding aside, what is the real take on the 1000
      > page<BR>
      > spec?<BR>
      > Dr. Royce said a 1000 page spec is appropriate
      > and<BR>
      > David said it's reasonable, but isn't this
      > totally<BR>
      > wrong approach to agile?<BR>
      > Why spec so much?<BR>
      > I loathe the waterfall methodology.  We have
      > one<BR>
      > manager trying to push it at my company.  He's
      > winning<BR>
      > the battle.<BR>
      > <BR>
      > --- Ken Schwaber <ken.schwaber@...>
      > wrote:<BR>
      > > Great. Where do I apply?<BR>
      > > Ken<BR>
      > > <BR>
      > > -----Original Message-----<BR>
      > > From: Mike Cohn<BR>
      > > [mailto:mike@...]<BR>
      > > Sent: Thursday, December 12, 2002 5:54 PM<BR>
      > > To: scrumdevelopment@yahoogroups.com<BR>
      > > Subject: RE: [scrumdevelopment] Waterfall and
      > Dr.<BR>
      > > Winston Royce<BR>
      > > <BR>
      > > <BR>
      > > According to<BR>
      > ><BR>
      > <a
      >
      href="http://woodrow.mpls.frb.fed.us/research/data/us/calc/">http://wood
      row.mpls.frb.fed.us/research/data/us/calc/</a><BR>
      > > <BR>
      > > $5 million in 1970 is $23M today<BR>
      > > and<BR>
      > > Ken should be making $55,515 a year.<BR>
      > > <BR>
      > > --Mike<BR>
      > > <BR>
      > > -----Original Message-----<BR>
      > > From: Ken Schwaber
      > [mailto:ken.schwaber@...]<BR>
      > > Sent: Thursday, December 12, 2002 3:18 PM<BR>
      > > To: scrumdevelopment@yahoogroups.com<BR>
      > > Subject: RE: [scrumdevelopment] Waterfall and
      > Dr.<BR>
      > > Winston Royce<BR>
      > > <BR>
      > > Let's see. In 1970 I was being paid $12,000 a
      > year<BR>
      > > by the University of<BR>
      > > Chicago. At the same markup (factor of 30), I
      > should<BR>
      > > be making $360,000<BR>
      > > per<BR>
      > > year. Who wants to contribute to the
      > cause??<BR>
      > > Ken<BR>
      > > <BR>
      > > -----Original Message-----<BR>
      > > From: David J. Anderson<BR>
      > > [mailto:netherby_uk@...]<BR>
      > > Sent: Thursday, December 12, 2002 5:12 PM<BR>
      > > To: scrumdevelopment@yahoogroups.com<BR>
      > > Subject: Re: [scrumdevelopment] Waterfall and
      > Dr.<BR>
      > > Winston Royce<BR>
      > > <BR>
      > > <BR>
      > > What would $5MM be in today's money? My guess
      > is<BR>
      > > around $150MM.<BR>
      > > <BR>
      > > I'd say a 1000 page specification for a
      > $150MM<BR>
      > > project<BR>
      > > would be decidedly agile.<BR>
      > > <BR>
      > > David<BR>
      > > --<BR>
      > > David Anderson<BR>
      > > <a
      >
      href="http://www.uidesign.net/">http://www.uidesign.net/</a><BR>
      > > The Webzine for Interaction Designers<BR>
      > > <BR>
      > > --- "Ken Schwaber
      > <ken.schwaber@...>"<BR>
      > > <ken.schwaber@...> wrote:<BR>
      > > <BR>
      > > Documentation - Dr. Royce, "My own view is
      > quite a<BR>
      > > lot...the first<BR>
      > > rule of managing software development is
      > ruthless<BR>
      > > enforcement of<BR>
      > > documentation requirements ... Management
      > of<BR>
      > > software<BR>
      > > is simply<BR>
      > > impossible without a very high degree of<BR>
      > > documentation." Dr. Royce<BR>
      > > indicates that a 1000 page spec document is<BR>
      > > appropriate for a $5m<BR>
      > > project, mostly because "a verbal record
      > is
      > too<BR>
      > > intangible."<BR>
      > > <BR>
      > > <BR>
      > > <BR>
      > >
      >
      __________________________________________________<BR>
      > > Do you Yahoo!?<BR>
      > > Yahoo! Mail Plus - Powerful. Affordable. Sign
      > up<BR>
      > > now.<BR>
      > > <a
      >
      href="http://mailplus.yahoo.com">http://mailplus.yahoo.com</a><BR>
      > > <BR>
      > > To Post a message, send it to:  <BR>
      > > scrumdevelopment@...<BR>
      > > To Unsubscribe, send a blank message to:<BR>
      > > scrumdevelopment-unsubscribe@...<BR>
      > > <BR>
      > > Your use of Yahoo! Groups is subject to<BR>
      > > <a
      >
      href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/term
      s/</a><BR>
      > > <BR>
      > > <BR>
      > > <BR>
      > > To Post a message, send it to:  <BR>
      > > scrumdevelopment@...<BR>
      > > To Unsubscribe, send a blank message to:<BR>
      > > scrumdevelopment-unsubscribe@...<BR>
      > > <BR>
      > > Your use of Yahoo! Groups is subject to<BR>
      > > <a
      >
      href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/term
      s/</a><BR>
      > > <BR>
      > > <BR>
      > > <BR>
      > > <BR>
      > > <BR>
      > > To Post a message, send it to:  <BR>
      >
      === message truncated ===

      =====
      ==Paul

      __________________________________________________
      Do you Yahoo!?
      Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
      http://mailplus.yahoo.com

      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/
    • Mike Beedle
      ... Mike Cohn wrote: Here s an interesting bit of math though that shows that if the $23 million project was managed via Scrum it could end up with 1000
      Message 2 of 24 , Dec 12, 2002
      • 0 Attachment
        --- Mike Cohn <mike@...> wrote:
        Mike Cohn wrote:
        Here's an interesting bit of math though that shows
        that if the $23<BR>
        million project was managed via Scrum it could end up
        with 1000 pages.<BR>
        Let's assume 200 people on the project for 12 months.
        200 people would<BR>
        be roughly 25 scrum teams. Each month each scrum team
        produces a sprint<BR>
        backlog (a list of "requirements" they'll
        fulfill that sprint). That's<BR>
        13 sprints/year times 25 teams or 325 individual
        sprints. If each sprint<BR>
        kept it's sprint backlog (for any of a variety of
        reasons) and one page<BR>
        summarizing the results of the sprint and one other
        page we'd have 975<BR>
        pages!!<BR>
        <BR>
        -Mike<BR>
        <BR>
        1 page x 100 x 12<BR>
        <BR>


        Mike:

        Ah, but there is a difference on _how_ the "Scrum
        1000 page requirements document" was put together;
        and in turn, _how_ the software was put togehter;
        because it was as _evolved_, _reprioritized_,
        _tested_, _integrated_, and _developed iteratively_
        through customer feedback while ensuring the comfort
        of the developers.

        To be able to do that you need:

        - short time-boxing
        - constant people interactions
        - shared values than promote cooperation
        - self-organizing behavior
        - constant learning
        - knowledge sharing
        - a license to do research and be creative
        - etc.
        - (and all of the other things that synergistically
        contribute to create a true agile environment)

        Yes, I know -- I am preaching to the choir, I just
        want
        to underline that the _how_ is perhaps very important,

        - Mike
      • Mike Cohn
        Absolutely, Absolutly! And even using the example I gave we d only get 75 pages of paper per month for a 200 person team. -Mike ... From: Mike Beedle
        Message 3 of 24 , Dec 12, 2002
        • 0 Attachment
          Absolutely, Absolutly!

          And even using the example I gave we'd only get 75 pages of paper per
          month for a 200 person "team."

          -Mike

          -----Original Message-----
          From: Mike Beedle [mailto:beedlem@...]
          Sent: Thursday, December 12, 2002 6:28 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: RE: [scrumdevelopment] Waterfall and Dr. Winston Royce


          --- Mike Cohn <mike@...> wrote:
          Mike Cohn wrote:
          Here's an interesting bit of math though that shows
          that if the $23<BR>
          million project was managed via Scrum it could end up
          with 1000 pages.<BR>
          Let's assume 200 people on the project for 12 months.
          200 people would<BR>
          be roughly 25 scrum teams. Each month each scrum team
          produces a sprint<BR>
          backlog (a list of "requirements" they'll
          fulfill that sprint). That's<BR>
          13 sprints/year times 25 teams or 325 individual
          sprints. If each sprint<BR>
          kept it's sprint backlog (for any of a variety of
          reasons) and one page<BR>
          summarizing the results of the sprint and one other
          page we'd have 975<BR>
          pages!!<BR>
          <BR>
          -Mike<BR>
          <BR>
          1 page x 100 x 12<BR>
          <BR>


          Mike:

          Ah, but there is a difference on _how_ the "Scrum
          1000 page requirements document" was put together;
          and in turn, _how_ the software was put togehter;
          because it was as _evolved_, _reprioritized_,
          _tested_, _integrated_, and _developed iteratively_
          through customer feedback while ensuring the comfort
          of the developers.

          To be able to do that you need:

          - short time-boxing
          - constant people interactions
          - shared values than promote cooperation
          - self-organizing behavior
          - constant learning
          - knowledge sharing
          - a license to do research and be creative
          - etc.
          - (and all of the other things that synergistically
          contribute to create a true agile environment)

          Yes, I know -- I am preaching to the choir, I just
          want
          to underline that the _how_ is perhaps very important,

          - 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/
        • Mary Poppendieck
          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
          Message 4 of 24 , Dec 12, 2002
          • 0 Attachment

            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

             

             

               From: "Ken Schwaber <ken.schwaber@...>" <ken.schwaber@...>

            Subject: Waterfall and Dr. Winston Royce

             

            At recent conferences, especially OOPSLA, I and others in the agile

            community were taken to task for not learning from history.

            Specifically, we were castigated for creating a them/us divide

            between prior delopment processes and agile processes. We were

            advised that we could only have done this division through ignorance,

            since the previous efforts contained many of the elements and,

            perhaps, even the essence of agility.

             

            At OOPSLA, we defined the essence of agility as the ability to be

            creative, to determine the right thing to do and then do it. Other

            aspects, such as iterations, increments, self-organization,

            emergence, collaboration were important supports, but without the

            creativity, agile

            loses its heart.

             

            So, when I was directed to the seminal papers on waterfall, I was

            quite hopeful to learn from my mistakes. After all, I had

            implemented numerous waterfall methodologies, including SADM, SSDM,

            SDM, Navigator, ForeFront, Method/1, and Summit. And none of them

            were agile or had the attributes of agile. But, I was advised that

            these were improper implementations of the paper that Dr. Winston

            Royce published in 1970, which included such agile mechanisms as

            iterations and complete freedom to move up and down within the

            waterfall.

             

            So I read the paper, "Managing The Development of Large Software

            Systems" which is available in the Session 9 ISCE ACM archives. Dr.

            Royce wrote the paper based on his 9 years of experience in

            spacecraft planning, command and post-flight analysis systems. His

            first comment was that "analysis and coding" are the essential steps

            to an development effort "which involve genuinely creative work which

            directly contributes to the usefulness of the final product." He then

            goes on to undercut this by saying "Many additional development steps

            are required, none contribute as directly to the final product as

            analysis and coding, and all drive up the development costs."

             

            Dr. Royce then goes on to describe a very extensive waterfall model

            for development. Iteration is allowed, but only "iteration with the

            preceding and succeeding steps (phases) but rarely with more remote

            steps in the sequence. The virtue of all of this is that as the

            design proceeds the change process is scope DOWN to manageable

            limits."

             

            Documentation - Dr. Royce, "My own view is quite a lot...the first

            rule of managing software development is ruthless enforcement of

            documentation requirements ... Management of software is simply

            impossible without a very high degree of documentation." Dr. Royce

            indicates that a 1000 page spec document is appropriate for a $5m

            project, mostly because "a verbal record is too intangible."

             

            Dr Royce's paper brings forth many sound concepts, such as get a

            formal structure, clear delineration of types of work, and roles.

            However, his paper is the mother of all waterfalls and the mother of

            all of the things which agile is intended to remedy. Great for the

            time, an important step forward, but not appropriate for most

            applications that I know about at this time.

             

            Ken

             

             

             

          • Adriano Comai
            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
            Message 5 of 24 , Dec 14, 2002
            • 0 Attachment
              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
            • 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.