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

1982RE: [scrumdevelopment] What's wrong with tracking estimates vs. actuals?

Expand Messages
  • Marc Hamann
    Oct 6 9:53 PM

      >I think there is a danger of "doing agile" for the
      >sake of it. The real goal is to make more money by
      >delivering more value faster to the end of value

      I agree that "doing agile" is not an end in and of itself. Providing
      return on investment and return on expectation is the real goal.

      We do this by producing working software that fulfills the needs of the
      customer. I'm quite skeptical that we can do this by producing "metrics".

      The only metric that counts is how many of the customer's requirements we
      clear out of the backlog by delivering well-made, working software for a
      given cost.
      Any other metric may or may not be a helpful guideline to help you
      accomplish that primary goal, but some metrics are blatantly
      counter-productive because they encourage the wrong behaviour.

      I'm glad you agree that SLOC is not a good metric; crappy code can eat up
      WAY more lines than good code. ;-)

      >One of the big problems with agile successes is that
      >they get reported in a relative manner

      I suppose part of our disagreement comes from our different concerns. You
      want to bring a scientific study to the successes of particular cases.
      Though I'm skeptical that you can ever factor out all the variables that go
      into a large project and isolate with absolute objectivity that one method
      is better than another, I can understand why you want to do this.

      However, I'm in the trenches, and the only reason I give a fig about the
      Agile methodologies is that they offer approaches and techniques that solve
      my real day to day challenges in building good, reliable, low cost
      software. What Chrysler did, or some offshore bank, though perhaps of
      academic interest will not sway me one way or another as to whether those
      techniques will work for me. If they work for me, I use them, if they
      don't, I won't.

      >So I fail to accept that you can assert that adhoc,
      >self-organizing processes can outperform lean
      >processes which still include aspects such as planned
      >versus actual dates.

      Well, since we are unlikely to find mutually satisfactory metrics for
      determining performance, I don't think I would make that claim. ;-)

      However, I do know that professionals who are too valuable to be fired are
      smart enough to tell when they are being micro-managed or babied, and
      neither of these brings out high morale, creativity and "can do" spirit.

      Remember that people will focus their energies on whatever you measure to
      evaluate them. If you measure their ability to estimate rather than their
      ability to produce working software, you will encourage them to pace their
      work to the plan, rather than doing the best they can always, to avoid
      taking risks that might throw their estimations off, even if it would
      improve the product.

      I can't see how that will improve productivity. In fact, I wouldn't
      believe it were so even if you showed me some metrics. ;-)

      >When you can show me the metrics
      >from real projects reported in a normalized fashion,
      >from projects performed in large businesses with large
      >value-added or revenue generation potential then I
      >might start to believe.

      When the Buddha was asked "Why should I believe what your saying?", he
      replied "Don't believe it. Try it for yourself ."

      I can't improve on that. ;-)

    • Show all 20 messages in this topic