Agreed 100%. But once you have people with the responsibility and authority and skill at determining based on actual users' workflows and feedback... in my opinion and experience, iterative design works -- even "rapidly iterating" ideally -- a lot lot better than assuming "functionality is relatively well known in advance", as the GP taneq suggested. Even experts at UX need iterative feedback to get it right, in fact an expert at UX is likely to know and tell you this, that's what their expertise tells them.

(And note even OP concludes by saying he does like "agile", just not "scrum" -- so taneq in arguing for avoiding rapid iteration for "functionality relatively well known in advance" is not necessarily making the same evaluation as OP either).

Part of what always happens in these discussions is we all come from our experience. I've seen it work, in such a way that convinces me it was because of it's iterative nature that it worked. taneq above, I would guess, has not.

As a field, we still haven't done great at working out a methodology to extract/abstract from these differing experiences to general consensus principles, when it comes to "how we write software". So we're all just arguing from our experiences, and such arguments show that experiences really differ. Not sure what to do with that. The arguments just go round and round. I don't think attempts to make this "empirical" and "data-driven" have proven satisfactory, they often seem to suffer from artificiality/lack of validity to me too.

(And as far as personal experience -- I think most of us who have been around 10+ years find that our opinions about 'the right way to do it' change over time, as our experiences show us different things; but that doesn't necessarily mean those who have been around longer are more likely to be right and should be defered to; clearly that defering to experience rarely happens anyway).