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

RE: [agilealliance] XP Plugin for RUP

Expand Messages
  • Mike Cohn
    RUP is a very fascinating subject. It is almost always implemented as a waterfall (on the dozen or so RUP projects I ve seen and from I gather from talking to
    Message 1 of 3 , Oct 6, 2002
    • 0 Attachment
      RUP is a very fascinating subject. It is almost always implemented as a
      waterfall (on the dozen or so RUP projects I've seen and from I gather
      from talking to others) yet when I read the RUP book ("The Unified
      Software Development Process") I see ways I could manage a RUP project
      in what I'd consider a very agile manner.

      I don't really think the XP plugin "cuts the heart of agility" right out
      of XP. DSDM defines work products and roles and it is still generally
      thought of as an agile process. Even without defined roles most
      developers will gravitate toward one or more of the traditional software
      development roles. I'm working with a Scrum team right now and everyone
      on the team has an official HR title of "Software Engineer" (hmm, that's
      probably a bad title for any agile developer). There are no titles
      beyond that but the five developers on this team have migrated into very
      natural roles--one is clearly the architect of the system, one is
      responsible for the database, one has taken on primarily testing, one
      programmer has taken up the client side, and the last does the server.
      Yes, they self-organized into these roles per the normal Scrum roles. If
      I had made a bunch of HTML pages and said to the team "read these, they
      tell you what each 'role' on the project does, then sign up for various
      roles" I don't think it would have affected the team's organization.
      They'd still be free to pick and choose and change those roles per the
      needs of their project.

      On the other hand, if a project manager mandates who fills which roles
      and what deliverables come out and what those deliverables look like
      then the process has lost its agility. I don't see the XP Plugin as
      going anywhere near that far.

      Similar arguments can be made about the definition of work products. If
      they are given as examples and good ideas then I think they're great. In
      implementing Scrum with teams the team will frequently decide that a few
      design documents will be handy and they produce them. With some teams I
      will encourage them to describe their expectations in the form of a
      table of contents or list of issues to be addressed before they start
      the document. In some ways this is similar to test-driven
      development--how will I know this document is done unless I write its
      "tests" first? If the team agrees on a template for what they want in a
      design document before it's written it is much easier on the person
      writing the design. Of course he is free to add or remove and to still
      do whatever he wants but he knows the expectations of his
      reviewers/users. (So maybe the right way to think of the expectations of
      the design document is as "user stories.")

      I think there are two types of agility: macro-agility and micro-agility.
      Macro-agility is the agility of the project as a whole--how well it can
      avoid backing itself into a design corner, how well it can cope with
      sudden orthogonal requirements, etc. Micro-agility is the amount of
      flexibility in the day to day work. XP, for examples, makes significant
      tradeoffs from micro-agility for macro-agility. In XP I can't just
      decide to code at whim--I have to write tests first and find someone to
      pair with. That can be a serious crimp on how one likes to work.
      However, a great amount of macro-agility is gained via that tradeoff. I
      think it is perfectly reasonable to assume that other tradeoffs may
      exist--for example, maybe I can great macro-agility if I define a "Chief
      Architect" role as does FDD. It's when I push that definition too far
      and have Chief Architects who refuse to code and eventually get too far
      away from the code that I lose agility.

      Here's a question for you, Ken: My favorite sections in your book were
      the ones differentiating defined and empirical processes. That really
      helped me see why Scrum works (and I'd been using it before you're book
      so I knew it worked but I didn't really know why). In your book you tell
      a story about chemists at DuPont and why they need to use an empirical
      process in some cases (it's a simplification but generally when there's
      too much uncertainty). Is it fair to say, though, that those chemists
      would have preferred to use a defined process if they could gain enough
      knowledge about the chemical reactions?

      If that's true for the chemists it seems very true for Project Managers
      who will use RUP or the XP Plugin for RUP. They want a defined process,
      not an empirical one, and the real danger is that they take the XP
      Plugin and apply it as though it's a defined process. They forgot the
      uncertainty and vagueness around the process. It seems like this is
      what's happened with RUP in general. Grady's "Object Solutions" book
      (which I view as the main predecessor to RUP) is very agile, RUP can be
      agile but rarely is implemented that way. It's just easier for someone
      who is accustomed to defined process to implement RUP in a very
      waterfall manner.

      Bringing all this back to your conclusion: The Plugin is great for RUP,
      bad for XP. I totally agree with you on this. XP will be tried by some
      organizations who wouldn't have tried it otherwise. It will help
      somewhat but not all the way (XP will be viewed as a failure by them)
      but their engineering practices will be improved by some of the XP
      practices.

      --Mike


      -----Original Message-----
      From: Ken Schwaber [mailto:kschwaber@...]
      Sent: Friday, October 04, 2002 7:46 AM
      To: agilealliance@yahoogroups.com
      Subject: [agilealliance] XP Plugin for RUP

      I've been questioned recently about the xP plugin for the Rational
      Unified Process (RUP) that ObjectMentor recently created for
      Rational. It is only available currently for RUP customers with
      license ID's, but I got a pretty good feel for what and how this was
      done at a Rational demo site:
      http://www.rational.com/demos/viewlets/rup/xp_plugin/XP_PlugIn_Preview
      _viewlet.html

      We've been struggling for some time with the difference between
      traditional methodologies and agile methodologies. In my mind, this
      difference is primarily based in the process control theory division
      of defined vs empirical, that is: command and control vs emergent and
      adaptive. I've always viewed RUP as a traditional methodology, but
      one implemented in a hypertext tool rather than the traditional
      database. However, I've been pleased that the underlying principles
      that Grady Booch and others adhere to are very close to agile and
      that they are making efforts to "lighten" RUP.

      With this background, I was quite interested to look at the xP plugin
      for RUP. I came away with mixed feelings. On the positive side, I
      think that this plugin makes xP more understandable to people coming
      at it from a traditional command-and-control background, and that are
      trying to use xP within the RUP mindset. This will help
      institutionalize and cause acceptance of many of the excellent xP
      engineering practices.

      On the negative side, I think the xP plugin cuts the heart of agility
      right out of xP. Roles are identified and people asked to fulfill
      them. Workproducts (artifacts) are defined and are shown to be
      created sequentially - such as a user story is an output from a
      release plan. The inspect/adapt cycle is lost, and the still unknown
      mechanisms of emergence on which we all rely are turned into mini-
      machines that can be repeated over and over. That is, the xP plugin
      makes the systems development process look repeatable, CMM
      certifiable, and like something that anyone can plugin and run like a
      good command-and-control manager.

      The heart of xP that you read in the xP series of books and sense in
      conversations with Kent, Ron and Ward is lost in this translation. My
      biggest concern with the plugin is that xP will be co-opted by this
      commercialization of it. People will buy the plugin, implement it,
      improve their engineering practices with it, but in no way realize
      the spirit of it. The plugin is great for RUP, bad for xP. It reminds
      me of the commercialization of love on TV.

      I've never been shy in saying what I think. Take a look and let me
      know what you think.
      Ken Schwaber



      To unsubscribe from this group, send an email to:
      agilealliance-unsubscribe@yahoogroups.com



      Your use of Yahoo! Groups is subject to
      http://docs.yahoo.com/info/terms/
    • Ken Schwaber
      The reason that I used the strong phrase, cuts the heart out is exactly as you described. Project managers and people new to XP will follow the defined
      Message 2 of 3 , Oct 6, 2002
      • 0 Attachment
        The reason that I used the strong phrase, "cuts the heart out" is exactly as
        you described. Project managers and people new to XP will follow the defined
        structure and think that xP is another defined process. They will not have
        picked up on the distinction that only relatively simple projects, with very
        little people,technology and requirements complexity and change can use
        defined approaches. They will think that, since ObjectMentor and Rational
        says that xP works in this manner, that it must work in this manner. They
        will not use the constant inspection and adaptation required for complex
        processes. The next step, of course, is for the plug-in to go to the
        company's process group, where they will really nail it down as a defined
        process. This is a constant trend and evolution of things, from a general
        set of guidelines that require intelligence and collaboration to something
        that is considered "rent an intelligence", where you applied the defined
        process that someone else wrote and figure that - since they said it's ok -
        that you can just measure hours and report changes.

        The goal of all process engineering is to turn something into a defined
        process. Empirical processes take a lot more effort, thought, intelligence,
        and work. A defined process can be set up once and run over and over.
        However, the defined process has to produce a product of quality adequate to
        the customer. Therein lies the problem for DuPont's chemical engineers - the
        precision of the specifications for the polymers exceeds the specificity of
        the raw materials and their ability at this time to control the chemical
        processes, so they have to use an empirical approach. Whereever possible
        they use defined, because of the reduced costs. But, of course, once it's
        defined and can be done without intelligence, it is a commodity and DuPont
        can't charge for their chemical capability and skills. So, with the
        empirical process, you are saying that this is such a complex thing that
        intelligence, inspection, adaptation is required, so you get to charge more.

        I'm going to give a talk at XPDay in England in November that will address
        this topic. How the premature rush to "define" CMM and RUP as commodities
        that can be generally applied without thinking led to their turning into a
        pile of dust. And how exactly the same thing can happen to agile.

        Ken



        -----Original Message-----
        From: Mike Cohn [mailto:mike@...]
        Sent: Sunday, October 06, 2002 12:08 PM
        To: agilealliance@yahoogroups.com; scrumdevelopment@yahoogroups.com
        Subject: RE: [agilealliance] XP Plugin for RUP


        RUP is a very fascinating subject. It is almost always implemented as a
        waterfall (on the dozen or so RUP projects I've seen and from I gather
        from talking to others) yet when I read the RUP book ("The Unified
        Software Development Process") I see ways I could manage a RUP project
        in what I'd consider a very agile manner.

        I don't really think the XP plugin "cuts the heart of agility" right out
        of XP. DSDM defines work products and roles and it is still generally
        thought of as an agile process. Even without defined roles most
        developers will gravitate toward one or more of the traditional software
        development roles. I'm working with a Scrum team right now and everyone
        on the team has an official HR title of "Software Engineer" (hmm, that's
        probably a bad title for any agile developer). There are no titles
        beyond that but the five developers on this team have migrated into very
        natural roles--one is clearly the architect of the system, one is
        responsible for the database, one has taken on primarily testing, one
        programmer has taken up the client side, and the last does the server.
        Yes, they self-organized into these roles per the normal Scrum roles. If
        I had made a bunch of HTML pages and said to the team "read these, they
        tell you what each 'role' on the project does, then sign up for various
        roles" I don't think it would have affected the team's organization.
        They'd still be free to pick and choose and change those roles per the
        needs of their project.

        On the other hand, if a project manager mandates who fills which roles
        and what deliverables come out and what those deliverables look like
        then the process has lost its agility. I don't see the XP Plugin as
        going anywhere near that far.

        Similar arguments can be made about the definition of work products. If
        they are given as examples and good ideas then I think they're great. In
        implementing Scrum with teams the team will frequently decide that a few
        design documents will be handy and they produce them. With some teams I
        will encourage them to describe their expectations in the form of a
        table of contents or list of issues to be addressed before they start
        the document. In some ways this is similar to test-driven
        development--how will I know this document is done unless I write its
        "tests" first? If the team agrees on a template for what they want in a
        design document before it's written it is much easier on the person
        writing the design. Of course he is free to add or remove and to still
        do whatever he wants but he knows the expectations of his
        reviewers/users. (So maybe the right way to think of the expectations of
        the design document is as "user stories.")

        I think there are two types of agility: macro-agility and micro-agility.
        Macro-agility is the agility of the project as a whole--how well it can
        avoid backing itself into a design corner, how well it can cope with
        sudden orthogonal requirements, etc. Micro-agility is the amount of
        flexibility in the day to day work. XP, for examples, makes significant
        tradeoffs from micro-agility for macro-agility. In XP I can't just
        decide to code at whim--I have to write tests first and find someone to
        pair with. That can be a serious crimp on how one likes to work.
        However, a great amount of macro-agility is gained via that tradeoff. I
        think it is perfectly reasonable to assume that other tradeoffs may
        exist--for example, maybe I can great macro-agility if I define a "Chief
        Architect" role as does FDD. It's when I push that definition too far
        and have Chief Architects who refuse to code and eventually get too far
        away from the code that I lose agility.

        Here's a question for you, Ken: My favorite sections in your book were
        the ones differentiating defined and empirical processes. That really
        helped me see why Scrum works (and I'd been using it before you're book
        so I knew it worked but I didn't really know why). In your book you tell
        a story about chemists at DuPont and why they need to use an empirical
        process in some cases (it's a simplification but generally when there's
        too much uncertainty). Is it fair to say, though, that those chemists
        would have preferred to use a defined process if they could gain enough
        knowledge about the chemical reactions?

        If that's true for the chemists it seems very true for Project Managers
        who will use RUP or the XP Plugin for RUP. They want a defined process,
        not an empirical one, and the real danger is that they take the XP
        Plugin and apply it as though it's a defined process. They forgot the
        uncertainty and vagueness around the process. It seems like this is
        what's happened with RUP in general. Grady's "Object Solutions" book
        (which I view as the main predecessor to RUP) is very agile, RUP can be
        agile but rarely is implemented that way. It's just easier for someone
        who is accustomed to defined process to implement RUP in a very
        waterfall manner.

        Bringing all this back to your conclusion: The Plugin is great for RUP,
        bad for XP. I totally agree with you on this. XP will be tried by some
        organizations who wouldn't have tried it otherwise. It will help
        somewhat but not all the way (XP will be viewed as a failure by them)
        but their engineering practices will be improved by some of the XP
        practices.

        --Mike


        -----Original Message-----
        From: Ken Schwaber [mailto:kschwaber@...]
        Sent: Friday, October 04, 2002 7:46 AM
        To: agilealliance@yahoogroups.com
        Subject: [agilealliance] XP Plugin for RUP

        I've been questioned recently about the xP plugin for the Rational
        Unified Process (RUP) that ObjectMentor recently created for
        Rational. It is only available currently for RUP customers with
        license ID's, but I got a pretty good feel for what and how this was
        done at a Rational demo site:
        http://www.rational.com/demos/viewlets/rup/xp_plugin/XP_PlugIn_Preview
        _viewlet.html

        We've been struggling for some time with the difference between
        traditional methodologies and agile methodologies. In my mind, this
        difference is primarily based in the process control theory division
        of defined vs empirical, that is: command and control vs emergent and
        adaptive. I've always viewed RUP as a traditional methodology, but
        one implemented in a hypertext tool rather than the traditional
        database. However, I've been pleased that the underlying principles
        that Grady Booch and others adhere to are very close to agile and
        that they are making efforts to "lighten" RUP.

        With this background, I was quite interested to look at the xP plugin
        for RUP. I came away with mixed feelings. On the positive side, I
        think that this plugin makes xP more understandable to people coming
        at it from a traditional command-and-control background, and that are
        trying to use xP within the RUP mindset. This will help
        institutionalize and cause acceptance of many of the excellent xP
        engineering practices.

        On the negative side, I think the xP plugin cuts the heart of agility
        right out of xP. Roles are identified and people asked to fulfill
        them. Workproducts (artifacts) are defined and are shown to be
        created sequentially - such as a user story is an output from a
        release plan. The inspect/adapt cycle is lost, and the still unknown
        mechanisms of emergence on which we all rely are turned into mini-
        machines that can be repeated over and over. That is, the xP plugin
        makes the systems development process look repeatable, CMM
        certifiable, and like something that anyone can plugin and run like a
        good command-and-control manager.

        The heart of xP that you read in the xP series of books and sense in
        conversations with Kent, Ron and Ward is lost in this translation. My
        biggest concern with the plugin is that xP will be co-opted by this
        commercialization of it. People will buy the plugin, implement it,
        improve their engineering practices with it, but in no way realize
        the spirit of it. The plugin is great for RUP, bad for xP. It reminds
        me of the commercialization of love on TV.

        I've never been shy in saying what I think. Take a look and let me
        know what you think.
        Ken Schwaber



        To unsubscribe from this group, send an email to:
        agilealliance-unsubscribe@yahoogroups.com



        Your use of Yahoo! Groups is subject to
        http://docs.yahoo.com/info/terms/






        To unsubscribe from this group, send an email to:
        agilealliance-unsubscribe@yahoogroups.com



        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      • Ron Jeffries
        ... defined ... general ... something ... defined ... it s ok - ... You re a bitter, bitter man, Ken. ;- It is true that many people think as you describe. It
        Message 3 of 3 , Oct 6, 2002
        • 0 Attachment
          --- In scrumdevelopment@y..., "Ken Schwaber" <ken.schwaber@v...>
          wrote:
          > The next step, of course, is for the plug-in to go to the
          > company's process group, where they will really nail it down as a
          defined
          > process. This is a constant trend and evolution of things, from a
          general
          > set of guidelines that require intelligence and collaboration to
          something
          > that is considered "rent an intelligence", where you applied the
          defined
          > process that someone else wrote and figure that - since they said
          it's ok -
          > that you can just measure hours and report changes.

          You're a bitter, bitter man, Ken. ;->

          It is true that many people think as you describe. It is also true
          that many do not. The current very small software process group at
          Ford, for example, chartered to help the company do RUP, is staffed
          entirely by XP people. With XP identified as a valid form of RUP,
          they are in a position to install the practices there.

          My opinion is that we only learn that the "empirical" processes work
          through experience. No amount of reasoning can convince us that
          our "defined" process view is wrong.

          So my thrust, wherever I go, is to get teams to try the agile
          practices. Trying them, some of them, at least, will get it. I know
          no better way, though I'd be happy to learn one.

          We at OM had great concerns about doing the XP plug-in, for just the
          reasons you mention. (And because we feared that none of you would
          ever talk to us again.) My own view was simple: Rational clearly
          would put XP under RUP. If that was to be the case, I felt that we
          owed it to the universe to see that it was as good as possible.

          We've done the first cut, and we're hoping that the agile community
          will help us make it better.

          Regards,

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