[oneshtein]

A customer of the software product need to know that after spending of $X dollars for Y days he will receive Z. In a working Agile project, PM must calculate team velocity and then use it to predict arrival time and expenses, then add/remove developers or features to meet budget and/or dead line. Agile manifesto says nothing about that.

[Kim_Bruning]

Perhaps the customer does want to spend $X to receive Z, this is fine. Probably they should consider buying something off-the-shelf.

Alternately, a different thing the customer might want is to Solve Their Problem; which is a fundamentally different thing, and requires a fundamentally different process.

[Tabular-Iceberg]

Well, they think they need that. What they really need is accomplish some business goal.

The Agile manifesto doesn't say anything about the former because it would defeat its own purpose.

[pydry]

The customer can demand that, but they need to understand that that also demands waterfall. It's unrealistic to have that kind of expectation and get anything other than cargo cult agile.

There are lots of consequences of doing "agile" properly that go way above the programmers' heads. That includes clients being able to specify requirements and price but not both at the same time.

I've worked on tons of teams where it was dictated from up on high that we should do agile and also do waterfall planning (always called something else). Agile consultants often have a tendency to accommodate this contradiction because up on high controls the purse strings and they need to eat.

The danger is that over time the things they do to eat become their identity and the genuine people get washed out of the industry.

We do need a sensemaking framework and a term which can be used to rule this type of thing out.