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

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

Expand Messages
  • Ron Jeffries
    Hello, Matt. On Monday, December 31, 2007, at 8:05:35 PM, you ... Cycle time, as I understand it, is the time from beginning to end of a process. We would
    Message 1 of 342 , Jan 1, 2008
    • 0 Attachment
      Hello, Matt. On Monday, December 31, 2007, at 8:05:35 PM, you
      wrote:

      > How do you think cycle time relates to productivity? Cycle time has
      > it's own issues of course but it seems that WRT to productivity in an
      > Agile environment what you really care about is how responsive you are
      > to the customers needs.

      Cycle time, as I understand it, is the time from beginning to end of
      a process. We would need to agree on when our productivity cycle
      begins and when it ends. One possibility is the time from when a
      story is given to the team to develop until it is tested, done done.

      A better definition would surely be the time from when a story is
      given to the dev team until it is deployed. Even better might be the
      time from when the story enters some queue (the Release Plan?) until
      it is deployed.

      It is this latter definition that leads to the idea that our story
      list constitutes a kind of waste. Perhaps in some senses it is,
      but it seems to me that when planning a software product, one
      needs some kind of feature list to work from. So it's kind of a
      dilemma to me on how to deal with this issue.

      Arlo Belshee's team reported using a short queue, seven items I
      think, with a note at the bottom indicating how long until ... I
      forget ... either the first unserved task is done, or until the last
      one in the list is done. (Someone remind me which it is?)

      Either way, this is giving a cycle-time sort of info and it should
      work quite nicely. The people managing the queue realize that big
      stories will slow things down, so they pick smaller ones, and so on.

      > One of the things about this conversation about productivity and
      > velocity that keeps eating at me is that it sounds an awful lot like the
      > kind of productivity conversations you hear in a non-Lean environments.
      > By using relative cycle-times as a measurement of productivity then we
      > might be able to give upper management a Lean measurement of what they
      > are looking for.

      Yes. I have been intentionally drawing attention back to what you're
      calling the "non-Lean" viewpoint, because that viewpoint is IMO by
      far the more commonly held in our profession. As you suggest here,
      we need to find some better way of communicating.

      As for relative cycle time, it won't be hard to quibble with it as a
      comparison. "But my stories are naturally bigger! But my customer
      doesn't have time to make small stories!" I encounter a lot of
      development teams who are at the mercy of customers we'd consider
      woefully inadequate. When the boss of such a team asks for
      productivity figures ... what are they to do?

      > This goes back to using RTF but not as a gross measurement but something
      > that relates to time. Thus if Team A has a cycle time of 2 weeks on new
      > feature requests and Team B has a cycle time of 4 weeks and they both
      > work on similar scoped features... then we can say something about the
      > amount of waste in the team can we not? And of course this means that
      > Team B is less productive... which is the non-Lean terminology for
      > "waste" IMO.

      I'm inclined to agree ... and it is all going to come down to what
      we mean by "similar".

      Happy new year,

      Ron Jeffries
      www.XProgramming.com
      Adapt, improvise, overcome.
      --Gunnery Sergeant Tom Highway (Heartbreak Ridge)
    • 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
      • 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.