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

Re: [scrumdevelopment] How to meassure new team learning overhead

Expand Messages
  • George Dinwiddie
    ... I would hope the team spends /all/ of their time learning about and adopting Scrum. That s not to the exclusion of accomplishing other work, of course.
    Message 1 of 6 , Aug 31, 2008
    • 0 Attachment
      Jan Behrens wrote:
      > In my company we have just (completed sprint 3 last Friday) started to
      > adopt Scrum with me 'mastering' the first team. I need to come up with a
      > reasonable idea of how much time the team spends on learning about and
      > adopting to Scrum. I basically need this split for discussions with
      > (senior) management. I wondered if anyone has some figures on this,
      > ideas on how to measure it or pointers to articles on this. The team
      > members are all complete newbies to Agile, as is the organisation.

      I would hope the team spends /all/ of their time learning about and
      adopting Scrum. That's not to the exclusion of accomplishing other
      work, of course.

      It's not clear to me what your senior management really wants. I
      suspect that they've asked one of those questions that is easy to ask,
      seems reasonable, but is devilishly difficult to define precisely.

      Are they trying to determine how much productivity is lost to the
      learning process during the "chaos" period of the change model? Are
      they trying to measure productivity changes relative to the prior way of
      working? How did they measure productivity prior to the adoption of
      Scrum? Was that productivity relatively stable over time, or were there
      peaks during projects and lulls between? If the latter, were both of
      these periods monitored for productivity?

      Have you had this conversation with senior managers? Or are you working
      just from a short request?

      > My thoughts so far revolve around looking at our velocity - basically
      > using the delta between velocity per sprint and the achieved velocity
      > around sprint 5 or 6 as I would hope the team will have adopted to a
      > first plateau by then. The (for me) necessary transfer to chargeable
      > hours would be relatively easy in such a scenario, and is one of my key
      > requirements :) What do you think, feasible, no good, ...?

      I think that will mostly measure estimation drift. If the team knows
      you're measuring that, then it will also dither the estimation.

      I think that you'll get a better feel for productivity changes with
      observations rather than measurements. I don't think software
      development productivity is quantifiable in a meaningful way.

      - George

      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    Your message has been successfully submitted and would be delivered to recipients shortly.