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

RE: [XP] How do agile methods survive in highly structured organisations

Expand Messages
  • William Pietri
    ... I d say that yes, Agile methods are only suitable to certain types of organizations. If I had to sum the difference up in one word, it d be sanity . The
    Message 1 of 19 , Feb 2, 2003
    • 0 Attachment
      On Sat, 2003-02-01 at 16:15, Michael Lane wrote:
      > We are interested in finding out from practitioners experienced in using
      > agile methods such as XP, whether agile methods fit better with certain
      > types of organisations than others and if so why?

      I'd say that yes, Agile methods are only suitable to certain types of
      organizations. If I had to sum the difference up in one word, it'd be
      "sanity".

      The attitude behind all of the various Agile methods that I've looked at
      closely seems to be that there is a real-world purpose to producing
      software, and that one's success can be measured by reference to that.
      Ergo, we should do everything we can to tighten feedback loops, so that
      we can converge rapidly on good ways to get where we are going.

      On the other hand, some organizations, which I will designate by the
      objective and non-judgemental term "crazy", appear to judge software
      project success by other criteria. These criteria vary, but in the
      examples I can think of success is determined by corporate politics or
      by conformance to process checkboxes of questionable relevance (e.g.,
      the amount which software conforms to a contract or spec, regardless of
      the actual utility of the software).

      The waterfall (and other document-centered methods), on the other hand,
      work at least as well in crazy organizations, and perhaps better. That's
      not to say that the software will be any better, of course. But long
      planning cycles, mountains of paper, and talmudic arguments over the
      "meaning" of a mass of semi-conflicting documents can effectively hide
      any pragmatic, real-world concern. That leaves a lot more room for
      politics, ritual, bullshit, and barking madness.


      It's my further observation that small companies are only crazy if the
      head honcho is pretty crazy. Large companies, though, can be crazy even
      if they are populated by people who are generally quite reasonable. So I
      would expect a moderate negative correlation between organization size
      and ease of adopting Agile methods.


      Is that the sort of thing you were looking for, Michael?


      William



      --
      brains for sale: http://scissor.com/
    • Priyank Johri
      ... of ... Here is what a typical large organization may have: 1. Tons of already existing processes which you have to work within. 2. Lots of legacy systems
      Message 2 of 19 , Feb 2, 2003
      • 0 Attachment
        > Surety you crave? SauRon gives none.
        >
        > He asked for more info about your situation, and you repeated the essense
        of
        > your question.

        Here is what a typical large organization may have:

        1. Tons of already existing processes which you have to work within.

        2. Lots of legacy systems with which you have to interface and which take
        time
        to modify.

        3. Cubes, cubes, and more cubes with no way of re-arranging furniture.

        4. Customers that are all over the place spanning timezones.

        5. Development or even testing which is outsourced offshore (10 hr
        difference in timezone).

        6. Managers who live, breathe and bathe in the *waterfall*.

        I'm sure others can add more. Now what do you say?

        ----- Original Message -----
        From: "Phlip" <plumlee@...>
        To: <extremeprogramming@yahoogroups.com>
        Sent: Saturday, February 01, 2003 9:32 PM
        Subject: Re: [XP] How do agile methods survive in highly structured
        organisations


        > > Ron Jeffries sez:
        >
        > > Are you trying XP now in such an organization? If so, what's happening
        > > to
        > > you? If not, what are your concerns?
        >
        > Michael Lane sez:
        >
        > > We are interested in finding out from practitioners experienced in using
        > > agile methods such as XP, whether agile methods fit better with certain
        > > types of organisations than others and if so why?
        > >
        > > We would be interested in any personal experiences, stories or case
        > > studies as such
        >
        > Surety you crave? SauRon gives none.
        >
        > He asked for more info about your situation, and you repeated the essense
        of
        > your question.
        >
        > You giving specifics works faster than us giving a long list of general
        > ideals. Just tell us what "certain types of organizations" you have.
        >
        > XP has "failed" in many situations where management did not want to
        provide an
        > OnsiteCustomer, did not give their puppet OSC any clout, did not want to
        > steer in real-time, did not want their pet sycophants' power taken away by
        > teams shredding, and did not want to admit their own lame shortcomings
        that
        > XP's feedback mechanisms exposed within a couple weeks.
        >
        > Change your organization, or change your organization.
        >
        > --
        > Phlip
        > http://www.greencheese.org/GonzoFriday
        > -- Bad nanoprobe! Bad! --
        >
        >
        > To Post a message, send it to: extremeprogramming@...
        >
        > To Unsubscribe, send a blank message to:
        extremeprogramming-unsubscribe@...
        >
        > ad-free courtesy of objectmentor.com
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
        >
        >
        >
      • Ron Jeffries
        ... I m interested in understanding your actual circumstances, why you are asking about this topic. Are you trying XP now in such a situation? If so, what is
        Message 3 of 19 , Feb 3, 2003
        • 0 Attachment
          On Monday, February 3, 2003, at 1:38:34 AM, Priyank Johri wrote:

          > Here is what a typical large organization may have:

          > 1. Tons of already existing processes which you have to work within.

          > 2. Lots of legacy systems with which you have to interface and which take
          > time
          > to modify.

          > 3. Cubes, cubes, and more cubes with no way of re-arranging furniture.

          > 4. Customers that are all over the place spanning timezones.

          > 5. Development or even testing which is outsourced offshore (10 hr
          > difference in timezone).

          > 6. Managers who live, breathe and bathe in the *waterfall*.

          > I'm sure others can add more. Now what do you say?

          I'm interested in understanding your actual circumstances, why you are
          asking about this topic.

          Are you trying XP now in such a situation? If so, what is happening to you?
          Are all of these circumstances in effect? Some of them? Are they affecting
          your project? In what ways?

          If you are not trying XP in such a situation, you have described some
          general situations which may or may not obtain. What is your concern? What
          are your intentions?

          Ron Jeffries
          www.XProgramming.com
          Fear is the mindkiller. --Bene Gesserit Litany Against Fear
        • Dustin Aleksiuk
          ... From: Priyank Johri To: Sent: Sunday, February 02, 2003 11:38 PM Subject: Re: [XP] How do agile
          Message 4 of 19 , Feb 3, 2003
          • 0 Attachment
            ----- Original Message -----
            From: "Priyank Johri" <lists@...>
            To: <extremeprogramming@yahoogroups.com>
            Sent: Sunday, February 02, 2003 11:38 PM
            Subject: Re: [XP] How do agile methods survive in highly structured
            organisations

            > I'm sure others can add more. Now what do you say?

            We're having an interesting problem in our company, which is quite a large
            organization. Due to the success of agile methods on various projects, upper
            management feels that they would like more teams them. Teams are being
            pressured from above to work in a certain way with very little experience or
            coaching. My worry is that people are going to take a subset of good
            practices, implement them badly, and then blame the methods they used when
            the project goes awry.

            Dustin Aleksiuk
          • Ron Jeffries
            ... Your worry is not entirely ill-founded. I believe that management should proceed, not by dictating agile methods, but by asking for certain kinds of things
            Message 5 of 19 , Feb 3, 2003
            • 0 Attachment
              On Monday, February 3, 2003, at 10:44:48 AM, Dustin Aleksiuk wrote:

              > We're having an interesting problem in our company, which is quite a large
              > organization. Due to the success of agile methods on various projects, upper
              > management feels that they would like more teams them. Teams are being
              > pressured from above to work in a certain way with very little experience or
              > coaching. My worry is that people are going to take a subset of good
              > practices, implement them badly, and then blame the methods they used when
              > the project goes awry.

              Your worry is not entirely ill-founded.

              I believe that management should proceed, not by dictating agile methods,
              but by asking for certain kinds of things that agile methods can help to
              provide, such as

              - delivery of customer-tested features every couple of weeks
              - estimates on features, broken down such that no estimate exceeds a
              couple of weeks
              - reports on development status in terms of resources, scope, quality,
              time
              - evidence that any feature can be worked on by more than one programmer

              And, of course, they should begin by providing what only they can provide,
              things like: a customer for every team, training and coaching, and an easy
              way to configure a workspace supporting agile methods for each team.

              Ron Jeffries
              www.XProgramming.com
              Bang, bang, Jeffries' silver hammer came down upon their heads ...
            • Michael Kenny
              ... An XP team will produce excellent software, stable, bug free etc. In a command-control organisation the danger is that the software you produce is not what
              Message 6 of 19 , Feb 4, 2003
              • 0 Attachment
                On Sun, 2 Feb 2003 10:15:15 +1000, you wrote:

                >We are interested in finding out from practitioners experienced in using
                >agile methods such as XP, whether agile methods fit better with certain
                >types of organisations than others and if so why?
                >
                >We would be interested in any personal experiences, stories or case
                >studies as such
                >
                >Thanks in advance
                >Michael Lane

                An XP team will produce excellent software, stable, bug free etc.
                In a command-control organisation the danger is that the software you
                produce is not what is needed however perfect it may be.

                What's going on? The team is great at using negotiation/feedback loops
                to build what we think is needed. But this discussion and feedback
                remains focussed on mostly technical/structural issues and is in a
                sense in a self-focussed world of its own.

                Why? At some stage above/beyond the team there is a hierarchy and a
                divide, where such feedback and questioning, cooperation and social
                dialogue turns into corporate monologue or a command from above. We
                want such-and- such a system. That's it. Then you deliver it and noone
                can use it. In these projects XP will be considered a failure even
                though the failure lies elsewhere.

                There is a clash of driving what is needed from above or below.

                Do Agile methods survive here? If the failure is discussed openly the
                organisation may change. It depends on the level of interest.


                Michael
              • Ron Jeffries
                ... Do you think there is a better way than XP to build software in an organization like you describe? Ron Jeffries www.XProgramming.com The practices are not
                Message 7 of 19 , Feb 4, 2003
                • 0 Attachment
                  On Tuesday, February 4, 2003, at 6:31:45 AM, Michael Kenny wrote:

                  > An XP team will produce excellent software, stable, bug free etc.
                  > In a command-control organisation the danger is that the software you
                  > produce is not what is needed however perfect it may be.

                  > What's going on? The team is great at using negotiation/feedback loops
                  > to build what we think is needed. But this discussion and feedback
                  > remains focussed on mostly technical/structural issues and is in a
                  > sense in a self-focussed world of its own.

                  > Why? At some stage above/beyond the team there is a hierarchy and a
                  > divide, where such feedback and questioning, cooperation and social
                  > dialogue turns into corporate monologue or a command from above. We
                  > want such-and- such a system. That's it. Then you deliver it and noone
                  > can use it. In these projects XP will be considered a failure even
                  > though the failure lies elsewhere.

                  Do you think there is a better way than XP to build software in an
                  organization like you describe?

                  Ron Jeffries
                  www.XProgramming.com
                  The practices are not XP. They are a path to XP.
                • Steve Berczuk
                  ... This reminds me of a NASA science satellite project I worked on ~1993. (before XP practices were grouped together and named as such...) Our group consisted
                  Message 8 of 19 , Feb 4, 2003
                  • 0 Attachment
                    Priyank Johri wrote:
                    > Here is what a typical large organization may have:
                    >
                    > 1. Tons of already existing processes which you have to work within.
                    >
                    >
                    > 6. Managers who live, breathe and bathe in the *waterfall*.
                    >
                    > I'm sure others can add more. Now what do you say?

                    This reminds me of a NASA science satellite project I worked on ~1993.
                    (before XP practices were grouped together and named as such...) Our
                    group consisted of some NASA contractors, and some people from MIT. We
                    had decided that iteration was good and we did our planning around the
                    idea of iterations and frequent integrations. The interesting thing was
                    that every project review presentation that the contrators prepared for
                    NASA management acknowledged this 'new' process by referring to a
                    "Modified waterfall approach" :)
                    In reality, it was so modified as to look more like a level stream
                    than a waterfall, yet the culture was such that the phrase 'waterfall'
                    had to be used.
                    It was a very interesting thing to see, and really frustrated me that
                    we were doing this 'new' thing and no one was really allowed to know!

                    Perhaps this is an example of a case where an agile method survived by
                    placing enough of the structured trappings around the process so as not
                    to alarm anyone who was not involved in the actual work. Not ideal, but...
                    -steve

                    --
                    Steve Berczuk | steve@... | http://www.berczuk.com
                    SCM Patterns: Effective Teamwork, Practical Integration
                    www.scmpatterns.com
                  • Brian Christopher Robinson
                    ... You may want to check this out: http://c2.com/cgi/wiki?ChangeYourOrganizationDiary
                    Message 9 of 19 , Feb 4, 2003
                    • 0 Attachment
                      On Sat, 1 Feb 2003, Michael <zzmlane@...> wrote:

                      > As anyone worked on or know of a project using a lightweight
                      > methodology such as XP or another agile methodology, RAD which did
                      > not fit well with the way the organisation operated.

                      You may want to check this out:

                      http://c2.com/cgi/wiki?ChangeYourOrganizationDiary
                    • Priyank Johri
                      Ron, ... you? Yes, the 6 items I mention below apply to my situation. I m not *trying* XP in this environment yet, although I would like to. I m, however,
                      Message 10 of 19 , Feb 4, 2003
                      • 0 Attachment
                        Ron,

                        > I'm interested in understanding your actual circumstances, why you are
                        > asking about this topic.
                        > Are you trying XP now in such a situation? If so, what is happening to
                        you?

                        Yes, the 6 items I mention below apply to my situation. I'm not *trying* XP
                        in this environment yet, although I would like to. I'm, however, trying to
                        evaluate
                        if I can use XP successfully in such in environment or not. Let me add a few
                        things
                        that we have been able to do on past projects and hence should be able to do
                        on this new one:

                        - Fairly fast integration, although only on the development machines
                        - Refactoring, not all the time, but quite a bit
                        - Bug (defect) tracking and feeding them back into our development cycles

                        What I'm concerned about is:

                        1. Tons of already existing processes which you have to work within.

                        As Steve Berczuk said, I may try to fake the existing processes to an
                        extent here,
                        but have no way of avoiding them. So, yes, they still want the 100 page
                        documents
                        that typically go with such systems.

                        2. Lots of legacy systems with which you have to interface and which take
                        time to modify.

                        You can't really do quick changes to such systems. You can only do changes
                        once and then you test them and you are done.

                        3. Cubes, cubes, and more cubes with no way of re-arranging furniture.

                        Creating the right kind of environment is a big problem. As is, office space
                        is scarce. Even if we get a C2 like environment (or war room) it would be
                        difficult to argue to still have our private cubes at the same time.

                        4. Customers that are all over the place spanning timezones.
                        PST, CST, EST... and definitely not on-site. We typically *listen* to our
                        customers
                        on audio conferences or use collaboration tools like Webex.

                        5. Development or even testing which is outsourced offshore (10 hr
                        difference in timezone).
                        Some of our testing is done in Asia..

                        6. Managers who live, breathe and bathe in the *waterfall*.
                        Most of the members on the project team are unlike this, but
                        everybody else (including systems that you have to interface with,
                        and the customers) are so full of the waterfall process, it isn't even
                        funny.

                        All this apart, there is still a lot of value in agile development and we'll
                        try to leverage whatever we can, including:
                        - Extensive unit testing
                        - Refactoring
                        - Constant customer feedback
                        - Possibly small releases
                        - Collective code ownership
                        -Effective planning

                        how eXtreme this will be, is another question.
                        ----- Original Message -----
                        From: "Ron Jeffries" <ronjeffries@...>
                        To: <extremeprogramming@yahoogroups.com>
                        Sent: Monday, February 03, 2003 3:20 AM
                        Subject: Re: [XP] How do agile methods survive in highly structured
                        organisations


                        > On Monday, February 3, 2003, at 1:38:34 AM, Priyank Johri wrote:
                        >
                        > > Here is what a typical large organization may have:
                        >
                        > > 1. Tons of already existing processes which you have to work within.
                        >
                        > > 2. Lots of legacy systems with which you have to interface and which
                        take
                        > > time
                        > > to modify.
                        >
                        > > 3. Cubes, cubes, and more cubes with no way of re-arranging furniture.
                        >
                        > > 4. Customers that are all over the place spanning timezones.
                        >
                        > > 5. Development or even testing which is outsourced offshore (10 hr
                        > > difference in timezone).
                        >
                        > > 6. Managers who live, breathe and bathe in the *waterfall*.
                        >
                        > > I'm sure others can add more. Now what do you say?
                        >
                        > I'm interested in understanding your actual circumstances, why you are
                        > asking about this topic.
                        >
                        > Are you trying XP now in such a situation? If so, what is happening to
                        you?
                        > Are all of these circumstances in effect? Some of them? Are they affecting
                        > your project? In what ways?
                        >
                        > If you are not trying XP in such a situation, you have described some
                        > general situations which may or may not obtain. What is your concern? What
                        > are your intentions?
                        >
                        > Ron Jeffries
                        > www.XProgramming.com
                        > Fear is the mindkiller. --Bene Gesserit Litany Against Fear
                        >
                        >
                        > To Post a message, send it to: extremeprogramming@...
                        >
                        > To Unsubscribe, send a blank message to:
                        extremeprogramming-unsubscribe@...
                        >
                        > ad-free courtesy of objectmentor.com
                        >
                        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                        >
                        >
                        >
                        >
                      • Brad Appleton
                        ... Gee - to my knowledge we ve never met, yet it seems like we both work at the same place :-) ... Of course you already know this, but being eXtreme isn t
                        Message 11 of 19 , Feb 4, 2003
                        • 0 Attachment
                          On Tue, Feb 04, 2003 at 09:47:54PM -0600, Priyank Johri wrote:
                          > What I'm concerned about is:
                          >
                          > 1. Tons of already existing processes which you have to work within.
                          ...
                          > 2. Lots of legacy systems with which you have to interface and which take
                          > time to modify.
                          ...
                          > 3. Cubes, cubes, and more cubes with no way of re-arranging furniture.
                          ...
                          > 4. Customers that are all over the place spanning timezones.
                          ...
                          > 5. Development or even testing which is outsourced offshore
                          ...
                          > 6. Managers who live, breathe and bathe in the *waterfall*.

                          Gee - to my knowledge we've never met, yet it seems like we both work at the same place :-)

                          > All this apart, there is still a lot of value in agile development and we'll
                          > try to leverage whatever we can, including:
                          > - Extensive unit testing
                          > - Refactoring
                          > - Constant customer feedback
                          > - Possibly small releases
                          > - Collective code ownership
                          > -Effective planning
                          >
                          > how eXtreme this will be, is another question.

                          Of course you already know this, but being "eXtreme" isn't
                          necessarily the goal as much as delivering quality software
                          on time in the face of rapid change :-)

                          Sounds like you need a variant of the "Firewall" or
                          "Facade" pattern where you team appears to be normal in
                          its communications, interfaces, and expectations with other
                          teams, but beneath that facade, within the team itself you
                          act as agile/extreme as you possibly can, and produce only
                          the bare minimum of additional artifacts necessary to satisfy
                          "inter-team protocol". I hear it takes a good communicator
                          and negotiator/facilitator to manage the inter-team communication
                          relationships in this case.

                          --
                          Brad Appleton <brad@...> www.bradapp.net
                          Software CM Patterns (www.scmpatterns.com)
                          Effective Teamwork, Practical Integration
                          "And miles to go before I sleep." -- Robert Frost
                        • Ron Jeffries
                          ... Understood. Someone has already raised the issue of whether you want to do XP or some other more or less agile thing. Of course, since XP is always
                          Message 12 of 19 , Feb 5, 2003
                          • 0 Attachment
                            On Tuesday, February 4, 2003, at 10:47:54 PM, Priyank Johri wrote:

                            > Yes, the 6 items I mention below apply to my situation. I'm not *trying* XP
                            > in this environment yet, although I would like to. I'm, however, trying to
                            > evaluate
                            > if I can use XP successfully in such in environment or not. Let me add a few
                            > things
                            > that we have been able to do on past projects and hence should be able to do
                            > on this new one:

                            > - Fairly fast integration, although only on the development machines
                            > - Refactoring, not all the time, but quite a bit
                            > - Bug (defect) tracking and feeding them back into our development cycles

                            Understood. Someone has already raised the issue of whether you want to do
                            XP or some other more or less agile thing. Of course, since XP is always
                            adjusted to the situation, these may be the same thing.

                            Overall I'm curious about which of the core practices, if any, you feel you
                            may not be able to use in your situation. I'll put some comments and
                            questions below.

                            > What I'm concerned about is:

                            > 1. Tons of already existing processes which you have to work within.

                            > As Steve Berczuk said, I may try to fake the existing processes to an
                            > extent here,
                            > but have no way of avoiding them. So, yes, they still want the 100 page
                            > documents
                            > that typically go with such systems.

                            Yes. Schedule them and write them. I've got this fantasy that they could be
                            written iteratively, as you learn, but have never tried it. An issue here
                            is that they may want a design before you apply programmers. If that's the
                            case, I wonder what would happen if you called your programmers designers
                            and analysts, and then did XP, throwing off documents as part of the
                            process. You might wind up with a zero-length coding phase ...

                            > 2. Lots of legacy systems with which you have to interface and which take
                            > time to modify.

                            > You can't really do quick changes to such systems. You can only do changes
                            > once and then you test them and you are done.

                            I'm not sure I understand only changing them once. I would wager that many
                            of them are changed quite a bit more often than that. In any case, you're
                            right that this is a problem, but it's a problem using any process. What
                            about XP gives you concern in this regard?

                            > 3. Cubes, cubes, and more cubes with no way of re-arranging furniture.

                            > Creating the right kind of environment is a big problem. As is, office space
                            > is scarce. Even if we get a C2 like environment (or war room) it would be
                            > difficult to argue to still have our private cubes at the same time.

                            I would not recommend that the team keep private cubes as well as the open
                            space, though there does need to be some more or less private space. Note
                            that the C3 team had small desks along one side of the room that they used
                            for desk and private work. I think I might add a few "phone booths",
                            tiny enclosed spaces just used for private phone calls and such.

                            Studies indicate that open space work is more productive than separate
                            offices or cubes. I don't suppose that helps ...

                            > 4. Customers that are all over the place spanning timezones.
                            > PST, CST, EST... and definitely not on-site. We typically *listen* to our
                            > customers
                            > on audio conferences or use collaboration tools like Webex.

                            I might designate some local subset of the team as surrogate customer. Or
                            it might turn out that with enough phoning you could do OK. Are the
                            customers willing to engage? Do they all have different needs? Perhaps you
                            should tell us more about the customer situation ...

                            > 5. Development or even testing which is outsourced offshore (10 hr
                            > difference in timezone).
                            > Some of our testing is done in Asia..

                            If it were me, I'd just make sure that I never got a bug report from them.
                            I'd do that by testing on my side of the ocean, under whatever guise I
                            needed: writing my own tests, or using theirs.

                            > 6. Managers who live, breathe and bathe in the *waterfall*.
                            > Most of the members on the project team are unlike this, but
                            > everybody else (including systems that you have to interface with,
                            > and the customers) are so full of the waterfall process, it isn't even
                            > funny.

                            You're right. It isn't funny. In what ways does that impact your agile
                            efforts? Tell us a story.

                            And again ... where do you see the XP practices fitting least well in your
                            situation? Are the programmers interested? Are local managers? How much
                            interest is behind this idea in your organization?

                            Ron Jeffries
                            www.XProgramming.com
                            Sigs are like I Ching or Tarot. They don't mean anything,
                            but sometimes if you think about them you'll get a useful idea.
                          • Caroline Foster
                            ... Pair programming. ... No. They re scared (me included!) ... Some. More so with the architects. ... At the top level - loads (it s RUP not
                            Message 13 of 19 , Feb 5, 2003
                            • 0 Attachment
                              --- Ron Jeffries <ronjeffries@...> wrote:
                              > And again ... where do you see the XP practices fitting least well in
                              > your situation?

                              <interrupting/>
                              Pair programming.

                              > Are the programmers interested?

                              No. They're scared (me included!)

                              > Are local managers?
                              Some. More so with the architects.

                              > How much interest is behind this idea in your organization?

                              At the top level - loads (it's RUP not XP, but still with the focus on
                              iterations with releasable executables). Beyond that it's personal
                              motivation. Project Managers are the coaches but I don't think all of them
                              "get" it.

                              Caroline.


                              __________________________________________________
                              Do you Yahoo!?
                              Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
                              http://mailplus.yahoo.com
                            • Ron Jeffries
                              ... What s to be scared of? (See sig, not random this time.) Ron Jeffries www.XProgramming.com Don t be afraid of pair programming: You may not be as good as
                              Message 14 of 19 , Feb 5, 2003
                              • 0 Attachment
                                On Wednesday, February 5, 2003, at 6:11:42 PM, Caroline Foster wrote:

                                >> And again ... where do you see the XP practices fitting least well in
                                >> your situation?

                                > <interrupting/>
                                > Pair programming.

                                >> Are the programmers interested?

                                > No. They're scared (me included!)

                                What's to be scared of? (See sig, not random this time.)

                                Ron Jeffries
                                www.XProgramming.com
                                Don't be afraid of pair programming:
                                You may not be as good as you think you are, but
                                You're not as bad as you fear.
                              • Michael Kenny
                                ... The simple answer would be, it doesn t matter.
                                Message 15 of 19 , Feb 6, 2003
                                • 0 Attachment
                                  On Tue, 4 Feb 2003 08:19:02 -0500, you wrote:

                                  >> want such-and- such a system. That's it. Then you deliver it and noone
                                  >> can use it. In these projects XP will be considered a failure even
                                  >> though the failure lies elsewhere.
                                  >
                                  >Do you think there is a better way than XP to build software in an
                                  >organization like you describe?

                                  The simple answer would be, it doesn't matter.
                                Your message has been successfully submitted and would be delivered to recipients shortly.