The agile community have been saying that you need to be agile in order to respond to changing requirements.
Well in actual fact the requirements don't generally change all that often. Rather what changes is the understanding of the requirements and the domain.
Perhaps because the agile community get this wrong they come up with some really bad advice - they say you should defer making the most critical decisions!
As an example, see The Last Responsible Moment by Jeff Atwood (2006) which says:
Making decisions at the Last Responsible Moment isn't procrastination; it's inspired laziness. It's a solid, fundamental risk avoidance strategy. Decisions made too early in a project are hugely risky. Early decisions often result in work that has to be thrown away. Even worse, those early decisions can have crippling and unavoidable consequences for the entire future of the project.
For another example, see Lean Principle #4 – Defer Commitment by Kelly Waters, 2010, which says:
... decide as late as possible, particularly for decisions that are irreversible, or at least will be impractical to reverse. Timebox critical decisions for the latest point they can be made without causing problems.
See as well the blog post Building Real Software (2012) by Jim Bird.
The advice is bad when it's unqualified - i.e. when it doesn't account for what might be learnt by making a decision early. Some decisions should be deferred, some shouldn't.
Decisions about things that are unlikely to provide deeper understandings of the domain should be deferred.
But decisions for which you are likely to learn a lot about the domain should be made early. Generally speaking the best way to minimise wastage it to learn fast and fail fast. The "grunt work" should occur late in a project not early - i.e. after you have a deep understanding of the domain.
The agile community claim requirements change all the time, when really it's the understanding of the domain that changes. You get understanding by trying things out, and learning from mistakes. Making the most critical/important decisions early is the best way to fail early and develop an understanding of the requirements and the domain, and to mitigate risk and avoid wastage. There are lots of important lessons to be learnt, you want to learn those lessons sooner not later. Sometimes you need to fail before you can succeed. Knowing what doesn't work can represent significant progress.
Putting off hard decisions means you are doing what appears to be the straightforward tasks first - But if you haven't developed a deep understanding of the problem domain yet, maybe the straightfoward things will be impacted. There is no substitute for a deep understanding of the domain.
The fastest way to understand the impact of a decision, is to make a choice and see where it leads. If you find it was the wrong choice then it's ok, you have developed a much better understanding of the domain.