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

Re: [XP] Velocity as a productivity metric

Expand Messages
  • Tim Ottinger
    Well, sustained cycle time maybe. Burst cycle time shouldn t be rewarded. You can make your work seem faster for a little while by super effort or by cutting
    Message 1 of 83 , Apr 3, 2012
      Well, sustained cycle time maybe. Burst cycle time shouldn't be rewarded. You can make your work seem faster for a little while by super effort or by cutting corners, but those don't hold out over the long run. Eventually, bad practices catch up to you.  If you cut a day or two off of a two-week cycle time, don't be too quick to hand out kudos or promotions. 
       
      Consider your last interaction with a call center that was "serving to metrics" rather than solving your problem.

      Tim Ottinger
      http://agileinaflash.blogspot.com/
      http://agileotter.blogspot.com/


      >________________________________
      > From: Amir Kolsky <kolsky@...>
      >To: extremeprogramming@yahoogroups.com
      >Sent: Monday, April 2, 2012 3:02 PM
      >Subject: RE: [XP] Velocity as a productivity metric
      >
      >Bugs are directly related to cycle time. If you have no bugs - you don't
      >have to rework and hence the cycle time stays short.
      >Code qualities have to do with cycle time - it takes less to execute and
      >there are less chances for bugs which again, relate to cycle time.
      >
      >It seems to me that cycle time is *the* metric that shows technical
      >improvement. Note the usage of "seems". If anyone could suggest an aspect
      >that is not covered by cycle time, please do so, as it will allow me to
      >refine my model :-)
      >
      >

      [Non-text portions of this message have been removed]
    • RonJeffries
      Hi Adrian, ... Yes. Here s a random thought that I had about how a reduction in cycle time might not be good. Suppose when a feature comes in, we ship the
      Message 83 of 83 , Apr 9, 2012
        Hi Adrian,

        On Apr 9, 2012, at 8:29 AM, Adrian Howard wrote:

        > However what I'm hearing from Amir (which may, of course, be in my head not his words) is that he's generally in a situation where he's *confident* that a decrease in cycle time is a "good thing". Likewise for increases in cycle time being a bad thing.
        >
        > I don't generally find myself in that place - I'm interested in figuring out one or more of:
        >
        > * How I can do this
        > * Why Amir can do it in his context, and I can't do it in mine
        > * How I'm misunderstanding what Amir is saying (or vice versa)
        >
        > Sound vaguely sane?


        Yes. Here's a random thought that I had about how a reduction in cycle time might not be good. Suppose when a feature comes in, we ship the current software and report the feature done. Cycle time drops quite low. Good, huh?

        Of course we'll have a lot of bug reports. But we handle them the same way: ship the current software and report the bug fixed.

        I'd like to hear from Amir on this one. :)

        Ron Jeffries
        www.XProgramming.com
        If not now, when? -- Rabbi Hillel



        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.