Section 4.1. Using Metrics to Affect Behavior


4.1. Using Metrics to Affect Behavior

Metrics are essentially statistics that measure some aspect of our development process or the things we produce. Although there is a wide variety of interesting metrics, they can be divided into two categories: those that are fixed for a given iteration and those that the team can influence. For example, staff days per iteration is generally fixed at the beginning of the iteration,[1] but the amount of functionality the team can produce (this is sometimes called the team's velocity) is not fixed. Instead, the velocity is a measure of how the iteration is going (or how it went). The metrics that are fixed don't give us information about how the process is going, so we want to focus on metrics that the team or process can influence.

[1] Yes, we can hire more people in the middle of an iteration, but usually either we know they are coming or they arrive too late to be useful. Either way, their arrival doesn't change the plan in the middle of an iteration.

There is an old adage (whose source I cannot find) that says, "Tell me how you'll measure me and I'll tell you how I'll behave."[2] Metrics that affect behavior have been called biased metrics[5]. As an example of a biased metric, many teams track the number of running, tested features (RTFs)[4] in their system. This is a great way to get the team to focus on delivering functionality. In addition, RTFs decline if the functionality we add in this iteration causes existing features to no longer pass their tests, so there is a quality aspect to this measure. A chart showing this value over time will help the team focus on activities that are valuable.

[2] My father claims this quote is his and that its root is in how he raised me, but I think it originated with someone more famous than he!

However, using metrics to influence behavior must be done carefully, or you may get unexpected behavior. One company that was interested in training attempted to measure managers by the average number of hours of training his employees received each quarter. They also tracked overhead costs (of which training was a part) as a performance measure. As a result, some managers selected cheap training opportunities even if the person had received that training in the past. Clearly, these metrics were not causing the intended behavior.




Refactoring to Agility
Refactoring to Agility
ISBN: B000P28WK8
EAN: N/A
Year: 2006
Pages: 58

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net