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

Re: R: [scrumdevelopment] Scrum and RUP

Expand Messages
  • Marco Abis
    Hi Ron, take a look here: http://www.crystalmethodologies.org/cgi/wiki?AgileVsSelfAdapting :-) ... Marco Abis - CEO & Chairman Agility SPI: Software Process
    Message 1 of 24 , Dec 31, 2002
    • 0 Attachment
      Hi Ron,

      take a look here: http://www.crystalmethodologies.org/cgi/wiki?AgileVsSelfAdapting :-)

      >Nice quote, Marco. Where did this appear?


      Marco Abis - CEO & Chairman
      Agility SPI: Software Process Improvement
      abis@... - abis@...
      http://agilemovement.it
    • Raul Fernandez
      Dear friends: Altough since October 2001 we have introduced the practice of the Scrum in our group this is my first Write to this list. Please excuse for my
      Message 2 of 24 , Jan 13, 2003
      • 0 Attachment
        Dear friends:

        Altough since October 2001 we have introduced the practice of the Scrum
        in our group this is my first Write to this list. Please excuse for my
        bad english, perhaps I could not express very well.
        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

        -----Mensaje original-----
        De: Marco Abis [mailto:abis@...]
        Enviado el: martes, 31 de diciembre de 2002 5:21
        Para: scrumdevelopment@yahoogroups.com
        Asunto: Re: R: [scrumdevelopment] Scrum and RUP


        Dear Adriano,

        >Yes. Scrum does not need RUP. RUP needs Scrum practices to be
        >effective.

        You are right but "effective" doesn't imply "agile".

        >But there are many IT organizations using RUP in an ineffective way,
        >and Scrum could help them to improve. Sometimes it's difficult to tell
        >these organizations, who made huge investments into RUP: throw it off,
        >there are more effective approaches out there, try them instead. In
        >such cases, I believe, it is better to suggest an improvement using
        >agile practices in the context of the existing process.

        Of course you are describing the real world but it must be clear that
        improving a Defined-Process with some practices from an Agile-Process do
        not make it Agile: it can make the process more effective (as you
        correctly wrote) but you will still miss peculiarity of the Agile
        Approach.

        Jim Highsmith months ago wrote:

        "In some ways agility has nothing to do with the process itself, but
        with how it is implemented and the philosophy of those doing the
        implementing. [...] but on the whole, I've not run acrosss clients of
        mine who have RUP who think it is either agile or lightweight. But
        lightweight is only one aspect of agile, the other two are collaborative
        values and principles and a fundamental understanding of the
        unpredictability of project activities (althought outcomes can be
        achieved). Agile is much more than lighter documentation and fewer
        processes."

        I experienced a lot of clients (of mine, of course) professing they were
        implementing an "Agile version" of RUP but when I analysed their work I
        found they were just cutting off some documents feeling "more
        lightweight".

        I definitly think this is one of the main issues: a lot of people
        believe Agile means just less docs, they try to cut off some of their
        docs and then affirm Agile is nothing more than this. As stated by Jim:
        they are missing fundamental understanding of the unpredictability of
        project activities.

        Happy new year :-)

        P.S.: For those who haven't read it I suggest 'Agile Revolution' by Mike
        Beedle: http://c2.com/cgi/wiki?AgileRevolution


        Marco Abis - CEO & Chairman
        Agility SPI: Software Process Improvement
        abis@... - abis@...
        http://agilemovement.it


        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/
      • Marco Abis
        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
        Message 3 of 24 , Jan 14, 2003
        • 0 Attachment
          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
        • Raul Fernandez
          Dear Marco: Of course there is a big difference between UML and RUP. When I talk about a UML diagrams I mean an RUP artifact made by a RUP activity. I think
          Message 4 of 24 , Jan 14, 2003
          • 0 Attachment
            Dear Marco:

            Of course there is a big difference between UML and RUP.
            When I talk about a UML diagrams I mean an RUP artifact made by a RUP
            activity. I think like Adriano and Allan (and also Krutchen and several
            Rational folks) that RUP not only could be customized but must be.
            Indeed I think Scrum practics are a clean way to do it by almost
            replacing the activities of Project Management discipline.
            About the Ken first message (I did not see before)
            1. I really dont know if XP is better or worst by the XP plug-in in RUP.
            2. Yes I think there is a way to represent the Scrum Plug-in with the
            Rational Procces Workbench.
            3. IMHO You can considre another point of view. Why a Scrum Plug-in in
            RUP?. Why not a RUP plug-in in Scrum, or a XP plug-in in Scrum, or
            protototypical development(Genexus) plug-in in Scrum, or OMT plug-in in
            Scrum. We are developping a client server aplication (we have called
            Scrum Pro) and we have the RUP activities as a repository for the
            backlogs. When we are talking about adaptive process, we are mainly
            talking about adaptive process management.

            Best wishes:

            Raul

            -----Mensaje original-----
            De: Marco Abis [mailto:abis@...]
            Enviado el: martes, 14 de enero de 2003 4:39
            Para: scrumdevelopment@yahoogroups.com
            Asunto: 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



            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/
          • Ken Schwaber
            I really like the descriptionof RUP as a repository with applications for using it in a research or knowledge intensive mode. I proposed that to Rational a
            Message 5 of 24 , Jan 14, 2003
            • 0 Attachment
              I really like the descriptionof RUP as a repository with applications for
              using it in a research or knowledge intensive mode. I proposed that to
              Rational a year ago and haven't consulted there since.
              Ken

              -----Original Message-----
              From: Raul Fernandez [mailto:raul@...]
              Sent: Tuesday, January 14, 2003 2:51 PM
              To: scrumdevelopment@yahoogroups.com
              Subject: RE: R: [scrumdevelopment] Scrum and RUP


              Dear Marco:

              Of course there is a big difference between UML and RUP.
              When I talk about a UML diagrams I mean an RUP artifact made by a RUP
              activity. I think like Adriano and Allan (and also Krutchen and several
              Rational folks) that RUP not only could be customized but must be.
              Indeed I think Scrum practics are a clean way to do it by almost
              replacing the activities of Project Management discipline.
              About the Ken first message (I did not see before)
              1. I really dont know if XP is better or worst by the XP plug-in in RUP.
              2. Yes I think there is a way to represent the Scrum Plug-in with the
              Rational Procces Workbench.
              3. IMHO You can considre another point of view. Why a Scrum Plug-in in
              RUP?. Why not a RUP plug-in in Scrum, or a XP plug-in in Scrum, or
              protototypical development(Genexus) plug-in in Scrum, or OMT plug-in in
              Scrum. We are developping a client server aplication (we have called
              Scrum Pro) and we have the RUP activities as a repository for the
              backlogs. When we are talking about adaptive process, we are mainly
              talking about adaptive process management.

              Best wishes:

              Raul

              -----Mensaje original-----
              De: Marco Abis [mailto:abis@...]
              Enviado el: martes, 14 de enero de 2003 4:39
              Para: scrumdevelopment@yahoogroups.com
              Asunto: 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



              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/


              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/
            • Marco Abis
              Of course there is a big difference between UML and RUP. When I talk about a UML diagrams I mean an RUP artifact made by a RUP activity. OK, I imagined that
              Message 6 of 24 , Jan 14, 2003
              • 0 Attachment
                Of course there is a big difference between UML and RUP.
                When I talk about a UML diagrams I mean an RUP artifact made by a RUP
                activity.

                OK, I imagined that and I wrote about it just for clarity :-)

                I think like Adriano and Allan (and also Krutchen and several
                Rational folks) that RUP not only could be customized but must be.

                You are right. I was a RUP fan and I customized it for my company and many customers times (and times) ago. From this point of view all of you (Adriano, you and several Rational folks) are right: if you already have invested on RUP and you want to make it more effective using practices from Scrum and other Agile Approach you can achieve good result.

                "If you already have invested on RUP".

                Otherwise if I have to use practices from other approaches to make effective (sorry but I'm not able to say agile for the reason about principles I wrote in my previous mail) something is supposed to provide such a big variety of templates and alternatives all you need to do is picking up the best for you why don't I just use the "other approaches"?

                From this point of view (mine, of course) I find more interesting your proposal of RUP plug-in for Scrum. Something like xP@Scrum (http://www.controlchaos.com/xpScrum.htm)

                Nice to read you :-)

                Marco Abis - CEO & Chairman
                Agility SPI: Software Process Improvement
                abis@... - abis@...
                http://agilemovement.it
              Your message has been successfully submitted and would be delivered to recipients shortly.