Your second option of trying something for a while and then saying if it will take more than 3 weeks to finish is still estimating. I don't disagree that it'll

Your second option of trying something for a while and then saying if it will take more than 3 weeks to finish is still estimating. I don't disagree that it'll result in a far more reliable estimate as you've had time to really feel out the problem and get an idea of what's really involved, but at the end of it you're still giving an estimate of less than three weeks. I think many people's aversion to estimates comes from a culture like the one you're describing in your first option, one where developers are asked for estimates but they're taken as hard commitments. The solution to that sort of culture is exactly the opposite of the one being proposed in this manifesto - instead of siloing ourselves away further and avoiding contact, we should communicate more. (Good) managers don't get angry at a 2 week task taking 6 weeks, they get angry at finding out that the 2 week task will take 6 weeks only after we hit the point at which they were expecting everything to be done. With a little intuition we can tell that a task is going to miss its deadline long before that deadline hits - presumably we've broken things down into smaller sub-tasks, if we haven't completed 25% of those when you're about 25% of the way in, we're going to miss our deadline. The typical developer has a tendency to convince themselves they'll catch up later on, I certainly do, but in all likelihood we won't. That 25% point is the time to sit down with the manager and talk things over. Bring options, make it clear that if the deadline matters that much some features might have to be dropped, or released later. Or maybe the deadline doesn't matter, but they'll need to rearrange things so that another person is working on a feature which has a deadline 6 weeks out. I get how appealing the proposal to just do away with deadlines, meetings, and regular updates can be, but that's only practical in an organisation entirely staffed by developers without any outside influences. Those influences will include all sorts of things, from investors to the season (woe betide the retailer who didn't bother estimating how long functionality to handle Christmas orders was going to take and released it on the 26th of December because that's when it was done). In the real world you're not building features in isolation so we need a way to communicate to others what they should expect, and when they should expect it.