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

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

Expand Messages
  • Steven Gordon
    ... More than just input. Under agile, the team owns its process. The team responsible for modifying their process in response to feedback. This is the point
    Message 1 of 342 , Jan 1, 2008
      On Jan 1, 2008 4:32 PM, 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.)

      More than just input. Under agile, the team owns its process. The
      team responsible for modifying their process in response to feedback.
      This is the point - velocity is just one of many feedback mechanisms
      the whole team consults to guide how it modifyies its own plan and
      processes.

      Management should indeed hold the whole team responsible for its
      effectiveness. However, velocity is just one of many relevant
      factors, so it should never be the sole measure of whether the team is
      being effective (or even whether the team is improving its
      effectiveness).

      Furthermore, because each team owns its own process and will modify it
      in response to different feedbacks from different contrasts, variation
      is to be expected as the processes diverge. So, while Deming may be
      right that the variation is due to the "system" itself, this
      observation does not help much when there are multiple evolving
      systems.

      > 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.
      >
      > 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. 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. So we would need
      > to have more accurate estimates, more normalized story sizes from the
      > customer, similarity of experience across teams etc. 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.
      >
      > Matt
      >
    • 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, 2008
        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.