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

RE: [XP] Customized XP (was "Issues faced in XP projects")

Expand Messages
  • Kent Beck
    Hello, Jim, Since I am never working in the situation you outline below, I have had to develop various techniques for helping people apply XP in the river .
    Message 1 of 29 , May 15 8:24 AM
      Hello, Jim,

      Since I am never working in the situation you outline below, I have had to
      develop various techniques for helping people apply XP "in the river". With
      existing commitments and code, incremental change is inevitable.

      The most important tool I use is Appreciative Inquiry, in which you ask
      people to focus on what they are doing (or have done) well and see how to do
      more of it. This completely eliminates the need to "convince" anyone of
      anything, since they are pulling ideas out of their own experience. Since
      I'm part of the conversation, XP-ish ideas get added to the mix.

      I was out hiking the Rogue yesterday with my friends/clients Greg Betty and
      Bruno Schmidt from Intelliware (an outstanding XP development shop in
      Toronto). Bruno pointed out the effects of water. If you have a mountain and
      water in conflict, bet on the water. The water knows where it is
      going--downhill. It actively works at getting there. If it gets blocked,
      though, it doesn't hammer away at the mountain, it flows around. Eventually,
      the water gets where it is going. When I keep in mind where I am going, when
      I respond to resistance with listening instead of belligerence, when I keep
      doing my work as best I can, then I have influence. Sometimes I miss the
      lack of drama and spotlight, but I appreciate the results.

      If you want to experience this Appreciative Inquiry first-hand, please
      attend the workshop Cynthia Andres and I will be hosting at XP 2006 and
      Agile 2006 on Mapping XP.

      Sincerely yours,

      Kent Beck
      Three Rivers Institute

      > -----Original Message-----
      > From: extremeprogramming@yahoogroups.com
      > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Jim Shore
      > Sent: Friday, May 12, 2006 9:04 PM
      > To: extremeprogramming@yahoogroups.com
      > Subject: Re: [XP] Customized XP (was "Issues faced in XP projects")
      >
      > Dale Emery wrote:
      > > Hi Jim,
      > >
      > >> My concern is that incorporating practices on an as-needed
      > >> basis requires black-belt software process and
      > >> organizational-change skills.
      > >
      > > Have you found that adopting XP as describe in XP1E requires less
      > > skill at software process and organizational change? That would
      > > be interesting to me.
      >
      > Hi, Dale,
      >
      > Yes, I do think "XP1E" style adoption takes less skill at software
      > process and organizational change, under limited and specific
      > circumstances.
      >
      > I think XP is easiest to adopt successfully when:
      >
      > - A friendly, open-minded, and cohesive team
      > - with supportive management
      > - led by at least one experienced developer (who
      > - groks object-oriented design and architecture)
      > - makes a sincere effort
      > - to understand and apply all of the practices
      > - to a brand-new, green-field project.
      >
      > I'm not saying that every team has this luxury... just that
      > this is what
      > I think is the easiest way to go. As each of these conditions
      > disappears, risk goes up, effort goes up, and the requirement for
      > process and organizational-change skills go up. At a certain point,
      > incremental adoption is better than wholesale adoption,
      > although I would
      > adopt some practices in chunks rather than singly.
      >
      > I'd be interested in hearing what you and others think is the easiest
      > way to adopt XP successfully.
      >
      > Cheers,
      > Jim
    • Dale Emery
      Hi Jim, ... I can see that. These conditions make any new idea easier to adopt successfully. ... Are some conditions more significant in reaching that point?
      Message 2 of 29 , May 15 11:52 AM
        Hi Jim,

        > I think XP is easiest to adopt successfully when:
        >
        > - A friendly, open-minded, and cohesive team
        > - with supportive management
        > - led by at least one experienced developer (who
        > - groks object-oriented design and architecture)
        > - makes a sincere effort
        > - to understand and apply all of the practices
        > - to a brand-new, green-field project.

        I can see that. These conditions make any new idea easier to
        adopt successfully.

        > As each of these conditions disappears, risk goes up, effort
        > goes up, and the requirement for process and
        > organizational-change skills go up. At a certain point,
        > incremental adoption is better than wholesale adoption,
        > although I would adopt some practices in chunks rather than
        > singly.

        Are some conditions more significant in reaching that point?
        Which conditions, if missing, are more likely to bring you to
        that adopt-in-chunks point?

        > I'd be interested in hearing what you and others think is the
        > easiest way to adopt XP successfully.

        I've never adopted XP. I've adopted many of the practices
        (stories, automated acceptance tests, TDD, refactoring, simple
        design, and coding standards) for my personal, solo use. That
        was easy enough, and successful. I tried to adopt metaphor, but
        was happier to just let the code be what it is rather than using
        metaphor to relate it to something else.

        So I've never adopted XP, successfully or otherwise--I have no
        experience to judge what might be the easiest way. That's why
        I'm grateful to you and Adrian and Kent for describing your
        experience. I'd love to hear from others about their experience
        adopting XP whole or in increments.

        Dale

        --
        Dale Emery, Consultant
        Inspiring Leadership for Software People
        Web: http://www.dhemery.com
        Weblog: http://www.dhemery.com/cwd
      • Joshua Kerievsky
        ... Hi Dale, We begin every transition with a Readiness Assessment. During the assessment, we collaborate with a would-be client on risks/rewards of
        Message 3 of 29 , May 15 3:48 PM
          Dale Emery wrote:
          > So I've never adopted XP, successfully or otherwise--I have no
          > experience to judge what might be the easiest way. That's why
          > I'm grateful to you and Adrian and Kent for describing your
          > experience. I'd love to hear from others about their experience
          > adopting XP whole or in increments.
          >
          Hi Dale,

          We begin every transition with a Readiness Assessment. During the
          assessment, we collaborate with a would-be client on risks/rewards of
          current/future process. When discussing how to manage risks, we point
          to management, customer and developer practices within Industrial XP
          (http://industrialxp.org). To customize a process for a would-be
          client, we remove practices from IXP that we/they consider to be beyond
          the current capabilities of the project community. In many cases, we
          end up removing no practices. In other cases, we remove practices.
          For example, we recently removed Storytest-Driven Development from one
          custom process, because the availability of the customer community is
          still suspect. HTH.

          --
          best regards,
          jk

          ----
          I n d u s t r i a l L o g i c , I n c .
          Joshua Kerievsky
          Founder, Industrial XP Coach
          http://industriallogic.com
          http://industrialxp.org
          866-540-8336 (toll free)
          510-540-8336 (phone)
          Berkeley, California
        • Jim Shore
          ... They certainly don t hurt. When faced with a difficult challenge, like adopting XP under non-ideal conditions, I see several choices. One is to say, We
          Message 4 of 29 , May 15 9:42 PM
            Dale Emery wrote:
            > Hi Jim,
            >
            >[Jim wrote:]
            >> I think XP is easiest to adopt successfully when:
            >>
            >> - A friendly, open-minded, and cohesive team
            >> - with supportive management
            >> - led by at least one experienced developer (who
            >> - groks object-oriented design and architecture)
            >> - makes a sincere effort
            >> - to understand and apply all of the practices
            >> - to a brand-new, green-field project.
            >
            > I can see that. These conditions make any new idea easier to
            > adopt successfully.

            They certainly don't hurt.

            When faced with a difficult challenge, like adopting XP under non-ideal
            conditions, I see several choices. One is to say, "We can't do all of
            XP, so we'll pick the things that we can do." Another is to say, "Let's
            hire an experienced coach to help us incrementally adopt everything."

            I also see a third choice, and this is where I focus my efforts. That
            choice is to say: "We can make the challenge go away if we focus some
            effort on making the easy approach possible." (Sort of like refactoring
            the code before introducing a new feature, I suppose.)

            I think that the most important "easy XP" conditions are possible to
            achieve in many companies. I make a special effort to encourage as many
            of these conditions be in place as possible before I start working with
            a team. (Usually, before I'm hired.) This is similar to Joshua
            Kerievsky's IXP "readiness assessment" practice and was in fact inspired
            by it. I had the good fortune to talk with Joshua Kerievsky about IXP
            after a bad transition experience and his insights into readiness
            assessments were an eye-opener for me.

            I'm still not saying that every company can achieve these conditions.
            But, knowing how much more successful I am when they are all present, I
            work that much harder for them. If enough aren't present, I won't offer
            to help with overall process change and I'll focus on individual
            practices instead.

            This sounds like idealism, I'm sure. But it's something I really do.
            It's an integral part of my practice. A story:

            I was recently talking with a very large company about a major XP
            conversion. It was a plum job and I wanted it.

            The person who wanted to hire me was very excited about having me help
            his team. The customer's participation, however, was also crucial to
            our success. I insisted that we talk with her. When we talked, I could
            tell that all she wanted was to meet a particular delivery date. I
            probed about scope and there seemed to be no options.

            The most important thing was that she didn't seem to be interested in XP
            at all; in fact, she was lukewarm, borderline hostile. She barely paid
            attention to the call and clearly was tuning us out.

            Given her critical involvement, I could tell that this was looking like
            a bad situation. So I took a direct, although non-confrontational
            approach. I told her that XP wouldn't help her achieve her near-term
            deadline any faster, and that learning new techniques would probably
            slow the team down in the near term. I probed for other problems that
            we /could/ help with. No cooperation. She was looking for more
            heads-down programming, not process improvement; or, if she was, she
            clearly didn't trust me to provide it.

            In the end, I let it go. I'm glad, despite missing a plum opportunity.
            It would have been a bad situation. Now we're looking for another
            way I can work with the company.

            When I do work on a major transition with this company--and I believe I
            will, though it may take a few more years--it /will/ be close to the
            "idealistic" scenario I describe above. I expect it to be a roaring
            success with benefits throughout the organization.

            >> As each of these conditions disappears, risk goes up, effort
            >> goes up, and the requirement for process and
            >> organizational-change skills go up. At a certain point,
            >> incremental adoption is better than wholesale adoption,
            >> although I would adopt some practices in chunks rather than
            >> singly.
            >
            > Are some conditions more significant in reaching that point?
            > Which conditions, if missing, are more likely to bring you to
            > that adopt-in-chunks point?

            I don't know if I can say. Let me try:

            >> - A friendly, open-minded, and cohesive team
            >> - with supportive management
            >> - makes a sincere effort
            >> - to understand and apply all of the practices

            If these aren't present in a strong majority of participants, I won't
            attempt a major process transition of any sort, XP or otherwise.

            >> - led by at least one experienced developer (who

            Lack of this just means that I need to be involved more. No biggie.
            They'll be more experienced when we're done. :)

            >> - groks object-oriented design and architecture)

            Lack of this makes all sorts of design activities more difficult.
            Teaching design at the same time as other practices is difficult. Not
            impossible, though. Depends on how much people are willing to unlearn.
            I might do more up-front training in TDD.

            >> - to a brand-new, green-field project.

            Lack of this can make TDD very difficult. Depends on how good the
            existing code is. If TDD is hard, a whole bunch of technical practices
            get knocked out for a time. Alternatively, I might focus just on TDD
            and refactoring for a while. Depends on where the value is.

            I keep an eye out for much more, particularly with regards to customer
            relationships. This is just a rough sketch. Fully (and accurately)
            describing my thought process on this would be a chapter in a book, I
            suspect.

            Regards,
            Jim

            --
            James Shore -- Titanium IT -- Successful Software
            Recipient of 2005 Gordon Pask award for
            Contributions to Agile Practice

            phone: 503-267-5490
            email: jshore@...
            web/blog: http://www.jamesshore.com
          • Jim Shore
            ... Hi, Kent. ... I ve had the good fortune to be in that situation several times. Well, fortune isn t the right word for it. I work hard to be in that
            Message 5 of 29 , May 15 9:54 PM
              Kent Beck wrote:
              > Hello, Jim,

              Hi, Kent.

              > Since I am never working in the situation you outline below, I have had to
              > develop various techniques for helping people apply XP "in the river". With
              > existing commitments and code, incremental change is inevitable.

              I've had the good fortune to be in that situation several times. Well,
              "fortune" isn't the right word for it. I work hard to be in that
              situation, as I discuss in my email to Dale.

              I see the advantages of applying XP "in the river," if I understand your
              usage of the term. It's also something I've had very mixed success
              with. Nowadays, if I'm "in the river," I don't have XP as a goal; I
              just help people adopt practices that will help them. I don't think
              they'll end up with XP, but I'm okay with that. (I sometimes think that
              in 10 years, we'll just call XP "software development.")

              Looking at this, it seems like we might be doing the same thing.

              I do think XP has some really significant benefits, though, and I love
              how smoothly projects work when they're all in place, so when
              appropriate I prefer to introduce all of XP. This takes time and effort
              but I just love seeing the results. A smoothly running XP team is a
              thing of beauty. (Thank you for that.)

              > The most important tool I use is Appreciative Inquiry, in which you ask
              > people to focus on what they are doing (or have done) well and see how to do
              > more of it. This completely eliminates the need to "convince" anyone of
              > anything, since they are pulling ideas out of their own experience. Since
              > I'm part of the conversation, XP-ish ideas get added to the mix.

              I've experienced Appreciative Inquiry first-hand due to some work with
              Diana Larsen. I liked what I saw and I still have a lot to learn about
              how to best apply it to my work. Your workshop sounds like a good way
              to learn more and I hope to attend.

              One thing I've learned through interaction with Diana and her colleagues
              is to focus on the positive. "Assume good faith" has always been a
              favored practice of mine; now I apply it more honestly and consistently.
              I used to enter a situation looking for problems to solve; now, I look
              for ways to help people recognize opportunities and grow.

              I think this is what appreciative inquiry is about at a philosophical
              level. I'm looking forward to learning more about how to apply it.

              Regards,
              Jim

              --
              James Shore -- Titanium IT -- Successful Software
              Recipient of 2005 Gordon Pask award for
              Contributions to Agile Practice

              phone: 503-267-5490
              email: jshore@...
              web/blog: http://www.jamesshore.com
            • Dale Emery
              Hi Jim, ... Sounds quite practical to me. It also sounds as if maybe you don t realize you have black belt skills in organizational change. ... Yes, those are
              Message 6 of 29 , May 15 11:18 PM
                Hi Jim,

                > I'm still not saying that every company can achieve these
                > conditions. But, knowing how much more successful I am when
                > they are all present, I work that much harder for them. If
                > enough aren't present, I won't offer to help with overall
                > process change and I'll focus on individual practices instead.
                >
                > This sounds like idealism, I'm sure.

                Sounds quite practical to me. It also sounds as if maybe you
                don't realize you have black belt skills in organizational change.

                >>> - A friendly, open-minded, and cohesive team
                >>> - with supportive management
                >>> - makes a sincere effort
                >>> - to understand and apply all of the practices
                >
                > If these aren't present in a strong majority of participants,
                > I won't attempt a major process transition of any sort, XP or
                > otherwise.

                Yes, those are doozies. When I encounter those, and when I don't
                know how to expand the boundaries, I look for what the team /is/
                open-minded about, what management /will/ support, and what the
                team /will/ sincerely try. If the intersection is a set of stuff
                that I think will create value, I'll work with that.

                >>> - groks object-oriented design and architecture)
                >
                > Lack of this makes all sorts of design activities more
                > difficult. Teaching design at the same time as other practices
                > is difficult. Not impossible, though. Depends on how much
                > people are willing to unlearn. I might do more up-front
                > training in TDD.

                I've seen how focusing entirely on design-in-the-small (noticing
                code smells, refactoring to make one teeny tiny improvement after
                another) can significantly improve design-in-the-large. Having
                seen that, I've been wondering if focusing entirely on code
                smells and refactoring would be enough to obviate the need for
                larger-scaled skills at OO design and architecture.

                >>> - to a brand-new, green-field project.
                >
                > Lack of this can make TDD very difficult. Depends on how good
                > the existing code is. If TDD is hard, a whole bunch of
                > technical practices get knocked out for a time.
                > Alternatively, I might focus just on TDD and refactoring for a
                > while.

                Yes, and techniques like the ones Michael Feathers describes in
                WELC. Elisabeth Hendrickson and I have done some training based
                around those and other techniques. I'd love to do some coaching
                in that area.

                Dale

                --
                Dale Emery, Consultant
                Inspiring Leadership for Software People
                Web: http://www.dhemery.com
                Weblog: http://www.dhemery.com/cwd
              • Joakim Karlsson
                ... So, waterfall will come back with a vengeance then? ;) /Joakim
                Message 7 of 29 , May 16 9:44 AM
                  On 5/15/06, Kent Beck <kentb@...> wrote:
                  > If you have a mountain and
                  > water in conflict, bet on the water. The water knows where it is
                  > going--downhill. It actively works at getting there. If it gets blocked,
                  > though, it doesn't hammer away at the mountain, it flows around. Eventually,
                  > the water gets where it is going.

                  So, waterfall will come back with a vengeance then? ;)

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