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

Re: [scrumdevelopment] Re: (unknown)

Expand Messages
  • Tobias Mayer
    Embrace paradox. T. Ron Jeffries wrote: ... I don t know, because Tobias, who introduced the term, has just come out against XP,
    Message 1 of 26 , Dec 1, 2005
      Embrace paradox.
      T.

      Ron Jeffries <ronjeffries@...> wrote:
      On Thursday, December 1, 2005, at 3:30:43 PM, Stephen J. Bobick wrote:

      >>From: woynam <woyna@...>
      >>Because in many organizations, if you mention the word "XP", you'll
      >>have the door shut in your face.

      > Maybe because they associate "XP" with "catastrophic" destruction and "ashes" (but no Phoenix).

      > I wonder where they would get such an idea from?

      I don't know, because Tobias, who introduced the term, has just
      come out against XP, while I, who actually do support XP, suggested
      that the term wasn't ideal for most listeners.

      Most peculiar, Mama.

      Ron Jeffries
      www.XProgramming.com
      Hope is not a strategy. -- Michael Henos


      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



    • Ron Jeffries
      ... Look, two ducks! Ron Jeffries www.XProgramming.com Thousands of years ago, the first man discovered how to make fire. He was probably burned at the stake
      Message 2 of 26 , Dec 1, 2005
        On Thursday, December 1, 2005, at 6:06:02 PM, Tobias Mayer wrote:

        > Embrace paradox.

        Look, two ducks!

        Ron Jeffries
        www.XProgramming.com
        Thousands of years ago, the first man discovered how to make fire.
        He was probably burned at the stake he had taught his brothers to
        light - Howard Roark (The Fountainhead, Ayn Rand)
      • kipkruide
        ... wrote: Solution seems simple then does it not, don t use the term xp, after all it is the results that count. Though in my peculiar world of humour it
        Message 3 of 26 , Dec 2, 2005
          --- In scrumdevelopment@yahoogroups.com, Tobias Mayer <tobyanon@y...>
          wrote:

          Solution seems simple then does it not, don't use the term xp, after
          all it is the results that count.

          Though in my peculiar world of humour it would be fun to tell the
          execs they've been doing xp for the last year, just to see the look on
          their faces.

          >
          > I care. Because "doing XP" is a big turn off to many people; often,
          exactly because of all the hype. But unit testing, or adopting test
          driven development, or automating the build process, or improving
          one's refactoring practices (etc.) well, those things usually make
          sense to people - and they are willing to do them - adopting XP a
          slice at a time, as it were. So yes, it is important for developers
          to know that these practices are older than XP, that they preceded the
          branding. That way they can be discussed on their own merits. Don't
          throw away history for the sake of marketing.
          > Tobias (not a brand fan)
          >
          >
          > Jef L Newsom <jef@i...> wrote:
          > I was wondering the same thing. Is there a concern that the brand
          > diminishes the value somehow? The simple fact is that they *are* XP
          > engineering practices, since XP brands them as such, "The engineering
          > practices that compose XP." And they *are* just engineering practices,
          > too. I personally don't care what they're called -- they're good tools
          > to have in your box.
          >
          > Jef
          >
          > JOEY: ... Go to China. Eat Chinese food.
          > CHANDLER: Course there, they just call it "food."
          >
          >
          > -----Original Message-----
          > From: scrumdevelopment@yahoogroups.com
          > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
          > Sent: Thursday, December 01, 2005 11:36 AM
          > To: scrumdevelopment@yahoogroups.com
          > Subject: Re: [scrumdevelopment] Re: (unknown)
          >
          > On Thursday, December 1, 2005, at 10:34:06 AM, woynam wrote:
          >
          > > I will keep repeating this until the day I die.
          >
          > > They are *not* XP engineering practices.
          >
          > Why is this important to you?
          >
          > Ron Jeffries
          > www.XProgramming.com
          > Yesterday's code should be as good as we could make it yesterday.
          > The fact that we know more today, and are more capable today,
          > is good news about today, not bad news about yesterday.
          >
          >
          >
          > To Post a message, send it to: scrumdevelopment@e...
          > To Unsubscribe, send a blank message to:
          > scrumdevelopment-unsubscribe@e...
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
          >
          >
          > To Post a message, send it to: scrumdevelopment@e...
          > To Unsubscribe, send a blank message to:
          scrumdevelopment-unsubscribe@e...
          >
          >
          >
          > SPONSORED LINKS
          > Scrum
          >
          > ---------------------------------
          > YAHOO! GROUPS LINKS
          >
          >
          > Visit your group "scrumdevelopment" on the web.
          >
          > To unsubscribe from this group, send an email to:
          > scrumdevelopment-unsubscribe@yahoogroups.com
          >
          > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
          Service.
          >
          >
          > ---------------------------------
          >
        • Steven Gordon
          I like to use the term agile software development. It avoids both the turn offs and brand name issues. It also affords a little more freedom to adapt to the
          Message 4 of 26 , Dec 2, 2005
            I like to use the term agile software development.
             
            It avoids both the turn offs and brand name issues.  It also affords a little more freedom to adapt to the specific project and cultural context.
             
            I still acknowledging borrowing whatever makes sense in any paricular situation from XP, Scrum, Lean, RAD, MDA, etc. (even if they borrowed it from something else).

             
            On 12/2/05, kipkruide <nlv14041@...> wrote:
            --- In scrumdevelopment@yahoogroups.com, Tobias Mayer < tobyanon@y...>
            wrote:

            Solution seems simple then does it not, don't use the term xp, after
            all it is the results that count.

            Though in my peculiar world of humour it would be fun to tell the
            execs they've been doing xp for the last year, just to see the look on
            their faces.

            >
            > I care.  Because "doing XP" is a big turn off to many people; often,
            exactly because of all the hype.  But unit testing, or adopting test
            driven development, or automating the build process, or improving
            one's refactoring practices (etc.) well, those things usually make
            sense to people - and they are willing to do them - adopting XP a
            slice at a time, as it were.  So yes, it is important for developers
            to know that these practices are older than XP, that they preceded the
            branding.  That way they can be discussed on their own merits.  Don't
            throw away history for the sake of marketing.
            > Tobias (not a brand fan)
            >
            >
            > Jef L Newsom <jef@i...> wrote:
            > I was wondering the same thing. Is there a concern that the brand
            > diminishes the value somehow? The simple fact is that they *are* XP
            > engineering practices, since XP brands them as such, "The engineering
            > practices that compose XP." And they *are* just engineering practices,
            > too. I personally don't care what they're called -- they're good tools
            > to have in your box.
            >
            > Jef
            >
            > JOEY: ... Go to China. Eat Chinese food.
            > CHANDLER: Course there, they just call it "food."
            >
            >
            > -----Original Message-----
            > From: scrumdevelopment@yahoogroups.com
            > [mailto:scrumdevelopment@yahoogroups.com ] On Behalf Of Ron Jeffries
            > Sent: Thursday, December 01, 2005 11:36 AM
            > To: scrumdevelopment@yahoogroups.com
            > Subject: Re: [scrumdevelopment] Re: (unknown)
            >
            > On Thursday, December 1, 2005, at 10:34:06 AM, woynam wrote:
            >
            > > I will keep repeating this until the day I die.
            >
            > >   They are *not* XP engineering practices.
            >
            > Why is this important to you?
            >
            > Ron Jeffries
            > www.XProgramming.com
            > Yesterday's code should be as good as we could make it yesterday.
            > The fact that we know more today, and are more capable today,
            > is good news about today, not bad news about yesterday.

          • Ilja Preuss
            ... To me, a practice being an XP practice just means that it is part of what XP teams do. It doesn t mean that the practice didn t exist before XP. What it
            Message 5 of 26 , Dec 2, 2005
              scrumdevelopment@yahoogroups.com wrote:
              > I care. Because "doing XP" is a big turn off to many people; often,
              > exactly because of all the hype. But unit testing, or adopting test
              > driven development, or automating the build process, or improving
              > one's refactoring practices (etc.) well, those things usually make
              > sense to people - and they are willing to do them - adopting XP a
              > slice at a time, as it were. So yes, it is important for developers
              > to know that these practices are older than XP, that they preceded
              > the branding. That way they can be discussed on their own merits.
              > Don't throw away history for the sake of marketing. Tobias (not a
              > brand fan)

              To me, a practice being an XP practice just means that it is part of what XP
              teams do. It doesn't mean that the practice didn't exist before XP.

              What it might well mean is that the practice was far less well known before
              it became part of the "XP brand", that it therefore gets connected to XP by
              many people. Frankly, I'm not sure that a mostly unknown practice is less
              hard to propagate than a hyped practice.

              With XP, people don't like to try Pair Programming because it's part of the
              "XP hype". I'd wager that without XP the same people wouldn't want to try it
              because they'd never have heart about someone doing it at all. I'd even
              wager that in many cases the *real* reason for the rejection of the practice
              is something else. Blaming XP might just hold you from addressing the real
              causes.

              Cheers, Ilja
            • Tobias Mayer
              ... A good point, and possibly true in many cases. However, the introduction of we should try pair-proramming because it is one of the 12 XP practices and we
              Message 6 of 26 , Dec 2, 2005
                Ilja wrote:
                > With XP, people don't like to try Pair Programming because it's part of the "XP hype". I'd wager that without XP the same people wouldn't want to try it because they'd never have heart about someone doing it at all. I'd even wager that in many cases the *real* reason for the rejection of the practice is something else. Blaming XP might just hold you from addressing the real causes.
                 
                A good point, and possibly true in many cases.  However, the introduction of "we should try pair-proramming because it is one of the 12 XP practices and we should be doing XP" (or words to that effect), is probably less useful than an aproach like: "let's remove these cubicle walls so we can communicate more effectively".
                 
                In my experience, a group of good developers in a shared workspace, will pair program, maybe not 8-hours a day, but enough of the time for it to be beneficial.  It is a natural way to work providing (and this is the key thing) that the culture around them supports - no, encourages risk and failure.  I believe a lot of the resistance to PP is pride, which of course stems from fear.  The fear is that you'll see I don't know something.  I'll be exposed.  My guard will be down, my bonus will be affected...
                 
                Creating a culture where failure is not only tolerated but celebrated is a better starting point, to my mind, than saying "let's do XP now".
                 
                Tobias


                Ilja Preuss <preuss@...> wrote:
                scrumdevelopment@yahoogroups.com wrote:
                > I care.  Because "doing XP" is a big turn off to many people; often,
                > exactly because of all the hype.  But unit testing, or adopting test
                > driven development, or automating the build process, or improving
                > one's refactoring practices (etc.) well, those things usually make
                > sense to people - and they are willing to do them - adopting XP a
                > slice at a time, as it were.  So yes, it is important for developers
                > to know that these practices are older than XP, that they preceded
                > the branding.  That way they can be discussed on their own merits.
                > Don't throw away history for the sake of marketing. Tobias (not a
                > brand fan)       

                To me, a practice being an XP practice just means that it is part of what XP
                teams do. It doesn't mean that the practice didn't exist before XP.

                What it might well mean is that the practice was far less well known before
                it became part of the "XP brand", that it therefore gets connected to XP by
                many people. Frankly, I'm not sure that a mostly unknown practice is less
                hard to propagate than a hyped practice.

                With XP, people don't like to try Pair Programming because it's part of the
                "XP hype". I'd wager that without XP the same people wouldn't want to try it
                because they'd never have heart about someone doing it at all. I'd even
                wager that in many cases the *real* reason for the rejection of the practice
                is something else. Blaming XP might just hold you from addressing the real
                causes.

                Cheers, Ilja


              • Greg Akins
                ... In my experience, a group of good developers in a shared workspace, will pair program, maybe not 8-hours a day, but enough of the time for it to be
                Message 7 of 26 , Dec 3, 2005


                  Tobias Mayer <tobyanon@...> wrote:
                  Ilja wrote:
                  >
                  In my experience, a group of good developers in a shared workspace, will pair program, maybe not 8-hours a day, but enough of the time for it to be beneficial.  It is a natural way to work providing (and this is the key thing) that the culture around them supports - no, encourages risk and failure.  I believe a lot of the resistance to PP is pride, which of course stems from fear.  The fear is that you'll see I don't know something.  I'll be exposed.  My guard will be down, my bonus will be affected...
                   
                  I would love to pair more... But have never been luck enough to be in a shop where anyone else is interested.  However, I find that if I'm just willing to ask other developers to help me work through certain tasks, they're always willing to sit with me for fairly long periods of time. 

                  My experience with that convinces me more that pair programming is a great direction.  Because in every case, I and the other programmer worked through issues more efficiently that either of us would have done individually.

                  Speaking to your point about fear and pride.  I think that removing the "pair" stigma, and working with developers that don't have "difficult" egos, combined with open offices and lots of communications makes pairing a natural progression for good programmers even if they don't realize they're doing it.
                • Ilja Preuss
                  ... Well, yes, of course. I just don t see how calling Pair Programming an XP practice could hold anyone from doing exactly that... Confused, Ilja
                  Message 8 of 26 , Dec 5, 2005
                    > A good point, and possibly true in many cases. However, the
                    > introduction of "we should try pair-proramming because it is one of
                    > the 12 XP practices and we should be doing XP" (or words to that
                    > effect), is probably less useful than an aproach like: "let's remove
                    > these cubicle walls so we can communicate more effectively".

                    Well, yes, of course. I just don't see how calling Pair Programming an "XP
                    practice" could hold anyone from doing exactly that...

                    Confused, Ilja
                  Your message has been successfully submitted and would be delivered to recipients shortly.