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

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

Expand Messages
  • Ron Jeffries
    ... Are you trying XP now in such an organization? If so, what s happening to you? If not, what are your concerns? Ron Jeffries www.XProgramming.com Sorry
    Message 1 of 19 , Feb 1, 2003
    • 0 Attachment
      On Saturday, February 1, 2003, at 1:38:51 AM, 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.

      > Can could you share us your experiences, frustations, remedies?

      Are you trying XP now in such an organization? If so, what's happening to
      you? If not, what are your concerns?

      Ron Jeffries
      www.XProgramming.com
      Sorry about your cow ... I didn't know she was sacred.
    • Michael Lane
      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
      Message 2 of 19 , Feb 1, 2003
      • 0 Attachment
        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


        -----Original Message-----
        From: Ron Jeffries [mailto:ronjeffries@...]
        Sent: Saturday, February 01, 2003 11:21 PM
        To: extremeprogramming@yahoogroups.com
        Subject: Re: [XP] How do agile methods survive in highly structured
        organisations

        On Saturday, February 1, 2003, at 1:38:51 AM, 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.

        > Can could you share us your experiences, frustations, remedies?

        Are you trying XP now in such an organization? If so, what's happening
        to
        you? If not, what are your concerns?

        Ron Jeffries
        www.XProgramming.com
        Sorry about your cow ... I didn't know she was sacred.


        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/
      • Phlip
        ... 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
        Message 3 of 19 , Feb 1, 2003
        • 0 Attachment
          > 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! --
        • 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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.