While I completely agree with you about the "investment today produces tangible value today", I must say that this is probably the most common error made by so-called agile teams.
Let me step back a bit and ellaborate...
A project (according to both PMI and Prince2 standards) is something that has:
- a start
- an end
- delivers a specific product.
It's a common misunderstanding that scrum (or xp, or whatever) is a "Project Management" methodology. This is simply not true, because in Scrum the so-called project doesn't have an end and it doesn't deliver a specific product. Scrum (or xp, or whatever) is a "Software Development Process". This might seem like a silly conceptual nitpicking, but it does make a huge difference.
Agile methodologies are very much useful for contracts of ongoing maintainance and evolution of a already running software, because in that case, the idea of "release soon, release often" is the most efficient way to deliver the most value-added to the customer. Keeping it in strict time-frames gives a better manageability of the integration, release, deployment cycles. Although this is often called that way, it is not, by any formal definition, a project. It's an ongoing process.
The basic practical difference between a "project" and an "ongoing process" is the management of the stakeholders and the expectation of the scope of the work. When you have an ongoing process, you should do now the work that adds value now. When you have a project, you have a "specific product" you must deliver, and it doesn't matter how much you try to transfer the role of "requirement analisys" to the customer, it is only going to get back to your face. In a project you really need to do the "big design up-front", otherwise you'll have too much scrap, and nobody wants to pay that.
And this is probably the hardest part to understand. Even if you want to embrace agile methodologies, you need to understand that the first release must be managed as a project, with a start, an end and a specific product to deliver. You need to do all the requirement analisys of this first release (I even recommend making an effort to turn it into the smallest possible project), but you can't do that first release in "sprints", because it doesn't make any sense precisely because you are not adding any value because the system is not in use yet.
So build your planning, assign the resources, keep room for fixing bugs and eventual misunderstanding of the requirements. And move to a agile methodology as soon as the system is up, running and successfully deployed. But never before that.
Rework is not always scrap, but rework when the system is not yet deployed is always scrap. Most failing Agile "projects" I've seen were failing because they forced agile in the "first release", and the customer simply refuses to pay for rework or to features misprioritization while the system is not yet deployed.
