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

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

Expand Messages
  • Ron Jeffries
    ... 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
    Message 1 of 6 , Jun 1, 2001
    • 0 Attachment
      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
    • 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 2 of 6 , Jun 1, 2001
      • 0 Attachment
        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 3 of 6 , Jun 1, 2001
        • 0 Attachment
          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 4 of 6 , Jun 1, 2001
          • 0 Attachment
            > 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 5 of 6 , Jun 1, 2001
            • 0 Attachment
              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 6 of 6 , Jun 2, 2001
              • 0 Attachment
                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.