zlacker

My most productive team did no time estimates at all (short of very very rough project estimates i.e. "yeah I'll work on this project for at least the next quarter then we'll see"), and instead of spending endless time in planning meetings determining how complex a task was, we instead spent that time just doing the thing.

>>mgfist+(OP)
How did you align with other teams?

I agree it's best if working in isolation, but if you need to synchronise then estimations make sense.

If you need 3 months to implement something, and another team 1 week, and both need to be ready at the same time; then if you actually know those estimations the second team can wait until then and do something immediately useful in between.

>>Lehere+7W
Yes, then you must have a rough estimate for that. Or in the other extreme example - in the case of an outage, estimates must be much more precise (i.e. "we should have a workaround in ~30 minutes").

But neither case requires too much thought or discussion. My point was more that estimation ends up overwhelming time and energy, when you can just do the thing instead. I've worked on teams where we've spent more time arguing about how complex a task than it would've been for someone to crank out a solution.

I also don't mean engineers shouldn't collaborate, just that it should be more ad-hoc and not manager/tpm/scrum-master driven.