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.

... rework when the system is not yet deployed is always scrap...

I question that because:

... keep room for fixing bugs...

... and:

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.

"Just plan harder so you don't write bugs" is hardly realistic.

(If you define "scrap" as "stuff you have to throw away because it has provided no value", then you have a circular definition you can only break by redefining "value". You get to pick what you rework: is it the BDUF spec several months later or is it code minutes to days later?)

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.

Every reputable agile method of which I am aware suggests this explicitly.

The problem are not in the bugs -- bugs are inevitable. What you can avoid is going in one direction for a time and then realizing that was not the right direction before delivering any value to the customer. This is the kind of rework that nobody wants to pay for, and that happens too often in some so-called agile teams -- specially the ones that try to agil'ize the first release.

daniel