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

Re: [extremeperl] estimation

Expand Messages
  • Tom Brown
    ... Not it my experience. Pair programming and testing were harder to introduce to an environment foreign to those concepts... and the test suites are of
    Message 1 of 3 , Jan 28, 2002
    • 0 Attachment
      On Mon, 28 Jan 2002, Perrin Harkins wrote:

      > Not perl-specific, but kind of an XP thing:
      >
      > I am trying to convert the management at my organization to a more XP way of
      > thinking regarding estimates. I just had a meeting about a longer-term
      > project (about 3 months) where I told them that I can provide a working
      > release every two weeks, and they can choose the most important features
      > they want in the next release each time. They were very reluctant. They
      > would much rather have me tell them a date when all of their features will
      > be done, and I think they would rather have this regardless of whether or
      > not the date is correct.
      >
      > They just can't deal with the idea of working on the most important features
      > until the systems has enough to go into production, or even with working
      > toward a date and dropping features as necessary to hit it. I wonder if
      > this is the biggest obstacle to getting XP practices adopted. I also wonder

      Not it my experience. Pair programming and testing were harder to
      introduce to an environment foreign to those concepts... and the test
      suites are of course core to the whole methodology.

      I found the XP scheduling methods to be intuitive and make so much sense
      that I would expect anyone to understand and agree. Can you just buy
      whomever doesn't understand lunch, and try explaining it again? Maybe
      putting it in context with the what you describe in the next sentence
      would help?

      > if this is all the fault of consulting companies, who always seem to give
      > exact dates, even though they never hit them.

      So, give them a date. If they don't want the benefits, they don't have to
      have them. Of course, you do need their assistance for continuous
      feedback, so maybe it isn't that simple....

      >
      > - Perrin
      >
      >
      >
      > To unsubscribe from this group, send an email to:
      > extremeperl-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >

      ----------------------------------------------------------------------
      tbrown@... | Courage is doing what you're afraid to do.
      http://BareMetal.com/ | There can be no courage unless you're scared.
      | - Eddie Rickenbacker
    • Ged Haywood
      Hi Perrin, ... For the last two thousand years or so, people who have tried to change the way other people think have usually wound up nailed to something. ...
      Message 2 of 3 , Jan 28, 2002
      • 0 Attachment
        Hi Perrin,

        On Mon, 28 Jan 2002, Perrin Harkins wrote:

        > I am trying to convert the management at my organization to a more
        > XP way of thinking regarding estimates.

        For the last two thousand years or so, people who have tried to change
        the way other people think have usually wound up nailed to something.

        > I just had a meeting about a longer-term project (about 3 months)
        > where I told them that I can provide a working release every two
        > weeks, and they can choose the most important features they want in
        > the next release each time. They were very reluctant.

        They probably don't believe you.

        > They would much rather have me tell them a date when all of their
        > features will be done, and I think they would rather have this
        > regardless of whether or not the date is correct.

        They KNOW the date isn't correct, it's called 'experience'.

        > They just can't deal with the idea of working on the most important
        > features until the systems has enough to go into production, or even
        > with working toward a date and dropping features as necessary to hit
        > it. I wonder if this is the biggest obstacle to getting XP
        > practices adopted.

        If you put it like that, it will be an obstacle. You are in effect
        saying "we know we are going to fail, we just don't know by how much
        until after it's happened". Terrible sales pitch.

        > I also wonder if this is all the fault of consulting companies, who
        > always seem to give exact dates, even though they never hit them.

        Well, 'never' is arguable. I remember once estimating 30 days for a
        bit of assembly language coding and delivering it on day 29. (OK, it
        was in 1982, but I still have the PERT chart. On the wall.:)

        This has got nothing to do with the technical merits of the case, nor
        with consulting companies charging big bucks to make wild guesses.
        The point is they are saying "we will succeed". People like that a
        lot better, it gives them someone to blame when it all hits the fan.

        Don't forget that the people you are dealing with have their careers
        to think about. Most people are not high fliers, and it's really only
        high fliers who cope well with risk. Even if the chances of failure
        are small (and if that were the case you wouldn't get a kick out of
        success, would you?:) for most people it's much more important to have
        someone/something to blame in the case of failure than it is to have a
        high chance of success. That way it won't look bad on their CV.

        So be strong, make carefully reasoned estimates with confidence, and
        don't be scared of taking the risks - and the blame. After all, the
        worst that can happen is that you'll find yourself looking for work.

        73,
        Ged.
      Your message has been successfully submitted and would be delivered to recipients shortly.