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

RE: [XP] What's biting these guys?

Expand Messages
  • Glen B. Alleman
    Responding to Ron... After listening to your XP talk in Longmont last month, the discussion of the C3 Project s termination cleared the air on many issues. Is
    Message 1 of 6 , Jun 1, 2001
      Responding to Ron...

      After listening to your XP talk in Longmont last month, the discussion of
      the C3 Project's termination cleared the air on many issues. Is it
      appropriate to repeat the same words here so everyone can understand in the
      way your audience did that XP process and XP team were not part of the
      problem but were the solution "mechanism"?

      Glen Alleman
      Niwot Ridge Consulting

      "You're going to make mistakes and many times act dumb, so
      you'd better learn to have a thick skin." - Mother Schellinger



      >-----Original Message-----
      >From: Ron Jeffries [mailto:ronjeffries@...]
      >Sent: Friday, June 01, 2001 4:29 AM
      >To: extremeprogramming@yahoogroups.com
      >Subject: Re: [XP] What's biting these guys?
      >
      >
      >Responding to Torben Wölm (10:39 AM 6/1/2001 +0200):
      >>Doug Rosenberg and Kendall Scott have an article on sdmagazine.com:
      >>
      >>"Give Them What They Want
      >>
      >>Requirements review is an essential part of the modeling process.
      >>Here's how to ensure that your use cases and the domain model
      >>work together to address the end users' functional requirements."
      >>
      >>http://www.sdmagazine.com/articles/2001/0106/0106c/0106c.htm
      >>
      >>The article features several shots at XP...
      >
      >I sent the following to the editors:
      >=====
      >Dear Editor:
      >
      >In Doug Rosenberg and Kendall Scott's article, "Give them What They Want",
      >their obligatory shot at XP and agile methods goes wide of the mark.
      >
      >They say: "One of the fundamental tenets of Extreme Programming (XP) is
      >that since requirements change every day, it doesn't make much
      >sense to try
      >to deal with them explicitly". This is no tenet of XP. We do deal with
      >requirements explicitly, with at least four of the twelve practices of XP:
      >
      >* On-Site Customer requires that an XP team have the full-time presence of
      >a responsible individual from the requirements side. We don't have a
      >document, we have someone who actually knows what is wanted.
      >
      >* Planning Game produces a Release Plan showing what requirements (we call
      >them User Stories) are currently contemplated for the next
      >official release
      >of the product. It also produces Iteration Plans, the on-site customer's
      >list of the requirements to build over the next couple of weeks.
      >
      >* Small Releases requires that the team deliver working software to the
      >customer, so that she can see what she is really getting.
      >
      >* And Acceptance Tests requires that the software pass tests that the
      >customer specifies, again to ensure that she is getting what she wants.
      >
      >All this takes place in a context that assumes that there will be learning
      >about what is really needed during the process and how much requirements
      >will cost to implement. Contrary to what Rosenberg and Scott say: We think
      >requirements will change as often as every day. Therefore we deal
      >with them
      >very explicitly as part of the XP process.
      >
      >The authors go on to say that following this approach loses the intense
      >face-to-face negotiation. I would politely suggest that full-time on-site
      >customer presence is more face to face than what they seem to be
      >recommending.
      >
      >The authors, never having visited the C3 project, then go on to
      >hypothesize
      >what may have affected it, and attribute its termination to "creeping
      >featuritis", suggesting that the programming team was adding "cool
      >features".
      >
      >XP teams don't add any features except those requested and scheduled by
      >their customer: in the case of C3, the individual in Payroll (not IT) who
      >was present all the time. At the time I left C3, there had been few if any
      >frivolous features requested or implemented. The customer was extremely
      >well-focused on business value, not frills. Rosenberg and Scott are far
      >wide of the mark.
      >
      >Overall, the article is interesting, though it does contemplate a process
      >much less focused on actual software deliverables than some of us might
      >prefer. The shots at XP are wide of the mark, reflecting little
      >understanding of what we teach, but offering a convenient opportunity to
      >have the word "extreme" in the article.
      >
      >Shots at XP are fine with me and all the XP proponents: it's not for
      >everyone, and we welcome chances to improve it. To help us improve it,
      >authors and editors ought to keep those shots accurate.
      >
      >Regards,
      >
      >Ron Jeffries
      >www.XProgramming.com
      >www.ObjectMentor.com
      >www.AgileAlliance.org
      >=======
      >
      >We'll see what they do.
      >
      >Regards,
      >
      >
      >
      >Ronald E Jeffries
      >http://www.XProgramming.com
      >http://www.objectmentor.com
      >History teaches us that men and nations behave wisely
      >once they have exhausted all alternatives. -- Abba Eban
      >
      >To Post a message, send it to: extremeprogramming@...
      >
      >To Unsubscribe, send a blank message to:
      >extremeprogramming-unsubscribe@...
      >
      >Don't miss XP UNIVERSE, the first US conference on XP and Agile
      >Methods. see www.xpuniverse.com for details and registration.
      >
      >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
    • Phlip
      ... Inside a terminated project itself, that s part of the visibility . -- Phlip phlip_cpp@my-deja.com ==============
      Message 2 of 6 , Jun 1, 2001
        Proclaimed Glen B. Alleman from the mountaintops:
        > Responding to Ron...
        >
        > After listening to your XP talk in Longmont last month, the discussion of
        > the C3 Project's termination cleared the air on many issues. Is it
        > appropriate to repeat the same words here so everyone can understand in the
        > way your audience did that XP process and XP team were not part of the
        > problem but were the solution "mechanism"?

        Inside a terminated project itself, that's part of the "visibility".

        --
        Phlip phlip_cpp@...
        ============== http://phlip.webjump.com ==============
        -- Personally qualified to snub Mensa --
      • Phlip
        ... This is how you dumbshits should write any article about XP. You find the nearest willing XP team, and your writers sit in with them, preferrably across an
        Message 3 of 6 , Jun 1, 2001
          > Dear Editor:

          This is how you dumbshits should write any article about XP.

          You find the nearest willing XP team, and your writers sit in with them,
          preferrably across an iteration transistion.

          The alternative is the equivalent of writing about open heart surgery after
          reading a bunch of insider case histories about it.

          --
          Phlip phlip_cpp@...
          ============== http://phlip.webjump.com ==============
          -- MCCD - Microsoft Certified Co-Dependent --
        • Ron Jeffries
          ... Might be. I have no idea what I said, however. Ronald E Jeffries http://www.XProgramming.com http://www.objectmentor.com
          Message 4 of 6 , Jun 1, 2001
            Responding to Glen B. Alleman (06:50 AM 6/1/2001 -0600):
            >After listening to your XP talk in Longmont last month, the discussion of
            >the C3 Project's termination cleared the air on many issues. Is it
            >appropriate to repeat the same words here so everyone can understand in the
            >way your audience did that XP process and XP team were not part of the
            >problem but were the solution "mechanism"?

            Might be. I have no idea what I said, however.



            Ronald E Jeffries
            http://www.XProgramming.com
            http://www.objectmentor.com
          • Don Wells
            They are trying to sell books and consulting services. I think that we need to stop concentrating on our anger for their obvious attempts to advertise their
            Message 5 of 6 , Jun 2, 2001
              They are trying to sell books and consulting services. I think that we need
              to stop concentrating on our anger for their obvious attempts to advertise
              their own products and instead focus on our amusement in the future when
              these two announce they are highly effective and experienced XP coaches.

              Much of what they say supports XP. They just have not realized where in
              their own methodology they have gone wrong. They need to realize that
              software is not really about modeling and simulation. Basing your design on
              real world objects doesn't do what they think it does. Introducing an
              object brick and an object mortar isn't going to keep requirements from
              changing.

              They have some interesting things to say about prototypes:

              "Always keep in mind that proof-of-concept prototypes are just like facade
              houses. What do you do if you have pointy-haired management that can't tell
              the difference? It's simple: Don't build your prototypes in code just work
              with pencil-and-paper line drawings."

              Exactly so, except that you can not learn anything from a pencil and paper
              prototype that is useful. You must do it in code. Eventually they will
              figure this out.

              But they do raise an interesting point about prototypes. It is very
              attractive to put a prototype into production. Unfortunately these authors
              do not have enough experience to understand how that happens. The best way
              to avoid it is to spend very little time on a prototype and to only build a
              prototype to demonstrate the solution to a very focused question. In other
              words a spike. Focus on a single problem or question and not simulate the
              entire system.

              They further demonstrate their ignorance in their discourse on prototypes as
              facades. A facade does not answer anyone's question, unless a facade is
              really what was desired. They use the metaphor of creating a movie set:

              "It's a lot like bringing in a construction crew to put up a movie set: They
              can build a "house" (actually a facade) that looks fantastic, in just a
              fraction of the time it takes to build a real house but it will lack a few
              minor details, like blueprints, electrical schematics and plumbing plans.
              Imagine trying to refactor this movie facade into a real house."

              If you are building a set you don't need to call the phone company to
              connect the phone. They seem to think you must have an entire house when
              all you wanted was the front. If I was their customer and I had hired them
              to create a movie set and found out several millions of dollars later they
              had created a small city I would be very, very, very angry. I think they
              know this.

              I do sympathize with Rosenberg and Scott. I used to refactor this way
              myself. I didn't understand the idea of slowly changing the design over a
              long time as things change. Instead I would throw the whole thing away and
              start over. This is what these two are talking about. They want us to
              build a system with the customer sitting next to us (much the same as we do
              in XP) and then refactor it by throwing it away and rebuilding. You don't
              need to do that if you have been testing it and refactoring it effectively
              as you go.

              I have no doubt that these two will come to see what is important in their
              method and what can be disposed of. They will come to see that XP is not
              entirely different from what they are advocating, it just has all the
              useless crap removed from it.

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