The point being that, at that level, it's more important to know how to deploy your soldiers toward a goal as opposed to the low-level details of every individual task.
I never give estimates, to the great fury of my boss, but I told him I don't want to lie.
Lying is unethical, and accepting a lie, or not calling out a liar, is encouraging unethical behavior.
If someone tells me: "I'll have an answer, or: be done with the work, by a certain date/time, I shake my head, then reply: "Don't make promises. Just let me know when it's done."
Estimating is hard, but it's an estimate. Problems usually arise when one gives an estimate of 'X days' and what the manager hears is 'It will take X days, and no longer.'
An estimate will increase in accuracy the more you know, so if you don't feel comfortable giving an estimate, ask the question: "What information do I need to know to give me comfort for an estimate of Y% accuracy" and ask more questions.
If each iteration is producing sufficient independent business value (e.g., not dependent on subsequent iterations), then you don't have to estimate the size of the "overall project" to determine if it is worth starting. That's actually a key part of the risk mitigation provided by agile/lean methods.
When they say "How long will it take to do the estimate?" I reply: "I have no idea until I get into the details of the problem."
When management asks for an estimate, with rare exceptions, they actually mean: "We are putting pressure on you to get this done by a certain date, but we don't want to tell you what that date is, and we're betting that if you give us a low estimate now, you'll pressure yourself to meet your own deadline, and we won't have to manage the project."
The problem with that type of reasoning is that in the end, the workers are stressed, and the solution is suboptimal.
That may be so, but the military environment is different. Officers need to be able to make good-enough decisions on the spot, without the benefit of careful consideration, because there might be a literal dead line, after which people die. Sometimes being in motion is more important than the actual direction.
I have been thinking about this a lot over the past months, most teams and projects fail because people get in over their head by
* Not analyzing the problem deeply enough (hrs not weeks)
* Estimating too early, they don't want to look weak
* Not revising estimates once they are in it (heroic save)
* Not asking for help or re-analysis from outside minds
As a poster above mentioned, accepting a bullshit answer is being complicit in a lie. We need to push back in a polite way when we are being bullshitted. By accepting poor estimates (in all the dimensions of poor) we enable failure.