> that an emphasis on estimates and estimating is negatively correlated to productivity
When the estimates and their accuracy become the primary goal, productivity is secondary.
My worst experience with this was a company that valued roadmap accuracy so highly that we were rated on our on-time delivery more than anything else. The inevitable result was heavily padded estimates and teams who carefully avoided doing any more work than necessary (yes, early delivery was technically negative points for your bonus). The pace of work was incredibly slow and methodical, but the company got their metrics optimized. Madness.
The opposite end of this spectrum isn’t great, though. There’s something about teams that pride themselves on no estimates and no deadlines leads a lot of people to spin their wheels forever. I’ve also been stuck on some teams with endless cycles of rewrites and refactors and switching to the latest language or framework every 6 months. We did a lot of work, but didn’t ship a lot.
There is a middle ground that is much nicer than either extreme.
> There is a middle ground that is much nicer than either extreme.
That middle ground is focusing on releasing. It is done on a completely dimension from the "estimate everything" vs. "estimate nothing" duality of your post. So I really disagree with your characterization of it as "middle ground".
When the estimates and their accuracy become the primary goal, productivity is secondary.
My worst experience with this was a company that valued roadmap accuracy so highly that we were rated on our on-time delivery more than anything else. The inevitable result was heavily padded estimates and teams who carefully avoided doing any more work than necessary (yes, early delivery was technically negative points for your bonus). The pace of work was incredibly slow and methodical, but the company got their metrics optimized. Madness.
The opposite end of this spectrum isn’t great, though. There’s something about teams that pride themselves on no estimates and no deadlines leads a lot of people to spin their wheels forever. I’ve also been stuck on some teams with endless cycles of rewrites and refactors and switching to the latest language or framework every 6 months. We did a lot of work, but didn’t ship a lot.
There is a middle ground that is much nicer than either extreme.