Hacker News Reader

Comment by vp8989 | Hacker News Reader

Anecdotally, I've observed across my ~12 year career so far that an emphasis on estimates and estimating is negatively correlated to productivity, lead time, velocity, impact, positive outcomes etc...

I suspect the reason is because management is trying to use numbers to justify bin packing more work to an already oversubscribed team. What never shows up in those project management spreadsheets is the very real and predictable cost of context switching and the increase in mistakes from dealing with a larger amount of in-flight work.

View on HN

> 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".

Focus on releasing what?

On releasing whatever they are doing for people to use.

Somebody already answered "value". But that's too abstract to my taste.

Value.

Estimating and a lot of project management stuff is a form of procrastination for a lot of folks/businesses. It doesn't matter what fields the cards have or how they are arranged, the work still needs to get done, and all of this shuffling is just delaying the start of that work.

That's only true if there's a fixed set of work to get done. But that's rarely the case. Often, management has N different things they could have done, and enough people and time to do M of them, for M < N. Which ones should they do? Well, whatever maximizes profits. So they (management) estimate income from each thing that could be done, and ask engineering (hopefully) to estimate how much it will cost to implement (or how long it will take, which equates to cost). Then they make a (hopefully) more informed decision than they otherwise could have made.

Look, there's lots of ways this gets done badly. I get that. But the idea itself is not nonsense.

This is a cost centric perspective. I wish I could find the YouTube talk where Merck switched to a metric of "cost of not implementing" IE: how much revenue do you lose per day by not implementing. They found out of 100s of projects, that about two were 3 orders of magnitude larger, yet they delayed shipping those projects so they could get more in a release cycle, and diverted resources. From that new perspective, it was obvious that they should stop doing everything except those two projects. From the same talk, Microsoft found a third of projects were revenue negative! (Better to just not do them at all)

The point of the talk was ultimately that the revenue of projects usually dwarf the cost, to the extent that if a project is worth doing, it is clearly so whether it takes 3x or even 10x the time estimated.

At the team level, keeping M to 1-2 works really well in my experience. Of course M is never really 1 or 2 because you're always wrapping up small details from $previous, looking ahead at $next or just doing $maintenance. A reasonably sized team will be kept busy enough with "just" an M of 1 or 2.

The constraint helps to ruthlessly focus on the most impactful work. The maximalists want to get cute and try to bin pack but it just doesn't work, unfortunately.

That's an interesting thought. I've never considered it before, but estimation as procrastination might be a good explanation.

Totally agree. My management mostly is interested in estimates and deadlines . They never engage in discussions about productivity or quality. This results in people continuing ineffective processes and other systems. It also encourages people to make tests pass at any cost or close tickets even when there are deeper problems that should be resolved.

In short, the focus on estimates

Yep. If you don’t track the hours for The Process it’s just pure conjecture whether or not The Process is a value add.

the thing is, management is accountable to a budget, timeline, and an ROI. They have to be able to say how much something is going to cost, how long, and how much they're going to get in return. Now, a person doing the estimation has to be able to take everything into account, down to the cost of context switching, but those three things are all that matter upstream. Also, the people doing the estimations have to be able to answer questions like "well, what can you do in, say, half the time?". It's not easy.

Reply on news.ycombinator.com