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

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

Expand Messages
  • Chris Garty
    Beautiful... To add to this. Some small organisations have customers that seem to think that asking for a spec document and loads of documentation will
    Message 1 of 8 , Feb 2 10:50 PM
    • 0 Attachment
      Beautiful...

      To add to this. Some small organisations have customers that seem to
      think that asking for a spec document and loads of documentation will
      actually promote better development practices and outcomes. So it is not
      only the company but also its clients that must be focused functional
      utility of the software instead of the 'other stuff'.

      - Chris

      -----Original Message-----
      From: William Pietri [mailto:william@...]
      Sent: Monday, 3 February 2003 2:13 PM
      To: extremeprogramming@yahoogroups.com
      Subject: RE: [XP] How do agile methods survive in highly
      structuredorganisations


      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/


      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/
    • Ed Mostrom
      ... Sounds like just about every place I have ever worked. You probably also have an obscene number of departments dictating various aspects of your work
      Message 2 of 8 , Feb 5 1:40 PM
      • 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*.
        > >

        Sounds like just about every place I have ever worked. You probably also have an
        obscene number of departments dictating various aspects of your work life; and you are
        unlikely to change the viewpoint of even one of these areas. You will most likely
        never implement full XP; but that is not the point as someone else mentioned in another
        response "it is to create quality software" (I might add: in an environment we enjoy
        being in).

        Even with all of the corporate requirements, you can still probably adopt the somewhat
        agile methodology XP90 (90 % of what XP says to do.) If you are scraping the bottom of
        the process barrel, then adding even some of the principles are bound to help.

        The 2 most difficult principles to adopt in a typical corporate world are onsite
        customers and pair programming. I am not as strict as some - needing the customer and
        another programmer sitting on your lap while you work. In my opinion, we live and work
        in the high tech, so use the tools: e-mail, net conferencing, multicast work
        sessions... Someone looking at a monitor 300 miles away can pair program with you if
        you have the right tools. The other problem implementing pair programming is the idea
        that you will loose productivity sense 2 people are doing 1 thing. To be honest, you
        probably already pair program frequently... like when you ask for help and the other
        person comes over and you work through the code together. The concept just needs
        expanded more to become full time pair programming.

        The next most difficult parts to implement are probably going to be collective
        ownership and constant integration. I believe these can be done just about anywhere,
        if you have the right pieces in place and put things in slowly one at at time. The
        plan I am working on (which has not gone very far; but I am working on it) is as
        follows:

        1. Acceptance Tests
        Get the customer to define the acceptance test before "design" starts; and have the
        tests in place before coding starts. This will help solidify requirements making the
        design step (which you have to do because of corporate requirements) much smaller. It
        also means you won't be waiting on the customer well after the coding is done.

        2. Negative Impact Tests
        Put in the system to keep old acceptance tests and run them with each integration.
        Obvious benefit to the customer - more testing done on the app. Developers feel more
        comfortable releasing the product.

        3. Unit Tests
        Get the other developers to start doing unit testing, hopefully before coding, and add
        them to the test suite. Again helps the developers feel more comfortable.

        4. Constant Integration
        Once the above 3 are in place, you should be able to get approval from customer,
        project managers, and developers to check in your changes at any time as long as they
        don't break any of the tests set up. May take a lot of talking; but eventually people
        will get comfortable with the idea.

        5. Unlock the files
        If you live in an environment where files are locked by one person until their task is
        done, now is the time to switch to multiple checkouts. Make sure people are
        integrating often so they don't have a lot of conflicts to merge.

        6. Collective ownership
        With the other 5 in place, you already have the safety net in place to make sure you
        can't break anything. The only thing you can do is make the code better by refactoring
        and bug fixing.

        Hopefully the rest of XP will be easier to get in place at this point. These are my
        current thoughts on how to adopt XP in a traditional corporate setting.

        Ed
      • Ron Jeffries
        ... I pair program with physical presence a lot, mostly with Chet. We have tried setting up VPN or NetMeeting, and a speakerphone call. We both have high-speed
        Message 3 of 8 , Feb 5 4:09 PM
        • 0 Attachment
          On Wednesday, February 5, 2003, at 4:40:42 PM, Ed Mostrom wrote:

          > The 2 most difficult principles to adopt in a typical corporate world are onsite
          > customers and pair programming. I am not as strict as some - needing the customer and
          > another programmer sitting on your lap while you work. In my opinion, we live and work
          > in the high tech, so use the tools: e-mail, net conferencing, multicast work
          > sessions... Someone looking at a monitor 300 miles away can pair program with you if
          > you have the right tools. The other problem implementing pair programming is the idea
          > that you will loose productivity sense 2 people are doing 1 thing. To be honest, you
          > probably already pair program frequently... like when you ask for help and the other
          > person comes over and you work through the code together. The concept just needs
          > expanded more to become full time pair programming.

          I pair program with physical presence a lot, mostly with Chet. We have
          tried setting up VPN or NetMeeting, and a speakerphone call. We both have
          high-speed Internet connections.

          Our experience suggests that with that setup, remote pair programming is to
          real pair programming what love letters are to real love: a pale
          substitute.

          What are others' experiences doing it both ways?

          Ron Jeffries
          www.XProgramming.com
          First they ignore you, then they laugh at you, then they fight you, then you win.
          - Gandhi
        • Ron Jeffries
          ... And they re good ones, IMO. Ron Jeffries www.XProgramming.com How do I sell my executive team on doing this stuff? -- Questioner Don t. Just do it. They
          Message 4 of 8 , Feb 5 4:10 PM
          • 0 Attachment
            On Wednesday, February 5, 2003, at 4:40:42 PM, Ed Mostrom wrote:

            > Hopefully the rest of XP will be easier to get in place at this point. These are my
            > current thoughts on how to adopt XP in a traditional corporate setting.

            And they're good ones, IMO.

            Ron Jeffries
            www.XProgramming.com
            How do I sell my executive team on doing this stuff? -- Questioner
            Don't. Just do it. They don't know what you're doing anyway. -- Jim Highsmith
          • Ed Mostrom
            I agree that long distance pair programming is not the same as having someone right there next to you. But in a time when IT jobs are shrinking, it is nice to
            Message 5 of 8 , Feb 6 7:32 AM
            • 0 Attachment
              I agree that long distance pair programming is not the same as having someone right there
              next to you. But in a time when IT jobs are shrinking, it is nice to know I can work for any
              project/team regardless of where I am currently located.

              Ed


              Ron Jeffries wrote:

              > On Wednesday, February 5, 2003, at 4:40:42 PM, Ed Mostrom wrote:
              >
              > > The 2 most difficult principles to adopt in a typical corporate world are onsite
              > > customers and pair programming. I am not as strict as some - needing the customer and
              > > another programmer sitting on your lap while you work. In my opinion, we live and work
              > > in the high tech, so use the tools: e-mail, net conferencing, multicast work
              > > sessions... Someone looking at a monitor 300 miles away can pair program with you if
              > > you have the right tools. The other problem implementing pair programming is the idea
              > > that you will loose productivity sense 2 people are doing 1 thing. To be honest, you
              > > probably already pair program frequently... like when you ask for help and the other
              > > person comes over and you work through the code together. The concept just needs
              > > expanded more to become full time pair programming.
              >
              > I pair program with physical presence a lot, mostly with Chet. We have
              > tried setting up VPN or NetMeeting, and a speakerphone call. We both have
              > high-speed Internet connections.
              >
              > Our experience suggests that with that setup, remote pair programming is to
              > real pair programming what love letters are to real love: a pale
              > substitute.
              >
              > What are others' experiences doing it both ways?
              >
              > Ron Jeffries
              > www.XProgramming.com
              > First they ignore you, then they laugh at you, then they fight you, then you win.
              > - Gandhi
              >
              > 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
              ... There s an entire sub-culture of engineers who like to get on the internet and vocally worry about outsourcing moving their jobs to sweatshops in the
              Message 6 of 8 , Feb 6 7:39 AM
              • 0 Attachment
                Ed Mostrom sez:

                > I agree that long distance pair programming is not the same as having
                > someone right there next to you. But in a time when IT jobs are shrinking,
                > it is nice to know I can work for any project/team regardless of where I am
                > currently located.

                There's an entire sub-culture of engineers who like to get on the internet and
                vocally worry about "outsourcing" moving their jobs to sweatshops in the
                tropics.

                (Did I mention the worrying engineers were typically nordics?)

                Oddly enough, these are often the very same people who will scream at you if
                you try to bring up such simple "best practices" as "OnsiteCustomer" or
                "AllEngineersInOneRoom", or "FrequentReleases".

                Bosses outsource because they think they need fat teams. They don't; they need
                to be taught that running lean on-site teams with direct customer involvement
                is much more efficient.

                --
                Phlip
                http://flea.sourceforge.net
                -- "In my experience, the customer doesn't know what he wants
                until you don't give it to him." --David Brady --
              • Brent <me@other-space.com>
                ... wrote: [snip] ... programming is to ... I ve done some remote pair programming and one session of real pair programming, and I agree
                Message 7 of 8 , Feb 6 10:34 AM
                • 0 Attachment
                  --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                  <ronjeffries@a...> wrote:
                  [snip]
                  > Our experience suggests that with that setup, remote pair
                  programming is to
                  > real pair programming what love letters are to real love: a pale
                  > substitute.
                  >
                  > What are others' experiences doing it both ways?

                  I've done some remote pair programming and one session of "real" pair
                  programming, and I agree with Ron. However, remote pair programming
                  is still better than solo programming.

                  I'm going to remote pair program via IRC with a friend tonight (he
                  can't use a phone). Should be an interesting experiment.

                  --
                  Brent P. Newhall
                  http://brent.other-space.com/
                • Phlip
                  ... Done that once writing a Web site, where my brother could hit pages and examine them too. We weren t strictly in the same function at the same time, but
                  Message 8 of 8 , Feb 6 10:39 AM
                  • 0 Attachment
                    > I'm going to remote pair program via IRC with a friend tonight (he
                    > can't use a phone). Should be an interesting experiment.

                    Done that once writing a Web site, where my brother could hit pages and
                    examine them too. We weren't strictly in the same function at the same time,
                    but chatting on that little window in the corner, plus serving the new pages
                    cross country instantly, worked fine.

                    --
                    Chico Marx
                  Your message has been successfully submitted and would be delivered to recipients shortly.