Comment by marcosdumay
2 years ago
It sucked being that person back then too.
The idea of measuring everything and acting on the numbers you can get is from the 19th century. Managers have been doing that same kind of practice since then, with the same kind of result (it's a very reliable result), without a change.
A lot of that is from Frederick Taylor, who invented “scientific management”.
He did experiments where he would have workers shovel piles of ash from one side of a line to the next, giving them a new shovel size each day. Found that the ideal shovel size holds 21 pounds [1].
The ideological assumption of his work is that management exclusively does the thinking and the workers exclusively do the doing. This falls apart when the workers have unique knowledge and insight that management does not have.
[1] https://www.mentalfloss.com/article/63341/frederick-winslow-...
> when the workers have unique knowledge and insight that management does not have.
AKA every time.
AFAIK, Taylor himself wasn't nearly as radical about doing measurements and only acting on them nor about managers deciding everything and not listening to the workers as Taylorism preaches. His work was one of the many, many management theories that was completely modified to appeal to incompetent power-hungry wannabe dictators (and yet blamed on the person proposing the original theory).
Being superficial wasn't invented in the 19th century. People are very oriented to things they can see, measure and touch, when the most impactful and insightful people are often the silent care takers, the teachers, those keeping things running smoothly.
When you do things right, people won't be sure you've done anything at all.
Acting on the numbers you get is not intrinsically a problem: it's what the action is. Looking at how fast stories, function points or whatever get closed is important for planning what you can get done in a given time, and that can be crucial for project management and managing customer expectations. It's not acquiring the information which is a problem; it's not using the metrics which is the problem. The problem is not understanding what the metric can be used to represent (project velocity), and what it cannot (individual productivity);
Those are not important at all, or the top software projects would be using them. Linux kernel is doing fine without the velocity point story tickets. Agile "planning" which is used in worse software projects is snake oil.
It may be useful to collect metrics to get insights, but if they are publicized as a measure of performance, it's likely they'll be gamed, making them less useful.