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

Re: Performance Metrics for Engineers in a Scrum Environment

Expand Messages
  • petriheiramo
    Hi, Resurrecting also this old thread... ... Regarding measurement, these are a good start. I also like the idea of measuring automated test coverage (although
    Message 1 of 9 , Aug 24, 2009
      Hi,


      Resurrecting also this old thread...


      > Mary Poppendieck suggests 3 holistic measures to focus on:
      >
      > 1. Average Cycle Time – how long things take to go through the system.
      > E.g. requirements from capture to acceptance and defects from
      > detection to correction.
      > 2. The Business Case – Is the project still viable? Without this,
      > everything else is irrelevant.
      > 3. Customer satisfaction – are your customers happy?

      Regarding measurement, these are a good start. I also like the idea of measuring automated test coverage (although more as information than with a numeric goal) and escaped bugs per iteration (with the goal of making this a zero).

      However, regarding the need of the management, what I usually find them to want is a solution to this equation:

      Productivity = Value / Cost

      In other words, they are interested in how to squeeze out more from the business operation. It is very easy to read that equation in the wrong way. "Hmm... Cost... if we can lower that, we have increased productivity"

      What kills the equation is that Cost and Value are not independent of each other. Nor are they linearly dependent. Their relationship is pretty complex, because it is possible to have the following scenarios:
      - Value increases with additional Costs
      - Value increases while costs are reduced
      - Value reduces while more money is poured into the pit
      - Value reduces with Cost savings
      And because they are related in many situations, we may have simultaneous changes ongoing, making it impossible to evaluate the effect of any individual change.

      The second killer is that so far I haven't yet found a way to measure value. I think Poppendieck's have come closest in their recommendation to build a financial business scenario, but even that approach has trouble including such things are fickle customer preferences (which are essentially incorporated in the revenue estimates). So, as soon as your management has found a way to measure the Value generated by their business, they can start applying the formula :).


      Because management cannot solve the equation, they should not assume Value stays the same while Costs can be adjusted. Instead, they should focus on things that affect the ability to generate value in the system, such as:
      - quality of the deliverables and process
      - speed of delivery and reaction
      - ability to learn and share learning
      - capability to react to unexpected situations
      - ability to incite excitement in users with the product


      Yours Sincerely,


      Petri

      ---
      Petri Heiramo
      Process Development Manager, Agile Coach (CST)
      Digia Plc., Finland
    Your message has been successfully submitted and would be delivered to recipients shortly.