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

Re: [XP] RUP vs. XP

Expand Messages
  • George Dinwiddie
    ... According to my understanding an online conversation I had with Grady Booch on this very some years back, it s incorrect if it s not iterative. - George --
    Message 1 of 17 , Apr 2, 2007
    • 0 Attachment
      JLStandley@... wrote:
      > I'm not sure it's using RUP "incorrectly" to do Waterfall. The team I
      > was on learned "RUP as Waterfall" directly from Rational Consultants ...
      > in 1996. RUP can be made to fit XP or other agile ways pretty well, but
      > it can go other directions, too.

      According to my understanding an online conversation I had with Grady
      Booch on this very some years back, it's incorrect if it's not iterative.

      - George

      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    • dnicolet99
      ... Consultants ... ... well, but ... iterative. ... A process can be a waterfall even if it s iterative.
      Message 2 of 17 , Apr 3, 2007
      • 0 Attachment
        --- In extremeprogramming@yahoogroups.com, George Dinwiddie
        <lists@...> wrote:
        >
        > JLStandley@... wrote:
        > > I'm not sure it's using RUP "incorrectly" to do Waterfall. The team I
        > > was on learned "RUP as Waterfall" directly from Rational
        Consultants ...
        > > in 1996. RUP can be made to fit XP or other agile ways pretty
        well, but
        > > it can go other directions, too.
        >
        > According to my understanding an online conversation I had with Grady
        > Booch on this very some years back, it's incorrect if it's not
        iterative.
        >
        > - George

        A process can be a waterfall even if it's iterative.
      • Ron Jeffries
        Hello, JLStandley. On Monday, April 2, 2007, at 7:21:17 PM, you ... RUP is inherently iterative. It explicitly calls for a software deliverable at the end of
        Message 3 of 17 , Apr 3, 2007
        • 0 Attachment
          Hello, JLStandley. On Monday, April 2, 2007, at 7:21:17 PM, you
          wrote:

          > I'm not sure it's using RUP "incorrectly" to do Waterfall. The team I
          > was on learned "RUP as Waterfall" directly from Rational Consultants ...
          > in 1996. RUP can be made to fit XP or other agile ways pretty well, but
          > it can go other directions, too.

          RUP is inherently iterative. It explicitly calls for a software
          deliverable at the end of each phase, and for a series of rolling
          development phases, each of which delivers software, as do the
          earlier inception phases and such.

          Analyze Design Code Test will not fit into RUP.

          Ron Jeffries
          www.XProgramming.com
          You can observe a lot by watching. --Yogi Berra
        • dnicolet99
          ... Consultants ... ... well, but ... And yet it seems as if most implementations of RUP do exactly that: Analyze Design Code Test, over and over
          Message 4 of 17 , Apr 3, 2007
          • 0 Attachment
            --- In extremeprogramming@yahoogroups.com, Ron Jeffries
            <ronjeffries@...> wrote:
            >
            > Hello, JLStandley. On Monday, April 2, 2007, at 7:21:17 PM, you
            > wrote:
            >
            > > I'm not sure it's using RUP "incorrectly" to do Waterfall. The team I
            > > was on learned "RUP as Waterfall" directly from Rational
            Consultants ...
            > > in 1996. RUP can be made to fit XP or other agile ways pretty
            well, but
            > > it can go other directions, too.
            >
            > RUP is inherently iterative. It explicitly calls for a software
            > deliverable at the end of each phase, and for a series of rolling
            > development phases, each of which delivers software, as do the
            > earlier inception phases and such.
            >
            > Analyze Design Code Test will not fit into RUP.
            >

            And yet it seems as if most implementations of RUP do exactly that:
            Analyze Design Code Test, over and over (iteratively).

            Why is that? Are there a lot of people who misunderstand RUP? Are
            there a lot of other people who misunderstand "iterative" to mean "not
            waterfall" by definition? Some of both, maybe?

            Dave
          • Fernando Rodrigues
            I think that one of the great mistakes when using RUP happens when people installs it, adding not culture to the team, but forcing the team to make all the
            Message 5 of 17 , Apr 3, 2007
            • 0 Attachment
              I think that one of the great mistakes when using RUP happens when people
              installs it, adding not culture to the team, but forcing the team to make
              all the artifacts and the activities through tailored disciplines (something
              that is completely wrong) at once. And I think that the easiest way to
              managers install RUP is in the waterfall manner, and is easier to "control"
              the process in a waterfall manner, using it in a iterative way is hard at
              first time, even to evolve from the waterfall to the iterative is hard if
              there is no commitment in the team to make it, specially when you have been
              trained in the waterfall way over the years.

              In the version of RUP that I have here the waterfall is called the "Grand
              Design" Lifecycle, "The traditional waterfall approach can be seen as a
              degenerated case in which there is only one iteration in the construction
              phase. It is called "grand design" in
              [DOD94<http://psds.portalcorporativo.serpro/rup/process/referenc.htm#DOD94>].
              In practice, it is hard to avoid additional iterations in the transition
              phase."

              As we can see, RUP considers the waterfall as a degenerated case.

              XP and other agiles approaches have the benefit to evolve slowly, adding
              practices as the team increases in experience. Unfortunately RUP is commonly
              added to the team as a whole, making hard to add all the activities at once,
              the easiest way to add this whole is in a waterfall manner, and this goes
              over the years in the team.

              The waterfall way occurs here in my company. And is hard to change the view
              of the company and from people (specially quality assurances) to work in a
              iterative way when they have been trained to work on the waterfall manner.

              Anyway, if is hard to understand what I'm saying, sorry for my English.

              Thanks,
              Fernando Rodrigues

              On 03 Apr 2007 05:35:22 -0700, dnicolet99 <dnicolet@...> wrote:
              >
              > --- In extremeprogramming@yahoogroups.com<extremeprogramming%40yahoogroups.com>,
              > Ron Jeffries
              > <ronjeffries@...> wrote:
              > >
              > > Hello, JLStandley. On Monday, April 2, 2007, at 7:21:17 PM, you
              > > wrote:
              > >
              > > > I'm not sure it's using RUP "incorrectly" to do Waterfall. The team I
              > > > was on learned "RUP as Waterfall" directly from Rational
              > Consultants ...
              > > > in 1996. RUP can be made to fit XP or other agile ways pretty
              > well, but
              > > > it can go other directions, too.
              > >
              > > RUP is inherently iterative. It explicitly calls for a software
              > > deliverable at the end of each phase, and for a series of rolling
              > > development phases, each of which delivers software, as do the
              > > earlier inception phases and such.
              > >
              > > Analyze Design Code Test will not fit into RUP.
              > >
              >
              > And yet it seems as if most implementations of RUP do exactly that:
              > Analyze Design Code Test, over and over (iteratively).
              >
              > Why is that? Are there a lot of people who misunderstand RUP? Are
              > there a lot of other people who misunderstand "iterative" to mean "not
              > waterfall" by definition? Some of both, maybe?
              >
              > Dave
              >
              >
              >


              [Non-text portions of this message have been removed]
            • JLStandley@comcast.net
              That s a fair correction, but I guess it s evolved since I claimed to be doing RUP. The whale chart has always shown most activities happening across phases,
              Message 6 of 17 , Apr 3, 2007
              • 0 Attachment
                That's a fair correction, but I guess it's evolved since I claimed to be
                "doing RUP." The whale chart has always shown most activities happening
                across phases, but when Rational taught it to us, the word "iteration"
                was not uttered. I could probably dig up a hundred page MS project plan
                that shows all the use cases, all the object analysis, all the
                robustness analysis, all the design, all the coding, all the testing in
                clear phases. Frequent Delivery of Running Tested Software was not to
                be seen. To be fair, the RUP may have been "beta" at the time but after
                that experience, the first time I heard Rational say that RUP could be
                tailored into XP I laughed out loud.

                Ancient history aside, today RUP and Open UP and so on can be just about
                as agile as you like.

                George Dinwiddie wrote:
                >
                > JLStandley@... <mailto:JLStandley%40comcast.net> wrote:
                > > I'm not sure it's using RUP "incorrectly" to do Waterfall. The team I
                > > was on learned "RUP as Waterfall" directly from Rational Consultants
                > ...
                > > in 1996. RUP can be made to fit XP or other agile ways pretty well, but
                > > it can go other directions, too.
                >
                > According to my understanding an online conversation I had with Grady
                > Booch on this very some years back, it's incorrect if it's not iterative.
                >
                > - George
                >
                > --
                > ----------------------------------------------------------
                > * George Dinwiddie * http://blog.gdinwiddie.com
                > <http://blog.gdinwiddie.com>
                > Software Development http://www.idiacomputing.com
                > <http://www.idiacomputing.com>
                > Consultant and Coach http://www.agilemaryland.org
                > <http://www.agilemaryland.org>
                > ----------------------------------------------------------
                >
                >
              • Seyit Caglar Abbasoglu
                It seems like, the main problem is the size of the waterfalls, not having waterfalls in the process. When size of the waterfalls increase the risk increases
                Message 7 of 17 , Apr 3, 2007
                • 0 Attachment
                  It seems like, the main problem is the size of the waterfalls, not having
                  waterfalls in the process. When size of the waterfalls increase the risk
                  increases to. I think any (really any) processes have waterfalls. For
                  example daily integrations are some kind of waterfall for me. Bu the
                  waterfalls in some agile processes are too tiny to recognize, and to be
                  considered as risks.

                  For me, waterfalls in RUP (as I know) is much smaller than a traditional
                  analyze, design, code, test process. I think this is a great improvement,
                  and decreases the risk noticeably.


                  A smart person once described RUP as a prescriptive process that takes
                  > an "iterative, requirements-driven, and architecture-centric
                  > approach." Agile development is an adaptive, customer-driven, and
                  > value-centric approach in which requirements are discovered through
                  > collaboration and architecture evolves through the addition of
                  > customer-requested features and refactoring. The two sound fairly
                  > different to me.
                  >
                  >
                  I think those values that you describe truly depend on the team. I see no
                  obstacle to use RUP in an adaptive, customer-driven and value-centric way in
                  which requirements are discovered through collaboration and architecture
                  evolves through the addition of
                  customer-requested features and refactoring. If I'm not mistaken books I
                  read about RUP were encouraging evolving requirements and evolving design.

                  But perhaps, that might be true, most RUP teams prefer the first approach
                  you described, which contradicts with Agile Manifesto as I interpreted.

                  On 03 Apr 2007 05:35:22 -0700, dnicolet99 <dnicolet@...> wrote:
                  >
                  > --- In extremeprogramming@yahoogroups.com<extremeprogramming%40yahoogroups.com>,
                  > Ron Jeffries
                  > <ronjeffries@...> wrote:
                  > >
                  > > Hello, JLStandley. On Monday, April 2, 2007, at 7:21:17 PM, you
                  > > wrote:
                  > >
                  > > > I'm not sure it's using RUP "incorrectly" to do Waterfall. The team I
                  > > > was on learned "RUP as Waterfall" directly from Rational
                  > Consultants ...
                  > > > in 1996. RUP can be made to fit XP or other agile ways pretty
                  > well, but
                  > > > it can go other directions, too.
                  > >
                  > > RUP is inherently iterative. It explicitly calls for a software
                  > > deliverable at the end of each phase, and for a series of rolling
                  > > development phases, each of which delivers software, as do the
                  > > earlier inception phases and such.
                  > >
                  > > Analyze Design Code Test will not fit into RUP.
                  > >
                  >
                  > And yet it seems as if most implementations of RUP do exactly that:
                  > Analyze Design Code Test, over and over (iteratively).
                  >
                  > Why is that? Are there a lot of people who misunderstand RUP? Are
                  > there a lot of other people who misunderstand "iterative" to mean "not
                  > waterfall" by definition? Some of both, maybe?
                  >
                  > Dave
                  >
                  >
                  >


                  [Non-text portions of this message have been removed]
                • Keith Ray
                  It happens often enough that a paper, that two RUP experts wrote How to Fail with RUP (by treating it as waterfall). The PDF paper can be found at:
                  Message 8 of 17 , Apr 3, 2007
                  • 0 Attachment
                    It happens often enough that a paper, that two RUP experts wrote "How
                    to Fail with RUP" (by treating it as waterfall). The PDF paper can be
                    found at:

                    http://www.agilealliance.org/show/941

                    On 03 Apr 2007 05:35:22 -0700, dnicolet99 <dnicolet@...> wrote:

                    > And yet it seems as if most implementations of RUP do exactly that:
                    > Analyze Design Code Test, over and over (iteratively).
                    >
                    > Why is that? Are there a lot of people who misunderstand RUP? Are
                    > there a lot of other people who misunderstand "iterative" to mean "not
                    > waterfall" by definition? Some of both, maybe?
                    >

                    --
                    C. Keith Ray
                    ----
                    I n d u s t r i a l L o g i c , I n c .
                    http://industriallogic.com
                    http://industrialxp.org
                    866-540-8336 (toll free)
                    510-540-8336 (phone)
                    Berkeley, California
                    ----
                    http://homepage.mac.com/keithray/blog/index.html
                  • dnicolet99
                    ... I disagree. In my view, a batch-and-queue process is inherently wasteful. We like to toss the word waterfall around, but I think it s more to the point
                    Message 9 of 17 , Apr 3, 2007
                    • 0 Attachment
                      --- In extremeprogramming@yahoogroups.com, "Seyit Caglar Abbasoglu"
                      <scabbasoglu@...> wrote:

                      > I think any (really any) processes have waterfalls.

                      I disagree. In my view, a batch-and-queue process is inherently
                      wasteful. We like to toss the word "waterfall" around, but I think
                      it's more to the point to talk about hand-offs and work queues,
                      especially when people assume a separate group of specialists must
                      deal with the contents of each work queue - requirements analysts,
                      testers, developers, etc.

                      It is very, very uncommon for organizations to use a process that
                      doesn't have some degree of batch-and-queue processing. The fact that
                      it's uncommon as of today's date doesn't mean it's inevitable for
                      "really any" process.

                      > For
                      > example daily integrations are some kind of waterfall for me.

                      Why don't you integrate more frequently, then? Or would that only make
                      the waterfall smaller?

                      >
                      > For me, waterfalls in RUP (as I know) is much smaller than a traditional
                      > analyze, design, code, test process. I think this is a great
                      improvement,
                      > and decreases the risk noticeably.

                      I agree. Iterative development is the single most powerful value-add
                      attribute of RUP. I just don't think it's the last word in process
                      improvement. I think it's possible to break out of the batch-and-queue
                      model altogether. That's not to say it would be easy or quick, but
                      it's possible.
                    • George Dinwiddie
                      ... Not by my definition of iterative. Incremental, yes, but iterative, no. -- ... * George Dinwiddie * http://blog.gdinwiddie.com
                      Message 10 of 17 , Apr 3, 2007
                      • 0 Attachment
                        dnicolet99 wrote:
                        > --- In extremeprogramming@yahoogroups.com, George Dinwiddie
                        > <lists@...> wrote:
                        >> JLStandley@... wrote:
                        >>> I'm not sure it's using RUP "incorrectly" to do Waterfall. The team I
                        >>> was on learned "RUP as Waterfall" directly from Rational
                        >>> Consultants ...
                        >>> in 1996. RUP can be made to fit XP or other agile ways pretty
                        >>> well, but
                        >>> it can go other directions, too.
                        >> According to my understanding an online conversation I had with Grady
                        >> Booch on this very some years back, it's incorrect if it's not
                        >> iterative.
                        >> - George
                        >
                        > A process can be a waterfall even if it's iterative.

                        Not by my definition of iterative. Incremental, yes, but iterative, no.

                        --
                        ----------------------------------------------------------------------
                        * George Dinwiddie * http://blog.gdinwiddie.com
                        Software Development http://www.idiacomputing.com
                        Consultant and Coach http://www.agilemaryland.org
                        ----------------------------------------------------------------------
                      • dnicolet99
                        ... the view ... work in a ... manner. I think many of us have had similar experiences. It s a great challenge to overcome many years of training and habit,
                        Message 11 of 17 , Apr 3, 2007
                        • 0 Attachment
                          --- In extremeprogramming@yahoogroups.com, "Fernando Rodrigues"
                          <fernando.rodrigues@...> wrote:
                          >
                          > The waterfall way occurs here in my company. And is hard to change
                          the view
                          > of the company and from people (specially quality assurances) to
                          work in a
                          > iterative way when they have been trained to work on the waterfall
                          manner.

                          I think many of us have had similar experiences. It's a great
                          challenge to overcome many years of training and habit, but the
                          rewards of success are also great.

                          > Anyway, if is hard to understand what I'm saying, sorry for my English.

                          You have nothing to apologize for. I wish I could communicate as well
                          in a second language. I admire you for that.

                          Dave
                        • dnicolet99
                          ... team I ... Grady ... What s your definition of iterative?
                          Message 12 of 17 , Apr 3, 2007
                          • 0 Attachment
                            --- In extremeprogramming@yahoogroups.com, George Dinwiddie
                            <lists@...> wrote:
                            >
                            > dnicolet99 wrote:
                            > > --- In extremeprogramming@yahoogroups.com, George Dinwiddie
                            > > <lists@> wrote:
                            > >> JLStandley@ wrote:
                            > >>> I'm not sure it's using RUP "incorrectly" to do Waterfall. The
                            team I
                            > >>> was on learned "RUP as Waterfall" directly from Rational
                            > >>> Consultants ...
                            > >>> in 1996. RUP can be made to fit XP or other agile ways pretty
                            > >>> well, but
                            > >>> it can go other directions, too.
                            > >> According to my understanding an online conversation I had with
                            Grady
                            > >> Booch on this very some years back, it's incorrect if it's not
                            > >> iterative.
                            > >> - George
                            > >
                            > > A process can be a waterfall even if it's iterative.
                            >
                            > Not by my definition of iterative. Incremental, yes, but iterative, no.
                            >

                            What's your definition of iterative?
                          • George Dinwiddie
                            ... Iterative involves going over the same ground, refining and adding functionality. Incremental involves building a piece at a time, but not going back to
                            Message 13 of 17 , Apr 3, 2007
                            • 0 Attachment
                              dnicolet99 wrote:
                              >>> A process can be a waterfall even if it's iterative.
                              >> Not by my definition of iterative. Incremental, yes, but iterative, no.
                              >>
                              >
                              > What's your definition of iterative?

                              Iterative involves going over the same ground, refining and adding
                              functionality. Incremental involves building a piece at a time, but not
                              going back to the previous pieces.

                              I had that conversation with Grady Booch when I was working for a
                              company "adopting RUP" but taking an incremental rather than iterative
                              approach. "First we'll design it all, then build this piece of the
                              design, then that piece of the design...." Grady assured me that this
                              approach was not RUP.

                              Unfortunately, many of the people I was working with didn't care much
                              about petty differences between iterative and incremental. They used
                              the words interchangeably, and to ill effect.

                              - George

                              --
                              ----------------------------------------------------------------------
                              * George Dinwiddie * http://blog.gdinwiddie.com
                              Software Development http://www.idiacomputing.com
                              Consultant and Coach http://www.agilemaryland.org
                              ----------------------------------------------------------------------
                            • dnicolet99
                              ... iterative, no. ... not ... Okay, I understand your definition and I see why you might correlate waterfall with incremental but not with iterative,
                              Message 14 of 17 , Apr 3, 2007
                              • 0 Attachment
                                --- In extremeprogramming@yahoogroups.com, George Dinwiddie
                                <lists@...> wrote:
                                >
                                > dnicolet99 wrote:
                                > >>> A process can be a waterfall even if it's iterative.
                                > >> Not by my definition of iterative. Incremental, yes, but
                                iterative, no.
                                > >>
                                > >
                                > > What's your definition of iterative?
                                >
                                > Iterative involves going over the same ground, refining and adding
                                > functionality. Incremental involves building a piece at a time, but
                                not
                                > going back to the previous pieces.

                                Okay, I understand your definition and I see why you might correlate
                                "waterfall" with "incremental" but not with "iterative," based on that
                                definition.

                                Thanks for the clarification.
                                Dave
                              • Scott Ambler
                                ... but not ... Confusing/comingling these two terms is a fairly common thing to do, and usually seems to lead to trouble. Years ago I argued that the term
                                Message 15 of 17 , Apr 4, 2007
                                • 0 Attachment
                                  --- In extremeprogramming@yahoogroups.com, George Dinwiddie
                                  <lists@...> wrote:
                                  >
                                  > Iterative involves going over the same ground, refining and adding
                                  > functionality. Incremental involves building a piece at a time,
                                  but not
                                  > going back to the previous pieces.

                                  Confusing/comingling these two terms is a fairly common thing to do,
                                  and usually seems to lead to trouble. Years ago I argued that the
                                  term "iteration" should really have been called increment because
                                  what we do is work on a new incremental release (often internal) of
                                  our system. Whether we work during that increment in
                                  waterfall/serial manner or in iterative manner is a separate issue.

                                  Unfortunately RUP socialialized this misuse of the term in the 1990s
                                  and several methods adopted it so I suspect we're stuck with it now
                                  forever. Other terms have been suggested over the years, in
                                  particular the word "cycle", but they've never caught on. Oh well.

                                  - Scott
                                Your message has been successfully submitted and would be delivered to recipients shortly.