2 ms·
I agree > but I'm often surprised at the kind of negative reaction I get when I bring it up. Because they assume you are trying to hide or obscure something.
by rdtsc 10y ago
I agree
> but I'm often surprised at the kind of negative reaction I get when I bring it up.
Because they assume you are trying to hide or obscure something. "Why wouldn't you want more 'visibility'?" kind of stuff.
Then if you explain, unless they completely trust your reasoning, they think "Oh this is just a rationalization".
Moreover, over time metrics, and processes, and rules just accumulate. Every time anything bad happens -- new rule and some new metrics get added. Sure after a while they are ignored, but they are still there. Then nobody wants to be the person to say, let's clear the table of these unused rules and metrics let's have less.
- mikekchar 10y agoOne of the biggest issues I've run into is that people honestly don't believe that measuring will change behaviour. They feel that "Let's measure this just in case we can use it some time" is a good strategy. I can't tell you the number of times I've had the following sort of conversation with a developer: "This story is not finished. It doesn't work at all". "I know, but my estimate was 2 days and I've already worked 3 on it. Can't we just add another story to do the things that aren't finished? We're already taking a lot of criticism for being slow. I don't want to let the team down." Then you have a finished story called "Add login to system" and an unstarted story called "Fix problems with login". The stake holder sees the list and says, "We can live with a few problems with the login system as long as the core functionality is there. Let's ship!" But... nobody wants to admit that login doesn't work at all so they look the other way... Absolute craziness that would be avoided if completion times were not measured.