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

great article on agile/waterfall re rup

Expand Messages
  • Alan Shalloway <alshall@netobjectives.co
    The title alone (How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering by Larman, Kruchten and Bittner) make this article worth
    Message 1 of 24 , Dec 14, 2002
    • 0 Attachment
      The title alone (How to Fail with the Rational Unified Process:
      Seven Steps to Pain and Suffering by Larman, Kruchten and Bittner)
      make this article worth reading ;) See
      http://www.dcs.bbk.ac.uk/~cc/courses/isad/articles/larman01howto.pdf

      However, on page 2 (Figure 1) there is a "Changing Requirements Are
      the Norm" graph which shows the bigger the project, the more the
      requirements change as a % of the original. This is precisely the
      point made earlier about why very large up-front requirements are
      virtually never that useful. If you really need them because the
      project is big, by the time you get to using them they are out of
      date. Nice to have some documentation about this.

      Great article - worth reading and recommending IMHO.

      Alan Shalloway
      CEO, Net Objectives
      www.netobjectives.com
    • Adriano Comai
      Alan, some time ago, I posted a reference to this article to the RUP-Forum, asking about why it was not published on Rational or Valtech websites. Some
      Message 2 of 24 , Dec 14, 2002
      • 0 Attachment
        Alan,

        some time ago, I posted a reference to this article to the RUP-Forum, asking
        about why it was not published on Rational or Valtech websites.

        Some Rational people answered they use it internally as a list of "process
        antipatterns".

        Philippe Krutchen said (I quote from his email):

        "And since we speak about this paper (How to fail with the RUP), for various
        reasons
        [...], mostly because of the possible misinterpretations and malicious
        misuses of what was initially thought as a "tongue in cheek" paper, we have
        not released it,
        and I still wonder how this draft ended up on this web site. "

        Anyway, on Rational restricted access website (www.rational.net) has been
        recently posted another interesting article about the same topics. It is by
        Black Diamond Software (a Rational Partner company), and you can find it
        (look under "white papers") at www.bds.com . They ask for your email to
        download it.

        Adriano Comai
        www.analisi-disegno.com

        > -----Messaggio originale-----
        > Da: Alan Shalloway <alshall@...>
        > [mailto:alshall@...]
        > Inviato: sabato 14 dicembre 2002 20.22
        > A: scrumdevelopment@yahoogroups.com
        > Oggetto: [scrumdevelopment] great article on agile/waterfall re rup
        >
        >
        > The title alone (How to Fail with the Rational Unified Process:
        > Seven Steps to Pain and Suffering by Larman, Kruchten and Bittner)
        > make this article worth reading ;) See
        > http://www.dcs.bbk.ac.uk/~cc/courses/isad/articles/larman01howto.pdf
        >
        > However, on page 2 (Figure 1) there is a "Changing Requirements Are
        > the Norm" graph which shows the bigger the project, the more the
        > requirements change as a % of the original. This is precisely the
        > point made earlier about why very large up-front requirements are
        > virtually never that useful. If you really need them because the
        > project is big, by the time you get to using them they are out of
        > date. Nice to have some documentation about this.
        >
        > Great article - worth reading and recommending IMHO.
        >
        > Alan Shalloway
        > CEO, Net Objectives
        > www.netobjectives.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/
        >
        >
      • Alan Shalloway
        Adriano: I appreciate this and have just seen BDS article as well because of it - thanks. I m surprised Philippe said that and if he is lurking here I d
        Message 3 of 24 , Dec 14, 2002
        • 0 Attachment
          Adriano:
          I appreciate this and have just seen BDS' article as well because of it
          - thanks.

          I'm surprised Philippe said that and if he is lurking here I'd
          appreciate his comments. Until a little over a year ago, I admit not
          knowing RUP very well and just dismissed it as a heavy methodology. I
          based this not on what I knew RUP to be but on the fact that every
          company I knew that followed RUP was mired in a heavyweight process. I
          even had a student who came to one of my design pattern classes say -
          "Please come to my firm, we've just implemented RUP and now all I do is
          documentation!"

          I finally decided I better actually learn something about it and read
          Philippe's great book and Larman's as well. At first I was skeptical -
          did Rational _really_ suggest RUP was agile? I finally had a great
          conversation with Gary Pollice and found out - yes!

          My opinion of RUP has changed considerably out of this (I still like
          Scrum best) and showing companies how to do RUP in an agile manner has
          now become a possibility.

          My point, however, is - since RUP _is_ so mis-applied, I think it is
          important to talk about this aspect of it so people become aware that
          this is _not_ what RUP is supposed to be. Without exposing this at
          every opportunity, many people will continue to be under a
          misunderstanding of what RUP is. Personally, I loved this article and
          think it was exceptionally written and would love for many "heavy
          weight" managers to read it.

          Alan Shalloway, Sr. Consultant, CEO
          office: 425-313-3065. mobile: 425-531-0810

          Net Objectives' vision is effective software development without
          suffering. Our mission is to assist software development teams in
          accomplishing this through a combination of training and mentoring.


          -----Original Message-----
          From: Adriano Comai [mailto:comai@...]
          Sent: Saturday, December 14, 2002 12:14 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: R: [scrumdevelopment] great article on agile/waterfall re rup

          Alan,

          some time ago, I posted a reference to this article to the RUP-Forum,
          asking
          about why it was not published on Rational or Valtech websites.

          Some Rational people answered they use it internally as a list of
          "process
          antipatterns".

          Philippe Krutchen said (I quote from his email):

          "And since we speak about this paper (How to fail with the RUP), for
          various
          reasons
          [...], mostly because of the possible misinterpretations and malicious
          misuses of what was initially thought as a "tongue in cheek" paper, we
          have
          not released it,
          and I still wonder how this draft ended up on this web site. "

          Anyway, on Rational restricted access website (www.rational.net) has
          been
          recently posted another interesting article about the same topics. It is
          by
          Black Diamond Software (a Rational Partner company), and you can find it
          (look under "white papers") at www.bds.com . They ask for your email to
          download it.

          Adriano Comai
          www.analisi-disegno.com

          > -----Messaggio originale-----
          > Da: Alan Shalloway <alshall@...>
          > [mailto:alshall@...]
          > Inviato: sabato 14 dicembre 2002 20.22
          > A: scrumdevelopment@yahoogroups.com
          > Oggetto: [scrumdevelopment] great article on agile/waterfall re rup
          >
          >
          > The title alone (How to Fail with the Rational Unified Process:
          > Seven Steps to Pain and Suffering by Larman, Kruchten and Bittner)
          > make this article worth reading ;) See
          > http://www.dcs.bbk.ac.uk/~cc/courses/isad/articles/larman01howto.pdf
          >
          > However, on page 2 (Figure 1) there is a "Changing Requirements Are
          > the Norm" graph which shows the bigger the project, the more the
          > requirements change as a % of the original. This is precisely the
          > point made earlier about why very large up-front requirements are
          > virtually never that useful. If you really need them because the
          > project is big, by the time you get to using them they are out of
          > date. Nice to have some documentation about this.
          >
          > Great article - worth reading and recommending IMHO.
          >
          > Alan Shalloway
          > CEO, Net Objectives
          > www.netobjectives.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/
          >
          >


          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
          Alan, I agree, and I m doing exactly the same thing, here in Italy. Adriano Comai www.analisi-disegno.com ... [...]
          Message 4 of 24 , Dec 14, 2002
          • 0 Attachment
            Alan,

            I agree, and I'm doing exactly the same thing, here in Italy.

            Adriano Comai
            www.analisi-disegno.com

            > -----Messaggio originale-----
            > Da: Alan Shalloway [mailto:alshall@...]
            > Inviato: domenica 15 dicembre 2002 3.28
            > A: scrumdevelopment@yahoogroups.com
            > Oggetto: RE: [scrumdevelopment] great article on agile/waterfall re rup

            [...]
            >
            > My opinion of RUP has changed considerably out of this (I still like
            > Scrum best) and showing companies how to do RUP in an agile manner has
            > now become a possibility.
            >
            > My point, however, is - since RUP _is_ so mis-applied, I think it is
            > important to talk about this aspect of it so people become aware that
            > this is _not_ what RUP is supposed to be. Without exposing this at
            > every opportunity, many people will continue to be under a
            > misunderstanding of what RUP is. Personally, I loved this article and
            > think it was exceptionally written and would love for many "heavy
            > weight" managers to read it.
            >
            > Alan Shalloway, Sr. Consultant, CEO
          • Ken Schwaber
            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
            Message 5 of 24 , Dec 15, 2002
            • 0 Attachment
              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?
              Ken



              -----Original Message-----
              From: Adriano Comai [mailto:comai@...]
              Sent: Sunday, December 15, 2002 2:35 AM
              To: scrumdevelopment@yahoogroups.com
              Subject: R: [scrumdevelopment] great article on agile/waterfall re rup


              Alan,

              I agree, and I'm doing exactly the same thing, here in Italy.

              Adriano Comai
              www.analisi-disegno.com

              > -----Messaggio originale-----
              > Da: Alan Shalloway [mailto:alshall@...]
              > Inviato: domenica 15 dicembre 2002 3.28
              > A: scrumdevelopment@yahoogroups.com
              > Oggetto: RE: [scrumdevelopment] great article on agile/waterfall re rup

              [...]
              >
              > My opinion of RUP has changed considerably out of this (I still like
              > Scrum best) and showing companies how to do RUP in an agile manner has
              > now become a possibility.
              >
              > My point, however, is - since RUP _is_ so mis-applied, I think it is
              > important to talk about this aspect of it so people become aware that
              > this is _not_ what RUP is supposed to be. Without exposing this at
              > every opportunity, many people will continue to be under a
              > misunderstanding of what RUP is. Personally, I loved this article and
              > think it was exceptionally written and would love for many "heavy
              > weight" managers to read it.
              >
              > Alan Shalloway, Sr. Consultant, CEO


              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
              Mike, It strikes me that one could substitute CMM or anyway PSP in your remarks below and about the same comments would hold. There is always wisdom in these
              Message 6 of 24 , Dec 15, 2002
              • 0 Attachment

                Mike,

                 

                It strikes me that one could substitute CMM or anyway PSP in your remarks below and about the same comments would hold.  There is always wisdom in these programs.  Problem is, when companies implement them, they focus on known demotivators (policy, supervision, administration) instead of known motivators (achievement, recognition, responsibility).  Generally this is not so much the fault of the program as it is the fact that the program readily lends itself to policy, supervision, and administration, while in and of itself, the program does not force an increase in achievement, recognition, and responsibility.

                 

                Mary Poppendieck

                www.poppendieck.com

                952-934-7998

                 

                   Date: Sat, 14 Dec 2002 18:28:22 -0800

                   From: "Alan Shalloway" <alshall@...>

                Subject: RE: great article on agile/waterfall re rup

                 

                Until a little over a year ago, I admit not

                knowing RUP very well and just dismissed it as a heavy methodology.  I

                based this not on what I knew RUP to be but on the fact that every

                company I knew that followed RUP was mired in a heavyweight process.  I

                even had a student who came to one of my design pattern classes say -

                "Please come to my firm, we've just implemented RUP and now all I do is

                documentation!"

                 

                I finally decided I better actually learn something about it and read

                Philippe's great book and Larman's as well.  At first I was skeptical -

                did Rational _really_ suggest RUP was agile?  I finally had a great

                conversation with Gary Pollice and found out - yes! 

                 

                My opinion of RUP has changed considerably out of this (I still like

                Scrum best) and showing companies how to do RUP in an agile manner has

                now become a possibility.

                 

                My point, however, is - since RUP _is_ so mis-applied, I think it is

                important to talk about this aspect of it so people become aware that

                this is _not_ what RUP is supposed to be.  Without exposing this at

                every opportunity, many people will continue to be under a

                misunderstanding of what RUP is.  Personally, I loved this article and

                think it was exceptionally written and would love for many "heavy

                weight" managers to read it.

                 

                Alan Shalloway, Sr. Consultant, CEO

                office: 425-313-3065. mobile: 425-531-0810

                 

                 

              • Alan Shalloway
                Mary: I do see how you can do PSP in an agile way, but I don t see how to do CMM in an agile way. Also, the point is that the people who developed the Unified
                Message 7 of 24 , Dec 15, 2002
                • 0 Attachment

                  Mary:
                  I do see how you can do PSP in an agile way, but I don’t see how to do CMM in an agile way.  Also, the point is that the people who developed the Unified Process _meant_ it to be agile while the people who developed SEI-CMM did not.  That’s my main point anyway.

                   

                  Alan Shalloway, Sr. Consultant, CEO
                  office: 425-313-3065. mobile: 425-531-0810

                  Net Objectives' vision is effective software development without suffering. Our mission is to assist software development teams in accomplishing this through a combination of training and mentoring.

                  -----Original Message-----
                  From: Mary Poppendieck [mailto:mary@...]
                  Sent: Sunday, December 15, 2002 8:55 AM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: RE: [scrumdevelopment] great article on agile/waterfall re rup

                   

                  Mike,

                   

                  It strikes me that one could substitute CMM or anyway PSP in your remarks below and about the same comments would hold.  There is always wisdom in these programs.  Problem is, when companies implement them, they focus on known demotivators (policy, supervision, administration) instead of known motivators (achievement, recognition, responsibility).  Generally this is not so much the fault of the program as it is the fact that the program readily lends itself to policy, supervision, and administration, while in and of itself, the program does not force an increase in achievement, recognition, and responsibility.

                   

                  Mary Poppendieck

                  www.poppendieck.com

                  952-934-7998

                   

                     Date: Sat, 14 Dec 2002 18:28:22 -0800

                     From: "Alan Shalloway" <alshall@...>

                  Subject: RE: great article on agile/waterfall re rup

                   

                  Until a little over a year ago, I admit not

                  knowing RUP very well and just dismissed it as a heavy methodology.  I

                  based this not on what I knew RUP to be but on the fact that every

                  company I knew that followed RUP was mired in a heavyweight process.  I

                  even had a student who came to one of my design pattern classes say -

                  "Please come to my firm, we've just implemented RUP and now all I do is

                  documentation!"

                   

                  I finally decided I better actually learn something about it and read

                  Philippe's great book and Larman's as well.  At first I was skeptical -

                  did Rational _really_ suggest RUP was agile?  I finally had a great

                  conversation with Gary Pollice and found out - yes! 

                   

                  My opinion of RUP has changed considerably out of this (I still like

                  Scrum best) and showing companies how to do RUP in an agile manner has

                  now become a possibility.

                   

                  My point, however, is - since RUP _is_ so mis-applied, I think it is

                  important to talk about this aspect of it so people become aware that

                  this is _not_ what RUP is supposed to be.  Without exposing this at

                  every opportunity, many people will continue to be under a

                  misunderstanding of what RUP is.  Personally, I loved this article and

                  think it was exceptionally written and would love for many "heavy

                  weight" managers to read it.

                   

                  Alan Shalloway, Sr. Consultant, CEO

                  office: 425-313-3065. mobile: 425-531-0810

                   

                   


                  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.

                • Mike Cohn
                  I recently finished reading a draft of an upcoming book on agile techniques and the author says something along the lines of The only Gantt chart that makes
                  Message 8 of 24 , Dec 15, 2002
                  • 0 Attachment

                    I recently finished reading a draft of an upcoming book on agile techniques and the author says something along the lines of

                    “The only Gantt chart that makes any sense looks like this:

                    Analysis            |*************************************|

                    Design              |*************************************|

                    Coding              |*************************************|

                    Testing              |*************************************| 

                    (That’s supposed to be 4 bars all extending the full length of the project.)

                    My immediate thought was that was a picture of RUP! Draw those lines with a little waviness and a few trends up or down and it’s exactly what RUP appears mostly to have been intended as.

                    --Mike

                     

                    -----Original Message-----
                    From: Alan Shalloway [mailto:alshall@...]
                    Sent: Sunday, December 15, 2002 10:23 AM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: RE: [scrumdevelopment] great article on agile/waterfall re rup

                     

                    Mary:
                    I do see how you can do PSP in an agile way, but I don’t see how to do CMM in an agile way.  Also, the point is that the people who developed the Unified Process _meant_ it to be agile while the people who developed SEI-CMM did not.  That’s my main point anyway.

                     

                    Alan Shalloway, Sr. Consultant, CEO
                    office: 425-313-3065. mobile: 425-531-0810

                    Net Objectives' vision is effective software development without suffering. Our mission is to assist software development teams in accomplishing this through a combination of training and mentoring.

                    -----Original Message-----
                    From: Mary Poppendieck [mailto:mary@...]
                    Sent: Sunday, December 15, 2002 8:55 AM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: RE: [scrumdevelopment] great article on agile/waterfall re rup

                     

                    Mike,

                     

                    It strikes me that one could substitute CMM or anyway PSP in your remarks below and about the same comments would hold.  There is always wisdom in these programs.  Problem is, when companies implement them, they focus on known demotivators (policy, supervision, administration) instead of known motivators (achievement, recognition, responsibility).  Generally this is not so much the fault of the program as it is the fact that the program readily lends itself to policy, supervision, and administration, while in and of itself, the program does not force an increase in achievement, recognition, and responsibility.

                     

                    Mary Poppendieck

                    www.poppendieck.com

                    952-934-7998

                     

                       Date: Sat, 14 Dec 2002 18:28:22 -0800

                       From: "Alan Shalloway" <alshall@...>

                    Subject: RE: great article on agile/waterfall re rup

                     

                    Until a little over a year ago, I admit not

                    knowing RUP very well and just dismissed it as a heavy methodology.  I

                    based this not on what I knew RUP to be but on the fact that every

                    company I knew that followed RUP was mired in a heavyweight process.  I

                    even had a student who came to one of my design pattern classes say -

                    "Please come to my firm, we've just implemented RUP and now all I do is

                    documentation!"

                     

                    I finally decided I better actually learn something about it and read

                    Philippe's great book and Larman's as well.  At first I was skeptical -

                    did Rational _really_ suggest RUP was agile?  I finally had a great

                    conversation with Gary Pollice and found out - yes! 

                     

                    My opinion of RUP has changed considerably out of this (I still like

                    Scrum best) and showing companies how to do RUP in an agile manner has

                    now become a possibility.

                     

                    My point, however, is - since RUP _is_ so mis-applied, I think it is

                    important to talk about this aspect of it so people become aware that

                    this is _not_ what RUP is supposed to be.  Without exposing this at

                    every opportunity, many people will continue to be under a

                    misunderstanding of what RUP is.  Personally, I loved this article and

                    think it was exceptionally written and would love for many "heavy

                    weight" managers to read it.

                     

                    Alan Shalloway, Sr. Consultant, CEO

                    office: 425-313-3065. mobile: 425-531-0810

                     

                     


                    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.


                    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.

                  • Ron Jeffries
                    The following are my personal opinions and do not necessarily reflect those of Object Mentor or anyone else for that matter. Or even mine as of yesterday or
                    Message 9 of 24 , Dec 15, 2002
                    • 0 Attachment
                      The following are my personal opinions and do not necessarily reflect those of
                      Object Mentor or anyone else for that matter. Or even mine as of yesterday or
                      tomorrow.

                      On Sunday, December 15, 2002, at 11:53:07 AM, Ken Schwaber wrote:

                      > 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?"

                      The comments from Rational clearly did not reflect the soul. They do not get
                      "agile" in my opinion. Some of them seem to get the idea of doing more with
                      less, but the overall push of the company is to sell their services and to sell
                      Rose and such. With IBM, if they wind up at IBM, this will only become more true
                      in my opinion. Less process cannot become a goal of a company that wants to sell
                      more process-oriented products.

                      Their philosophy, again in my opinion, is based in large-systems experience,
                      old-style "up front" thinking, and a command and control orientation.

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

                      It is quite difficult to express XP inside the RUP. The issues revolve around
                      the fact that the RUP has "slots" which need filling in: some of these are roles
                      which must be reflected, and some are "artifacts" which need to be connected
                      back to the process.

                      > 3. If the first two questions are adequately addressed, what is our best way
                      > to proceed with the effort?

                      They will pay to have it done. If someone who really understands Scrum does not
                      help them, they will do it themselves or hire some hack to do it.

                      So it's almost a moral issue. My involvement with the RUP XP plugin was based on
                      my belief that it would be better with me than without me, and I think it is.
                      Even so, it is still a long way from expressing what XP is.

                      BTW, I didn't make a dime on it, and don't expect to. If I had my way, it would
                      not have happened. But if 'twere done, 'twere best done well.

                      Ron Jeffries
                      www.XProgramming.com
                      The rules are ways of thinking, not ways to avoid thinking.
                    • Alan Shalloway
                      I certainly would not try to do RUP-XP. That marriage never made sense to me and still doesn t. I also agree that the powers that be at Rational seem to
                      Message 10 of 24 , Dec 15, 2002
                      • 0 Attachment
                        I certainly would not try to do RUP-XP. That "marriage" never made
                        sense to me and still doesn't. I also agree that the powers that be at
                        Rational seem to miss the point of agile. However, the Rational
                        consultants (or at least several I've talked to) do get agile.

                        I have also had the sentiment that "If I had my way, it would
                        not have happened. But if 'twere done, 'twere best done well." The
                        problem with many RUP projects is that many times the dev team want to
                        be agile while management wants to do RUP. They don't really even care
                        so much about agile, but are following a mandate from above about RUP.

                        I know how I can make RUP agile, but I don't know how I can do XP under
                        RUP. Also, I personally don't think doing XP is so important - doing
                        agile is. XP is merely one of many ways to be agile.

                        Alan Shalloway, Sr. Consultant, CEO
                        office: 425-313-3065. mobile: 425-531-0810

                        Net Objectives' vision is effective software development without
                        suffering. Our mission is to assist software development teams in
                        accomplishing this through a combination of training and mentoring.


                        -----Original Message-----
                        From: Ron Jeffries [mailto:ronjeffries@...]
                        Sent: Sunday, December 15, 2002 12:48 PM
                        To: scrumdevelopment@yahoogroups.com
                        Subject: Re: [scrumdevelopment] Scrum and RUP

                        The following are my personal opinions and do not necessarily reflect
                        those of
                        Object Mentor or anyone else for that matter. Or even mine as of
                        yesterday or
                        tomorrow.

                        On Sunday, December 15, 2002, at 11:53:07 AM, Ken Schwaber wrote:

                        > 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?"

                        The comments from Rational clearly did not reflect the soul. They do not
                        get
                        "agile" in my opinion. Some of them seem to get the idea of doing more
                        with
                        less, but the overall push of the company is to sell their services and
                        to sell
                        Rose and such. With IBM, if they wind up at IBM, this will only become
                        more true
                        in my opinion. Less process cannot become a goal of a company that wants
                        to sell
                        more process-oriented products.

                        Their philosophy, again in my opinion, is based in large-systems
                        experience,
                        old-style "up front" thinking, and a command and control orientation.

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

                        It is quite difficult to express XP inside the RUP. The issues revolve
                        around
                        the fact that the RUP has "slots" which need filling in: some of these
                        are roles
                        which must be reflected, and some are "artifacts" which need to be
                        connected
                        back to the process.

                        > 3. If the first two questions are adequately addressed, what is our
                        best way
                        > to proceed with the effort?

                        They will pay to have it done. If someone who really understands Scrum
                        does not
                        help them, they will do it themselves or hire some hack to do it.

                        So it's almost a moral issue. My involvement with the RUP XP plugin was
                        based on
                        my belief that it would be better with me than without me, and I think
                        it is.
                        Even so, it is still a long way from expressing what XP is.

                        BTW, I didn't make a dime on it, and don't expect to. If I had my way,
                        it would
                        not have happened. But if 'twere done, 'twere best done well.

                        Ron Jeffries
                        www.XProgramming.com
                        The rules are ways of thinking, not ways to avoid thinking.


                        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
                        I ll try to comment. Adriano Comai www.analisi-disegno.com ... [AC] To Ken: I have seen the XP Plug-in, but I haven t analyzed it. If your question means how
                        Message 11 of 24 , Dec 15, 2002
                        • 0 Attachment
                          I'll try to comment.

                          Adriano Comai
                          www.analisi-disegno.com

                          > -----Messaggio originale-----
                          > Da: Ron Jeffries [mailto:ronjeffries@...]
                          > Inviato: domenica 15 dicembre 2002 21.48
                          > A: scrumdevelopment@yahoogroups.com
                          > Oggetto: Re: [scrumdevelopment] Scrum and RUP
                          >
                          >
                          > The following are my personal opinions and do not necessarily
                          > reflect those of
                          > Object Mentor or anyone else for that matter. Or even mine as of
                          > yesterday or
                          > tomorrow.
                          >
                          > On Sunday, December 15, 2002, at 11:53:07 AM, Ken Schwaber wrote:
                          >
                          > > 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?

                          [AC]
                          To Ken:
                          I have seen the XP Plug-in, but I haven't analyzed it. If your question
                          means "how good it describes XP principles and practices", I'm not able to
                          give an answer.

                          To Ron:
                          But you seem rather skeptical about it.

                          >>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?"
                          >
                          > The comments from Rational clearly did not reflect the soul. They
                          > do not get
                          > "agile" in my opinion. Some of them seem to get the idea of doing
                          > more with
                          > less, but the overall push of the company is to sell their
                          > services and to sell
                          > Rose and such. With IBM, if they wind up at IBM, this will only
                          > become more true
                          > in my opinion. Less process cannot become a goal of a company
                          > that wants to sell
                          > more process-oriented products.
                          >
                          > Their philosophy, again in my opinion, is based in large-systems
                          > experience,
                          > old-style "up front" thinking, and a command and control orientation.

                          [AC]
                          There has been some debate about it in the extremeprogramming mailing list,
                          about 2 months ago. I remember Ron denying the Plugin lost XP soul. On the
                          other hand, I'm not sure how wide the distribution of the RUP Plug-in for XP
                          may have been, up to now.

                          To Ron:
                          It's true, less process cannot become a goal for Rational-IBM. But a more
                          effective process is a goal for many users of the RUP, both developers and
                          managers.

                          > > 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?
                          >
                          > It is quite difficult to express XP inside the RUP. The issues
                          > revolve around
                          > the fact that the RUP has "slots" which need filling in: some of
                          > these are roles
                          > which must be reflected, and some are "artifacts" which need to
                          > be connected
                          > back to the process.

                          [AC]
                          I've not yet analyzed the Rational Process Workbench, the tool to make RUP
                          Plug-ins.
                          All I can say is:
                          - RUP has no estimates whatever
                          - RUP has no any manadatory role. Roles can be completely changed.
                          - RUP has no mandatory artifacts. Artifacts can be completely changed.
                          - The lowest level tasks can be at whatever level, you don't need to
                          decompose below the level you need to describe. I pull it just a little: if
                          a Sprint is a "task", you don't need to decompose it, if you don't think it
                          correct or useful.
                          - The same for roles: if a "team" is a role, you don't need to decompose it
                          further.
                          - I could easily think of mapping into a RUP Plug-in the drawing of the page
                          "What is Scrum?" at http://www.controlchaos.com , and the roles, tasks,
                          artifacts, guidelines described in Ken Schwaber and Mike Beedle book.

                          On the other hand, I think making an XP Plugin is more difficult than making
                          a Scrum Plugin: there are much more "disciplines" to change, adding and
                          removing (requirements, analysis and design, implementation, test, project
                          management) fo XP than for Scrum. In the case of Scrum, it seems to me it is
                          necessary to change a lot (adding and removing) in the project management
                          discipline, something in the requirements one. In the other disciplines,
                          there's only to remove.

                          > > 3. If the first two questions are adequately addressed, what is
                          > our best way
                          > > to proceed with the effort?
                          >
                          > They will pay to have it done. If someone who really understands
                          > Scrum does not
                          > help them, they will do it themselves or hire some hack to do it.

                          [AC] If we think the hypothesis of the plug-in stands, we've got to
                          understand the business case for the project, the roles involved, the
                          project team, etc. In the meanwhile, I can obviously take a deeper look at
                          the technical how-to about the Process Workbench.
                        • Adriano Comai
                          Alan, having been involved in many RUP customizations, I think RUP_Scrum makes sense (much more, in my opinion, than RUP-XP). RUP needs _exactly_ the Scrum
                          Message 12 of 24 , Dec 15, 2002
                          • 0 Attachment
                            Alan,

                            having been involved in many RUP customizations, I think RUP_Scrum makes
                            sense (much more, in my opinion, than RUP-XP).
                            RUP needs _exactly_ the Scrum practices to become agile.

                            As you know, many shops with an existing waterfall culture buy RUP as an
                            help to move towards a more effective development approach, and then misuse
                            it. We can show them papers about RUP failures and antipatterns, such as
                            that by Larman and Krutchen. Still better, we can help them with effective
                            practices, the ones from Scrum, that can be used to avoid those traps.

                            Adriano Comai
                            www.analisi-disegno.com

                            > -----Messaggio originale-----
                            > Da: Alan Shalloway [mailto:alshall@...]
                            > Inviato: domenica 15 dicembre 2002 22.03
                            > A: scrumdevelopment@yahoogroups.com
                            > Oggetto: RE: [scrumdevelopment] Scrum and RUP
                            >
                            >
                            > I certainly would not try to do RUP-XP. That "marriage" never made
                            > sense to me and still doesn't. I also agree that the powers that be at
                            > Rational seem to miss the point of agile. However, the Rational
                            > consultants (or at least several I've talked to) do get agile.
                            >
                            > I have also had the sentiment that "If I had my way, it would
                            > not have happened. But if 'twere done, 'twere best done well." The
                            > problem with many RUP projects is that many times the dev team want to
                            > be agile while management wants to do RUP. They don't really even care
                            > so much about agile, but are following a mandate from above about RUP.
                            >
                            > I know how I can make RUP agile, but I don't know how I can do XP under
                            > RUP. Also, I personally don't think doing XP is so important - doing
                            > agile is. XP is merely one of many ways to be agile.
                            >
                            > Alan Shalloway, Sr. Consultant, CEO
                            > office: 425-313-3065. mobile: 425-531-0810
                          • Alan Shalloway
                            Adriano: Thanks for confirming this. I forgot to be explicit, but something else I meant to say. You can take a committed dev group (most are) and have them
                            Message 13 of 24 , Dec 15, 2002
                            • 0 Attachment
                              Adriano:
                              Thanks for confirming this. I forgot to be explicit, but something else
                              I meant to say. You can take a committed dev group (most are) and have
                              them do RUP/Scrum in a way that an upper management that doesn't want to
                              hear about agile will accept. Things like daily meetings, information
                              radiators, getting feedback monthly, staying in touch with the customer,
                              all sound good ;) The fact is, management is not stupid. They just want
                              certain things and don't always know that they can get it with agile.

                              This is a little pre-mature to release, but here's a chapter discussing
                              this I've just put on our public wiki (Dan Rawsthorne and I are writing
                              a book on effective software development and this is a likely chapter).
                              See
                              http://www.netobjectivesbooks.com/N_O_BookFeedback_Wiki/owbase/ow.asp?Do
                              ntTryToSellXP

                              Alan Shalloway, Sr. Consultant, CEO
                              office: 425-313-3065. mobile: 425-531-0810

                              Net Objectives' vision is effective software development without
                              suffering. Our mission is to assist software development teams in
                              accomplishing this through a combination of training and mentoring.


                              -----Original Message-----
                              From: Adriano Comai [mailto:comai@...]
                              Sent: Sunday, December 15, 2002 2:49 PM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: R: [scrumdevelopment] Scrum and RUP

                              Alan,

                              having been involved in many RUP customizations, I think RUP_Scrum makes
                              sense (much more, in my opinion, than RUP-XP).
                              RUP needs _exactly_ the Scrum practices to become agile.

                              As you know, many shops with an existing waterfall culture buy RUP as an
                              help to move towards a more effective development approach, and then
                              misuse
                              it. We can show them papers about RUP failures and antipatterns, such as
                              that by Larman and Krutchen. Still better, we can help them with
                              effective
                              practices, the ones from Scrum, that can be used to avoid those traps.

                              Adriano Comai
                              www.analisi-disegno.com

                              > -----Messaggio originale-----
                              > Da: Alan Shalloway [mailto:alshall@...]
                              > Inviato: domenica 15 dicembre 2002 22.03
                              > A: scrumdevelopment@yahoogroups.com
                              > Oggetto: RE: [scrumdevelopment] Scrum and RUP
                              >
                              >
                              > I certainly would not try to do RUP-XP. That "marriage" never made
                              > sense to me and still doesn't. I also agree that the powers that be
                              at
                              > Rational seem to miss the point of agile. However, the Rational
                              > consultants (or at least several I've talked to) do get agile.
                              >
                              > I have also had the sentiment that "If I had my way, it would
                              > not have happened. But if 'twere done, 'twere best done well." The
                              > problem with many RUP projects is that many times the dev team want to
                              > be agile while management wants to do RUP. They don't really even
                              care
                              > so much about agile, but are following a mandate from above about RUP.
                              >
                              > I know how I can make RUP agile, but I don't know how I can do XP
                              under
                              > RUP. Also, I personally don't think doing XP is so important - doing
                              > agile is. XP is merely one of many ways to be agile.
                              >
                              > Alan Shalloway, Sr. Consultant, CEO
                              > office: 425-313-3065. mobile: 425-531-0810


                              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/
                            • Ron Jeffries
                              ... I think it describes XP fairly well given the constraints of the medium. But I don t feel that it gives the flavor of XP, its values and so on. ... The
                              Message 14 of 24 , Dec 15, 2002
                              • 0 Attachment
                                On Sunday, December 15, 2002, at 5:48:53 PM, Adriano Comai wrote:

                                > To Ken:
                                > I have seen the XP Plug-in, but I haven't analyzed it. If your question
                                > means "how good it describes XP principles and practices", I'm not able to
                                > give an answer.

                                > To Ron:
                                > But you seem rather skeptical about it.

                                I think it describes XP fairly well given the constraints of the medium. But I
                                don't feel that it gives the flavor of XP, its values and so on.

                                > [AC]
                                > There has been some debate about it in the extremeprogramming mailing list,
                                > about 2 months ago. I remember Ron denying the Plugin lost XP soul. On the
                                > other hand, I'm not sure how wide the distribution of the RUP Plug-in for XP
                                > may have been, up to now.
                                >
                                > To Ron:
                                > It's true, less process cannot become a goal for Rational-IBM. But a more
                                > effective process is a goal for many users of the RUP, both developers and
                                > managers.

                                The managers and spokespeople whom I have spoken with and sat on panels with and
                                the like all give lip service to light weight and agility. Then they say "But
                                ..." and go on to say that you need more design, more this, more that.

                                I don't expect that behavior to decline.

                                Ron Jeffries
                                www.XProgramming.com
                                One test is worth a thousand expert opinions.
                                -- Bill Nye (The Science Guy)
                              • capotribu <abis@agilemovement.it>
                                Hi everybody, ... I think it makes sense as long as you want to continue to use RUP. If you just want to implement an agile, effective ecosystem (in the
                                Message 15 of 24 , Dec 24, 2002
                                • 0 Attachment
                                  Hi everybody,

                                  --- "Adriano Comai" <comai@t...> wrote:
                                  > having been involved in many RUP customizations, I think RUP_Scrum makes
                                  > sense (much more, in my opinion, than RUP-XP).
                                  > RUP needs _exactly_ the Scrum practices to become agile.

                                  I think it makes sense as long as you "want" to continue to use RUP.
                                  If you "just" want to implement an agile, effective ecosystem (in the
                                  Highsmith' sense) I think you can leave RUP to those who prefer to
                                  have a plan that they will never respect :-)

                                  I know this statement might sound a fundamentalist one but I will try
                                  to explain why I think so (after years of effective RUP implementations!):

                                  RUP is fundamentally a very, very big framework you can (must!)
                                  customize to meet your needs. In the very first months of
                                  customization you usually spend your time cutting off things, docs,
                                  tasks, etc, etc from the RUP framework.

                                  This is because of the intent of RUP: to cover all the possible
                                  situations and every aspects of every possible development effort!

                                  After years of experience in this field if a friend of mine will ever
                                  introduce me a new metodology/process/something_else with such a
                                  target I would simply greet him and turn back to my work having no
                                  time to waste.

                                  But we are speaking about something from Booch, Jacobson and many
                                  other "gurus", something that is so close to the (actual) management
                                  perspective it is impossible to ignore.

                                  Here is the point: I will no spend time to write why managers like RUP
                                  but Scrum, like all the others Agile ecosystems, makes me think that
                                  what managers want is something that isn't really useful to deliver
                                  the right project and often is the first impediment to the project
                                  success.

                                  Why have I to spend a lot of months (before starting anything else) to
                                  cut off things from something when I can start with the smallest
                                  useful set of practices NOW and add, if I'll need and only if I'll
                                  really need, others in the future?

                                  I don't know if you have ever read something about Wolfram's work:
                                  every time you add a rule to a system you increase the complexity of
                                  the system itself but at a certain point adding rules do not increase
                                  complexity anymore (sorry for simplification and for bad English :-)).
                                  We can infer that managing a complex system does not need an
                                  equivalent complex method because at a certain point your effort to
                                  simplify the system will only increase YOUR work! You will need more
                                  work to manage YOU same work, and so on.

                                  OK, I don't want to be (too) verbose so just a note: of course you can
                                  successfully customize RUP to reach(?) the Scrum agility but why if
                                  you can reach better result with a different approach?

                                  Happy Xmas :-D

                                  Marco Abis - CEO & Chairman
                                  Agility SPI: Software Process Improvement
                                  abis@... - abis@...
                                  http://agilemovement.it
                                • Adriano Comai
                                  Marco, ... Yes. Scrum does not need RUP. RUP needs Scrum practices to be effective. ... You re right. In the best possible world, where your choices are not
                                  Message 16 of 24 , Dec 31, 2002
                                  • 0 Attachment
                                    Marco,

                                    > I think it makes sense as long as you "want" to continue to use RUP.

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

                                    > OK, I don't want to be (too) verbose so just a note: of course you can
                                    > successfully customize RUP to reach(?) the Scrum agility but why if
                                    > you can reach better result with a different approach?

                                    You're right. In the best possible world, where your choices are not
                                    constrained by previous ones, there is no reason to use RUP, if something
                                    else is better.
                                    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.

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

                                    > -----Messaggio originale-----
                                    > Da: capotribu <abis@...> [mailto:abis@...]
                                    > Inviato: martedi 24 dicembre 2002 19.33
                                    > A: scrumdevelopment@yahoogroups.com
                                    > Oggetto: Re: [scrumdevelopment] Scrum and RUP
                                    >
                                    >
                                    > Hi everybody,
                                    >
                                    > --- "Adriano Comai" <comai@t...> wrote:
                                    > > having been involved in many RUP customizations, I think RUP_Scrum makes
                                    > > sense (much more, in my opinion, than RUP-XP).
                                    > > RUP needs _exactly_ the Scrum practices to become agile.
                                    >
                                    > I think it makes sense as long as you "want" to continue to use RUP.
                                    > If you "just" want to implement an agile, effective ecosystem (in the
                                    > Highsmith' sense) I think you can leave RUP to those who prefer to
                                    > have a plan that they will never respect :-)
                                    >
                                    > I know this statement might sound a fundamentalist one but I will try
                                    > to explain why I think so (after years of effective RUP implementations!):
                                    >
                                    > RUP is fundamentally a very, very big framework you can (must!)
                                    > customize to meet your needs. In the very first months of
                                    > customization you usually spend your time cutting off things, docs,
                                    > tasks, etc, etc from the RUP framework.
                                    >
                                    > This is because of the intent of RUP: to cover all the possible
                                    > situations and every aspects of every possible development effort!
                                    >
                                    > After years of experience in this field if a friend of mine will ever
                                    > introduce me a new metodology/process/something_else with such a
                                    > target I would simply greet him and turn back to my work having no
                                    > time to waste.
                                    >
                                    > But we are speaking about something from Booch, Jacobson and many
                                    > other "gurus", something that is so close to the (actual) management
                                    > perspective it is impossible to ignore.
                                    >
                                    > Here is the point: I will no spend time to write why managers like RUP
                                    > but Scrum, like all the others Agile ecosystems, makes me think that
                                    > what managers want is something that isn't really useful to deliver
                                    > the right project and often is the first impediment to the project
                                    > success.
                                    >
                                    > Why have I to spend a lot of months (before starting anything else) to
                                    > cut off things from something when I can start with the smallest
                                    > useful set of practices NOW and add, if I'll need and only if I'll
                                    > really need, others in the future?
                                    >
                                    > I don't know if you have ever read something about Wolfram's work:
                                    > every time you add a rule to a system you increase the complexity of
                                    > the system itself but at a certain point adding rules do not increase
                                    > complexity anymore (sorry for simplification and for bad English :-)).
                                    > We can infer that managing a complex system does not need an
                                    > equivalent complex method because at a certain point your effort to
                                    > simplify the system will only increase YOUR work! You will need more
                                    > work to manage YOU same work, and so on.
                                    >
                                    > OK, I don't want to be (too) verbose so just a note: of course you can
                                    > successfully customize RUP to reach(?) the Scrum agility but why if
                                    > you can reach better result with a different approach?
                                    >
                                    > Happy Xmas :-D
                                    >
                                    > Marco Abis - CEO & Chairman
                                    > Agility SPI: Software Process Improvement
                                    > abis@... - abis@...
                                    > http://agilemovement.it
                                    >
                                  • Marco Abis
                                    Dear Adriano, ... You are right but effective doesn t imply agile . ... Of course you are describing the real world but it must be clear that improving a
                                    Message 17 of 24 , Dec 31, 2002
                                    • 0 Attachment
                                      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
                                    • Ron Jeffries
                                      ... Nice quote, Marco. Where did this appear? Thanks, Ron Jeffries www.XProgramming.com In programming, do, or undo. There is always try. --Yoda
                                      Message 18 of 24 , Dec 31, 2002
                                      • 0 Attachment
                                        On Tuesday, December 31, 2002, at 5:20:36 AM, Marco Abis wrote:

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

                                        Nice quote, Marco. Where did this appear?

                                        Thanks,

                                        Ron Jeffries
                                        www.XProgramming.com
                                        In programming, do, or undo. There is always try. --Yoda
                                      • Marco Abis
                                        Hi Ron, take a look here: http://www.crystalmethodologies.org/cgi/wiki?AgileVsSelfAdapting :-) ... Marco Abis - CEO & Chairman Agility SPI: Software Process
                                        Message 19 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 20 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 21 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 22 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 23 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 24 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.