4.1. Using Metrics to Affect BehaviorMetrics 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.
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.
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. |