Observer effect
To find out if borscht is salted, it is enough to drop two electrodes into it, and then let current flow through them. If the smell of chlorine appears, then the soup is salted :)
In physics, there is such a thing as an “observer effect”: if a system is monitored, it makes a change in its behavior. Very interesting, this effect is manifested in the organization of the work of development teams (and indeed in any production processes). As soon as we start counting any metrics, we make changes in the behavior of the team and its individual members.
From the point of view of management, to measure in a numerical form (to introduce a metric), the idea, at first glance, is very sound. We get accurate data and on the basis of them we make the necessary actions. But, unfortunately, not everything is so simple: as soon as we enter a metric, the behavior of the team begins to change. The team and each of its members begins to adapt to the metric we have entered.
There is no need to go far for examples. Everyone knows the concept of “Hindu code”: as soon as developers start paying for the number of written lines of code, they start writing more code, often meaningless, forget about refactoring, making it unprofitable and so on. Thus, our performance measurement initiative turns against us.
')
You can try to reduce the number of defects in our product, for which we need to calculate how many bugs each developer made. We will award the best developers with bonuses, and apply the sanctions to the worst developers. Everything is simple and transparent. But in fact, it will be different: developers will argue on each bug with testers, there will be a fear and a desire to avoid risks, as a result of a lack of initiative and unwillingness to do the assigned tasks (“Less tasks, fewer bugs”). There is a very good topic on the topic “Living as a tester with a programmer” written by Yulia Nechaeva.
Let's come from the other side and we will calculate how many bugs testers find. In this situation, indirect effects will also appear, because each tester will regard the slightest deviation as a defect.
The conclusion from the above examples is simple, with the introduction of metrics, it is necessary to be guided, first of all, by the principle “do no harm”.
Analyze how measurements can affect the behavior of the team and its individual members. Moreover, the analysis should be carried out primarily on the non-obvious aspects that may not appear immediately. Consider which metrics can serve as a basis for discussion, for example, in retrospectives, if you use Scrum. Maybe your measurements are not really needed by anyone, and you measure, simply because you can measure?
Calculate how much time you spend collecting information on metrics. It is very likely that this process can be automated, especially if we are talking about code metrics, quality metrics and the like.
When introducing metrics, like any other innovations, it is very good to use the Deming cycle: Plan-Do-Check-Act, so that you have the opportunity to receive feedback from the team and make changes if necessary.
In physics, there is such a thing as an “observer effect”: if a system is monitored, it makes a change in its behavior. Very interesting, this effect is manifested in the organization of the work of development teams (and indeed in any production processes). As soon as we start counting any metrics, we make changes in the behavior of the team and its individual members.
"Do no harm"
From the point of view of management, to measure in a numerical form (to introduce a metric), the idea, at first glance, is very sound. We get accurate data and on the basis of them we make the necessary actions. But, unfortunately, not everything is so simple: as soon as we enter a metric, the behavior of the team begins to change. The team and each of its members begins to adapt to the metric we have entered.
There is no need to go far for examples. Everyone knows the concept of “Hindu code”: as soon as developers start paying for the number of written lines of code, they start writing more code, often meaningless, forget about refactoring, making it unprofitable and so on. Thus, our performance measurement initiative turns against us.
')
And yet, paradoxically, this is a very accurate metric. Two programmers in a team are governed by approximately the same number of lines for the same period of time. Of course, we need a lot of conventions (similar tasks, the presence of coding standards, for example, the maximum method length, no duplication, refactoring, and so on), but still the metric is quite accurate ... if you do not use it as a performance measure.
You can try to reduce the number of defects in our product, for which we need to calculate how many bugs each developer made. We will award the best developers with bonuses, and apply the sanctions to the worst developers. Everything is simple and transparent. But in fact, it will be different: developers will argue on each bug with testers, there will be a fear and a desire to avoid risks, as a result of a lack of initiative and unwillingness to do the assigned tasks (“Less tasks, fewer bugs”). There is a very good topic on the topic “Living as a tester with a programmer” written by Yulia Nechaeva.
Let's come from the other side and we will calculate how many bugs testers find. In this situation, indirect effects will also appear, because each tester will regard the slightest deviation as a defect.
The conclusion from the above examples is simple, with the introduction of metrics, it is necessary to be guided, first of all, by the principle “do no harm”.
What to do?
Analyze how measurements can affect the behavior of the team and its individual members. Moreover, the analysis should be carried out primarily on the non-obvious aspects that may not appear immediately. Consider which metrics can serve as a basis for discussion, for example, in retrospectives, if you use Scrum. Maybe your measurements are not really needed by anyone, and you measure, simply because you can measure?
Calculate how much time you spend collecting information on metrics. It is very likely that this process can be automated, especially if we are talking about code metrics, quality metrics and the like.
When introducing metrics, like any other innovations, it is very good to use the Deming cycle: Plan-Do-Check-Act, so that you have the opportunity to receive feedback from the team and make changes if necessary.
Yummy links
- www.slideshare.net/sergekovaleff/agile-base-camp-agile-metrics
- www.slideshare.net/krivitsky/agile-metrics-presentation-624960
- http://lib.custis.ru/__Agile_(to meet_AgileRussia.ru_2009-08-18)
- lib.custis.ru/Project_Metrics_for_Software_Development
- http://local.joelonsoftware.com/wiki/Consulting_to_estimated_productivity_(from_write)
- local.joelonsoftware.com/wiki/economic_motivating
- local.joelonsoftware.com/wiki/Productive Measurements
- en.wikipedia.org/wiki/Goodhart%27s_law
Source: https://habr.com/ru/post/118729/
All Articles