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

How do agile methods survive in highly structured organisations

Expand Messages
  • Michael <zzmlane@bigpond.com>
    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
    Message 1 of 19 , Jan 31, 2003
    • 0 Attachment
      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?
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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.