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

Re: XP weaknesses --- Fixed Price

Expand Messages
  • acockburn@aol.com
    I think I see where the difference is, Dominic, let s see if I can capture it... It looks to me as that you are thinking: (A) IF we re using XP, THEN it fits
    Message 1 of 5 , May 6, 2005
      I think I see where the difference is, Dominic, let's see if I can capture
      it...
      It looks to me as that you are thinking:
      (A) IF we're using XP, THEN it fits the fixed price-scene scene
      (which it doesn't, using your terms - large chunks of XP don't get exercised)
      but Ron and I are thinking:
      (B) IF we're in the fixed-price scene THEN XP (or what large chunks of
      it we can still use) works better that the alternatives.

      So we're okay with ignoring certain availabilities that XP otherwise might
      give us
      (like adding and replacing cards across iterations) in order to have access
      to
      other availabilities that XP gives us (like PP and refactoring and TDD and
      short iterations and ...)

      while it looks as though you are so unhappy with what gets cut out of XP
      that you wouldn't even call it XP any more. ... Trying that on for size for
      a minute, I'm guessing that in the fixed-price situation you'd still aim
      for short iterations, access to customer, PP, TDD, DTSTTCPW, refactoring,
      colocation? You'd still do the parts of XP that fit, even though you might
      have to call it WP instead.

      p.s. thanks for registering that you disagree about requirements
      gathering being outside XP. Until you wrote that I didn't notice.
      I thought this group was in general agreement with Ron about
      requirements gathering being outside XP.

      cheers


      <<


      >> I agree that the fp/s concept is a bad one, but if I
      >> were in that situation, I'd use XP to win.
      >
      > I agree with Ron.

      As I said only a month ago...
      http://groups.yahoo.com/group/extremeprogramming/message/105244

      ... I would also use, and have used, XP in a FP/S
      situation. However, I don't think XP's benefits are
      most apparent in that situation, nor is it easy for the
      XP spirit to prevail. I think XP with FP/S is a black
      diamond.


      >>


      [Non-text portions of this message have been removed]
    • acockburn@aol.com
      What s interesting to me about this section of the thread is that I came to the agile territory through the doorway marked efficiency not the doorway marked
      Message 2 of 5 , May 6, 2005
        What's interesting to me about this section of the thread is that I came to
        the agile territory through the doorway marked "efficiency" not the doorway
        marked "handle change". For my money, all the agile methods run more
        efficiently than their plan-centered counterparts through the reduced bureaucracy,
        rapid feedback and close communication, and that is all independent of whether
        someone is busy asking for changes or not. On the fp.s projects I've seen, the
        whole contract is so overloaded that any process inefficiencies make them
        nigh impossible. It takes a very efficient one for there to be even a hope of
        delivering on time.

        So to me it is a nearly irrelevant issue to discuss "handling change" in a
        fp/s situation, when there is so much to be gained just from reduced
        bureaucracy, rapid feedback and close communication.
        Alistair


        In a message dated 5/6/2005 8:03:24 A.M. Mountain Daylight Time,
        extremeprogramming@yahoogroups.com writes:


        This remark was preceded by the statement that you need to contractually
        agree to the "initial" scope and the procedure for negotiating changes in scope.
        This is absolutely necessary for a fp project under any methodology. Once
        that is in place, XP ability to accomodate change less expensively and to
        encourage change becomes an advantage.

        -----Original Message-----
        From: extremeprogramming@yahoogroups.com on behalf of Dominic Williams
        Sent: Fri 5/6/2005 12:37 AM
        To: extremeprogramming@yahoogroups.com
        Cc:
        Subject: Re: [XP] Re: XP weaknesses --- Fixed Price



        Steven Gordon wrote:

        > Tame fp/s projects are no big challenge for any
        > approach. [...] However, in the wild, what is
        > supposed to be a fp/s project usually turns out to be
        > a just a fp project.

        That is not only very true, but also intrinsically so:
        it's easy to fix the price, and almost impossible (not
        to mention not cost-effective and often undesirable) to
        fix scope because scope is intrisically vague (until
        you've got running software).

        > XP holds a big advantage when the customer (or
        > external forces) starts making unexpected requirement
        > changes, especially compared to non-agile approaches.

        I'm having trouble seeing XP's advantage here... XP's
        way of dealing with change is basically:

        1) be psychologically and technically prepared for it

        2) make its impact on cost and deadline very obvious,
        so that changes may be traded off against each
        other, or against time and cost.





        [Non-text portions of this message have been removed]
      • Ron Jeffries
        ... I m really not sure that I said that. I think I said, or tried to, that (a) requirements gathering is not discussed very much in the XP core literature. I
        Message 3 of 5 , May 7, 2005
          On Friday, May 6, 2005, at 10:50:42 AM, acockburn@... wrote:

          > p.s. thanks for registering that you disagree about requirements
          > gathering being outside XP. Until you wrote that I didn't notice.
          > I thought this group was in general agreement with Ron about
          > requirements gathering being outside XP.

          I'm really not sure that I said that. I think I said, or tried to,
          that (a) requirements gathering is not discussed very much in the XP
          core literature. I would go so far as to say that requirement
          gathering in XP is a sort of free variable that only has to meet
          certain constraints, such as those that Kent mentioned.

          I would point out that every XP and Agile practice is in large part
          free in the same sense. Call it Big Visible Chart, Information
          Radiator, or Informative Workspace -- we all have /examples/ of how
          to do it, and the XP / Agile instance defines a way that fits the
          idea and their needs.

          > Ron argued forcefully and without dissention from the group that
          > requirements gathering is strictly outside XP. Not seeing
          > disagreement on that view from the rest of this august body, I
          > accepted that position and now feel comfortable in writing,

          >> Now that we've established that requirements gathering is outside of XP,

          Now I did say:

          > Well, OK ... but it seems to me that XP starts /after/ there has
          > been enough requirements gathering to start. As far as I know, XP
          > does not address how to do requirements gathering. Maybe it should,
          > but ...
          >
          > ... why would we start before we had enough stories about which we
          > can answer questions ... and why do we need more than an iteration
          > or two's worth of stories in that state?

          ... and I wish I had more clearly said "[the] XP [literature] does
          not address," which was more like what I meant. I did comment a time
          or two that as I don't think XP is a thing, I don't think XP can
          address anything. Only its descriptions can address things, and in
          another sense of the word, its instances.

          > Oh, I just saw my mistake. Ron has already posted that XP is not
          > a 'thing' that can be described, and Kent has published that XP is his
          > way of reconciling humanity with productivity in software development
          > for himself and sharing that with others.
          >
          > I accidentally got suckered into the old thinking that XP is a thing
          > and thus one could discuss its weaknesses. Seeing the situation afresh,
          > I understand why I am feeling pulled around, and why much of this
          > discussion doesn't make any sense. Apologies, all.

          I may be taking it wrongly, but I take this as rather intense
          sarcasm. As far as I can tell, no Agile book nor spokesmodel,
          present company included, has presented Agile, or his own
          methodology, as a "thing" that can be precisely described, nor as an
          all-inclusive thing without a boundary.

          One of my favorite sigs, because it reminds me of something I often
          need to remember, is from Mary Doria Russel: "Wisdom begins when we
          discover the difference between 'That makes no sense' and 'I don't
          understand.'"

          Ron Jeffries
          www.XProgramming.com
          The work teaches us. -- Richard Gabriel
        • aacockburn
          ... wrote: I accidentally got suckered into the old thinking that XP is a thing ... afresh, ... You just fell into the hole of reading
          Message 4 of 5 , May 7, 2005
            --- In extremeprogramming@yahoogroups.com, Ron Jeffries
            <ronjeffries@X...> wrote:> > I accidentally got suckered into the old
            thinking that XP is a thing
            > > and thus one could discuss its weaknesses. Seeing the situation
            afresh,
            > > I understand why I am feeling pulled around, and why much of this
            > > discussion doesn't make any sense. Apologies, all.
            >
            > I may be taking it wrongly, but I take this as rather intense
            > sarcasm.

            You just fell into the hole of reading between the lines ;-)

            No sarcasm was intended. On some days I do recall that you and others
            on this list maintain that XP is not a thing, and on some days I
            don't. It is when I don't recall that that I get 'suckered' into
            thinking that one can discuss on this list XP as a thing - and that
            always comes around and hits me on the back of the head.

            (Just for the record, I *do* think that XP is a thing that can be
            described ((or at least it was until the interpretations multiplied
            to the point of making the term nearly meaningless)) --- so I have to
            deliberately set that belief aside when discussing with this group.)

            Alistair
          • Ron Jeffries
            ... I agree that we have a term XP and that we can describe our thoughts about it, and that we seem sometimes to be able to say that this idea is more like
            Message 5 of 5 , May 7, 2005
              On Saturday, May 7, 2005, at 12:47:29 PM, aacockburn wrote:

              > (Just for the record, I *do* think that XP is a thing that can be
              > described ((or at least it was until the interpretations multiplied
              > to the point of making the term nearly meaningless)) --- so I have to
              > deliberately set that belief aside when discussing with this group.)

              I agree that we have a term "XP" and that we can describe our
              thoughts about it, and that we seem sometimes to be able to say that
              this idea is more like the thing we're thinking about, and this
              other thing less like it.

              But I don't think there is a thing such that we can say, with any
              kind of certainty: this team is / is not doing XP.

              What kind of a thing to you think that XP is?

              Ron Jeffries
              www.XProgramming.com
              What is your dream? And knowing this, what have you
              done to work towards realizing it today? -- Les Brown
            Your message has been successfully submitted and would be delivered to recipients shortly.