But it might make it clear that it will fail much earlier and then at a lower cost.
Which *still* doesn't constitute success.
The term "agile development" covers a lot of ground. Much of what people mean by "agile" simply amounts to best practices (e.g. daily commits, unit testing, frequent builds etc.). But "agile" also refers to a kind of iterative and incremental approach to identifying and pursuing business goals in your project (exemplified by Scrum). That turns out to be a sensible and appropriate approach **in many but not all situations**.
Many development projects exist in a business environment where business needs evolve quickly, driven by both endogenous (management decisions) and exogenous (competition and market) factors. Likewise the software project itself, if it is reasonably successful, alters the very business conditions it is designed to address. *Under such conditions* you can't set out to build something in two years with any confidence that it will be what is needed twenty-four months from today. On the other hand, no programmer can be productive if he gets a different set of marching orders every day. You are forced by circumstances to adopt a flexible, iterative approach that allows the programmers to actually complete useful work before its specifications become obsolete, which contains the scope of *change-driven* failure and points your team in the right direction sooner rather than later.
But it is critical to remember that not *all* projects are like that. If you are writing software to control a spacecraft or a nuclear power plant, you don't sit down and bang out a little production code to figure out what it is you need to build. There's a lot more you can and should do to prepare for coding, and the classical engineering principle of discovering requirements as early in the process applies. It applies to the chaotic business situation too, but in that situation many requirements are simply impossible to anticipate.
In any case, the phrase "world's biggest agile project" should give any thinking developer pause. "Huge" and "agile" (in the goal-setting sense) don't go together. It seems to me that the idea of approaching *some things* in a waterfall manner (still using many best practices associated with "agile") and *others* in an interactive, exploratory fashion is the approach they should have been taking from the start.