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

RE: [XP] Re: Re: Re: alternatives to IXP...

Expand Messages
  • CORUM, M E [AG/1000]
    Steve, These are good questions. On the first question about why management would be against XP even though the project demonstrated good results, there are
    Message 1 of 48 , Apr 28, 2003
    • 0 Attachment
      Steve,

      These are good questions. On the first question about why management
      would be against XP even though the project demonstrated good results,
      there are several answers. Some of it has to do with people who just
      refuse to try anything new or who are smarter than me. Some of it
      would be hard for me to describe here since it is possible that others
      from my company may read this. As far as XP practices that this team
      still does (the one I call XP70), we still do test-first development,
      (both UTs and ATs), Pair Programming (if a particular manager is around,
      we do it less), continuous integration (although the already-small team
      was split into smaller teams by a manager to get some kind of apparent
      parallelism - this caused more difficulty integrating and caused our
      velocity to go down from 4.5 points to 3.5 points/week), Refactoring,
      Small Releases (somewhat), Simple Design, Metaphor, and a little bit of
      Collective Code Ownership, and Coding Standard. The hardest thing for
      the team to deal with is that we don't do the Planning Game. The thing
      that has replaced the planning game is more complex and less truthful.
      Sustainable Pace is also not practiced. We still get occassional trouble
      for pairing but the team has decided on their own to just ignore that
      and continue pairing. We experimented with pairing less and that resulted
      in that one bug that got into production as well as much more difficulty
      integrating (more tests were breaking when we didn't pair - it slowed us
      down). One particularly bad pattern is the pattern of certain people
      constantly challenging estimates in the meeting, which forces people to
      lie and give lower estimates. Then, certain people are upset that the
      team is missing its estimates. Those same people don't understand this
      simple and vicious cycle. I could go on and on... Thanks for your
      questions though.

      Mike Corum
      Monsanto

      -----Original Message-----
      >Message: 13
      > Date: Mon, 28 Apr 2003 09:14:01 -0400
      > From: Steve Berczuk <berczuk@...>
      >Subject: Re: Re: Re: alternatives to IXP...
      >
      >Two questions...
      >
      >CORUM, M E [AG/1000] wrote:
      >> Another project (with management pressure not to do
      >> XP because they read something bad about it in ComputerWorld and they
      just
      >> can't imagine how pairing could work) did its first four months at around
      >> XP70 and delivered its first production release with one production bug.
      >> That project also recorded the highest productivity numbers we've seen
      for
      >> comparable projects at our shop. This didn't persuade managers to like
      XP.
      >> Since then, the pressure to do less XP has increased and two people have
      >> been added to the team.
      >
      >- Do you have any insights into why management is against XP even though
      >the project demonstrated good results?
      >
      >- What is any XP practices can you still do, even without management
      >blessing, if they help you get work done? Which ones really need
      >managemet buy-in?
      >
      >I find these situations interesting. Most places that I started using XP
      >practices there was a lot of reluctance, but in the end, not a lot of
      >concern over How my team did their work as long as we delivered good
      >software on time. And once others noticed that our team tended to work
      >more effectively others seemed interested in adopting practices...
      >(Hence my questions about your situation...)
      >
      >-steve
    • Steve Berczuk
      ... I agree that the metaphors are not perfect. Metaphors just need to be analogous.... But if you think of the view of Achitecture that Christopher Alexander
      Message 48 of 48 , May 9, 2003
      • 0 Attachment
        glenlwood wrote:
        > All these metaphors fall short. I spend most of my days working in
        > high-rise offices. We the final user/customer for the office building
        > are only incidentally thought of when it is constructed. It is built
        > as an empty shell to be furnished and decorated much later for real
        > use. In fact the interior is often being 'refactored' for the
        > changing purposes.
        I agree that the metaphors are not perfect. Metaphors just need to be
        analogous....


        But if you think of the view of Achitecture that Christopher Alexander
        discusses, which is very interactive, or even building a custom house,
        there is a LOT of consideration of the needs of the user (or at least
        the customer).

        > Are the buildings equivalent to the hardware, networks and software
        > that is a given when most of us establish applications to exist
        > within this computing space?

        This leads me to think of an interesting issue: Buildings typically
        survive through many occupants and a long time... Some software does,
        some is made with a particular use in mind (and yet it still lasts a
        LONG TIME...) so the idea of refactoring is important in both building
        construction and software construction.


        --
        Steve Berczuk | steve@... | http://www.berczuk.com
        SCM Patterns: Effective Teamwork, Practical Integration
        www.scmpatterns.com
      Your message has been successfully submitted and would be delivered to recipients shortly.