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

R: R: [scrumdevelopment] Scrum and RUP

Expand Messages
  • Adriano Comai
    ... Marco, that s simply not true, believe me. Or, please, show me this well defined sequence. I ve never found it. In RUP there are only _examples_ of
    Message 1 of 3 , Jan 14, 2003
      > But RUP is an iterative process articulated in a well defined SEQUENCE of
      > activities.

      Marco,
      that's simply not true, believe me. Or, please, show me this well defined
      sequence. I've never found it. In RUP there are only _examples_ of
      workflows, and it is explicitly written that they are _examples_.

      Adriano Comai
      http://www.analisi-disegno.com


      > -----Messaggio originale-----
      > Da: Marco Abis [mailto:abis@...]
      > Inviato: martedi 14 gennaio 2003 10.39
      > A: scrumdevelopment@yahoogroups.com
      > Oggetto: RE: R: [scrumdevelopment] Scrum and RUP
      >
      >
      > Dear Raul,
      >
      >
      > I think we need to remember what Ken wrote in the first
      > mail of this thread:
      >
      > "Let us hypothesize that having a Scrum plug-in for RUP is an idea worth
      > pursuing. Then I have the following questions:
      > 1. How good was the effort at the XP plug-in. Does it help or
      > hurt? Did the
      > greater distribution cause the essence of XP to be more widely
      > distributed,
      > or did the translation of XP into RUP cause XP to lose it's "soul?"
      > 2. Given the meta model of a process within Rose, that is used to generate
      > RUP, how can an agile process be effectively described? The models of
      > processes that we used in our process management software always revolved
      > around hierarchies or tasks, with the lowest level tasks having estimates,
      > roles, inputs, outputs, techniques and task descriptions. And, of course,
      > each of the roles, techniques, inputs, and outputs were further described.
      > Is this type of metaphor appropriate for agile processes, or does
      > this level
      > of delineation lead to them being fodder for M/S project,for "hands-off"
      > management, and for robotic tracking of plans while ignoring realities?
      > 3. If the first two questions are adequately addressed, what is
      > our best way
      > to proceed with the effort?"
      >
      > It seems to me you are identifing RUP and UML. RUP is the commercial
      > implementation of the Unified Process by Rational (it's a
      > product) while UML,
      > you know, is 'just' a language used to represent (mainly)
      > software systems.
      >
      > Drawing an UML diagram doesn't mean using RUP (neither UP). Of course
      > implementing RUP imply the use of UML.
      >
      > If you find a UML diagram useful to add some sort of value to
      > your effort then
      > use it! :-)
      >
      > But RUP is an iterative process articulated in a well defined SEQUENCE of
      > activities.
      >
      > This is the point IMHO: RUP is a flow while agile approaches accept the
      > non-linearity and unpredictability of the events. They are based
      > on different
      > principles and practices are instantiation of these principles.
      >
      > Ken question was about the usefulness (or not) of a Scrum plug-in
      > for RUP (the
      > 'RUP product' is a web-site full of guidelines, templates, etc,
      > etc you can
      > customize).
      >
      > IMHO you can of course write a Scrum Plug-in for RUP and it will
      > help those
      > using it (as Adriano wrote: 'Scrum does not need RUP. RUP needs Scrum
      > practices to be effective') but I think 'the translation of Scrum into RUP
      > will cause Scrum to lose it's "soul?"'
      >
      > Best regards :-)
      >
      > > I think Scrum practices can replace the Project Management discipline in
      > > RUP and at least in this sense can drive the other disciplines in the
      > > right way, not only more effective, more light ( including in the
      > > backlog sprint only the activities that adds value) but more agile too.
      > > If we really think we must draw a UML diagram, because it really adds
      > > value for this sprint or for documenting the system, we follow this in
      > > the scrum meetings, making the team collaborative with completing the
      > > artifact. I do not understand why we cannot say it is more agile.
      > >
      > > Raul Fernandez
      >
      > Marco Abis - CEO & Chairman
      > Agility SPI: Software Process Improvement
      > abis@... - abis@...
      > http://agilemovement.it
    • Marco Abis
      Ciao Adriano, this thread is becoming a flame and we are going off topic. If you want we could continue by private mail. However: a process which promises to
      Message 2 of 3 , Jan 14, 2003
        Ciao Adriano,

        this thread is becoming a flame and we are going off topic. If you want
        we could continue by private mail.

        However: a process which promises to "increase predictability of software
        development" and "Gives project managers control over schedules and
        deliverables" (taken from official Rational 'RUP presentation' -
        http://www.rational.com/media/products/rup/D174F_RUP.pdf) where control means
        "to be able to force" can try to let this managers believe this only providing
        them a way to plan every possible aspect ant then a way to execute them one
        after the other (otherwise it will not be so predictable as stated above).

        Andriano: I agree with you it is possible to buy RUP and customize it to make
        it more effective but this is not the point: RUP is not Agile and with such a
        kind of goals it will never be. Of course if you integrate it with practices
        from Scrum you can make it more effective.

        Good work

        P.S.: all the above IMHO :-)


        > Marco,
        > that's simply not true, believe me. Or, please, show me this well defined
        > sequence. I've never found it. In RUP there are only _examples_ of
        > workflows, and it is explicitly written that they are _examples_.


        Marco Abis - CEO & Chairman
        Agility SPI: Software Process Improvement
        abis@... - abis@...
        http://agilemovement.it
      • Alan Shalloway <alshall@netobjectives.co
        I was very surprised when I read Krutchen s Rational Unified Process and continued my surprise with Larman s Applying UML and Patterns. When you read these
        Message 3 of 3 , Jan 14, 2003
          I was very surprised when I read Krutchen's Rational Unified Process
          and continued my surprise with Larman's Applying UML and Patterns.
          When you read these books it sounds like RUP (or UP) applied
          correctly _is_ iterative and non-linear. Given all the heads down,
          high ceremony RUP implementations I have seen I almost couldn't
          believe they were talking about the Unified Process. But they are.
          Furthermore, talk to some Rational folks, and they'll mostly tell
          you RUP should be done in an agile way.

          Why it doesn't seem to happen isn't a myster either - just need to
          step back and think. RUP is expensive so it's adoption is usually
          mandated from above. "Here, buy these tools and use them." Now,
          we're no longer low ceremony because we have a lot of tools we've
          been mandated to use. Also, it's more acceptable to over-use in
          this culture than underuse -- "I used the tools and it didn't work"
          (like that makes any difference).

          I'm not saying I like RUP over Scrum or XP, but there are almost 2
          different kinds of RUP - 1) high ceremony, linear RUP that doesn't
          work and 2) agile, iterative RUP that can work.

          Alan Shalloway
          www.netobjectives.com

          --- In scrumdevelopment@yahoogroups.com, "Adriano Comai"
          <comai@t...> wrote:
          > > But RUP is an iterative process articulated in a well defined
          SEQUENCE of
          > > activities.
          >
          > Marco,
          > that's simply not true, believe me. Or, please, show me this well
          defined
          > sequence. I've never found it. In RUP there are only _examples_ of
          > workflows, and it is explicitly written that they are _examples_.
          >
          > Adriano Comai
          > http://www.analisi-disegno.com
          >
          >
          > > -----Messaggio originale-----
          > > Da: Marco Abis [mailto:abis@a...]
          > > Inviato: martedi 14 gennaio 2003 10.39
          > > A: scrumdevelopment@yahoogroups.com
          > > Oggetto: RE: R: [scrumdevelopment] Scrum and RUP
          > >
          > >
          > > Dear Raul,
          > >
          > >
          > > I think we need to remember what Ken wrote in the first
          > > mail of this thread:
          > >
          > > "Let us hypothesize that having a Scrum plug-in for RUP is an
          idea worth
          > > pursuing. Then I have the following questions:
          > > 1. How good was the effort at the XP plug-in. Does it help or
          > > hurt? Did the
          > > greater distribution cause the essence of XP to be more widely
          > > distributed,
          > > or did the translation of XP into RUP cause XP to lose
          it's "soul?"
          > > 2. Given the meta model of a process within Rose, that is used
          to generate
          > > RUP, how can an agile process be effectively described? The
          models of
          > > processes that we used in our process management software always
          revolved
          > > around hierarchies or tasks, with the lowest level tasks having
          estimates,
          > > roles, inputs, outputs, techniques and task descriptions. And,
          of course,
          > > each of the roles, techniques, inputs, and outputs were further
          described.
          > > Is this type of metaphor appropriate for agile processes, or does
          > > this level
          > > of delineation lead to them being fodder for M/S
          project,for "hands-off"
          > > management, and for robotic tracking of plans while ignoring
          realities?
          > > 3. If the first two questions are adequately addressed, what is
          > > our best way
          > > to proceed with the effort?"
          > >
          > > It seems to me you are identifing RUP and UML. RUP is the
          commercial
          > > implementation of the Unified Process by Rational (it's a
          > > product) while UML,
          > > you know, is 'just' a language used to represent (mainly)
          > > software systems.
          > >
          > > Drawing an UML diagram doesn't mean using RUP (neither UP). Of
          course
          > > implementing RUP imply the use of UML.
          > >
          > > If you find a UML diagram useful to add some sort of value to
          > > your effort then
          > > use it! :-)
          > >
          > > But RUP is an iterative process articulated in a well defined
          SEQUENCE of
          > > activities.
          > >
          > > This is the point IMHO: RUP is a flow while agile approaches
          accept the
          > > non-linearity and unpredictability of the events. They are based
          > > on different
          > > principles and practices are instantiation of these principles.
          > >
          > > Ken question was about the usefulness (or not) of a Scrum plug-in
          > > for RUP (the
          > > 'RUP product' is a web-site full of guidelines, templates, etc,
          > > etc you can
          > > customize).
          > >
          > > IMHO you can of course write a Scrum Plug-in for RUP and it will
          > > help those
          > > using it (as Adriano wrote: 'Scrum does not need RUP. RUP needs
          Scrum
          > > practices to be effective') but I think 'the translation of
          Scrum into RUP
          > > will cause Scrum to lose it's "soul?"'
          > >
          > > Best regards :-)
          > >
          > > > I think Scrum practices can replace the Project Management
          discipline in
          > > > RUP and at least in this sense can drive the other disciplines
          in the
          > > > right way, not only more effective, more light ( including in
          the
          > > > backlog sprint only the activities that adds value) but more
          agile too.
          > > > If we really think we must draw a UML diagram, because it
          really adds
          > > > value for this sprint or for documenting the system, we follow
          this in
          > > > the scrum meetings, making the team collaborative with
          completing the
          > > > artifact. I do not understand why we cannot say it is more
          agile.
          > > >
          > > > Raul Fernandez
          > >
          > > Marco Abis - CEO & Chairman
          > > Agility SPI: Software Process Improvement
          > > abis@a... - abis@a...
          > > http://agilemovement.it
        Your message has been successfully submitted and would be delivered to recipients shortly.