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

Re: [XP] Don't let them see our velocity?

Expand Messages
  • Steve Howell
    ... I definitely agree with the idea that improving methods should take precedence over setting numerical goals. On the other hand, I think numerical metrics
    Message 1 of 342 , Jan 1, 2008
    • 0 Attachment
      --- Matt <maswaffer@...> wrote:

      >
      > Steve,
      >
      > If we believe Deming, the root cause of variations
      > in output will be the
      > system itself. Since the worker (developers in our
      > case) don't have the
      > power to change the system by themselves, the root
      > cause of variation
      > then lies with management. (Of course in a healthy
      > environment,
      > developers will have an input into the process.)
      > This was Deming's
      > reasoning behind "eliminating numerical goals"...
      > the numbers are not
      > important, the methods that created those numbers
      > *are* important.
      > Managers who set goals rather than improving methods
      > are making a huge
      > mistake.
      >

      I definitely agree with the idea that improving
      methods should take precedence over setting numerical
      goals. On the other hand, I think numerical metrics
      are useful in focusing discussion on where current
      methods may be imperfect. Does Deming go so far as to
      eliminate numerical metrics?

      In my company the turn of phrase that we use is that
      "you never want to fix a problem by asking people to
      have better intentions." I think this is basically
      just a restatement of the Deming philosophy--you
      always want to fix the process, not the people.

      On the other hand, my company is big time into
      metrics. I'm actually starting to drink the kool-aid
      and liking it a bit, although I think numbers always
      have to be put in context, and for lots of problems,
      I'd rather hear subjective opinions (e.g. "the team
      feels they need more whiteboards") than raw numbers.

      > So in the context of this discussion, any manager
      > who wanted to
      > understand the variation in the velocity numbers
      > would need to
      > understand the methods that caused those variations.

      Yes indeed. I think the problem here is that the
      methodology to create velocity numbers includes a much
      larger human component than counting widgets shipped,
      mean time between procurements, etc.

      > We have already
      > discussed that there are any number of reasons that
      > velocity could vary,
      > including of course productivity. This mean
      > understanding and "fixing"
      > all of the methods that produce the velocity number.

      I think the core problem with the velocity number is
      that story size is recorded before the story is even
      implemented. One solution is to allow developers to
      re-rate the stories after implementation in some kind
      of retrospective.

      > So we would need
      > to have more accurate estimates, more normalized
      > story sizes from the
      > customer, similarity of experience across teams etc.

      I know that a lot of the original context of this
      thread was to compare two different teams, but I think
      the problems are even challenging in comparing the
      same team at two different times.

      > Show me a manager
      > asking for "productivity numbers" who is willing to
      > tackle all of those
      > problems... and I bet anyone on this list would
      > gladly report their
      > velocity numbers every week.
      >

      My manager, and actually most folks in our
      organization, *really* do want to tackle at least two
      of the problems you mention:

      - more accurate estimates
      - more normalized story sizes

      Our process is far from perfect, but we have a
      reasonably healthy environment, and nobody's really
      reluctant to report velocity numbers at this point.
      Our biggest problems are the following:

      - we put our hours into XPlanner, but we don't take
      the time to mine the data
      - just not enough process around planning and
      reflection
      - lots of work done in parallel



      ____________________________________________________________________________________
      Looking for last minute shopping deals?
      Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
    • Ron Jeffries
      Hello, Ilja. On Saturday, February 16, 2008, at 6:23:42 PM, you ... Well, it sounds like it would take a pretty narrow set of ideas on how to improve
      Message 342 of 342 , Feb 16 5:33 PM
      • 0 Attachment
        Hello, Ilja. On Saturday, February 16, 2008, at 6:23:42 PM, you
        wrote:

        > I expect this to increase our velocity in the middle run. And I'm all
        > for measuring it.

        > I doubt we would have even tried this event if we had focused on
        > improving velocity.

        > How does that sound to you?

        Well, it sounds like it would take a pretty narrow set of ideas on
        how to improve velocity. In a discussion on that, I would hope that
        ideas like learning, better tools, higher morale, and better
        communication would come up.

        Ron Jeffries
        www.XProgramming.com
        Anyone can make the simple complicated.
        Creativity is making the complicated simple. -- Charles Mingus
      Your message has been successfully submitted and would be delivered to recipients shortly.