I consider fleshing out customer requirements part of the engineering process. You cannot expect the customer to properly communicate what they want/need. That doesn't mean Scrum, you have many other tools at your disposal, presenting the customer with scenarios to challenge their requirements, use interactive prototypes or even paper ones. All of them far cheaper than implementing the wrong thing.
I agree about the pitfalls of not seeing something usable until it's very late and how to measure progress. The opposite is also true however, you make some easy non-scalable PoC and it looks like a huge progress when it actually can't or shouldn't be used as a foundation for anything.
I'm inclined to think a PoC (or whatever you want to call it) would be useful for some things:
- a tangible and cheap way of showing the customer how you think you can solve their problem
- getting concrete feedback on that solution (you're both talking about the in same, tangible thing)
- using it as a foundation for the "big" project. Not its code, but the ideas behind its UX, flow, treatment of data, whatever is the main crux of the solution can be made tangible in a PoC and be used as a reference for the next step, ie making a production-worthy application
- the PoC can also show that what the customer wants is in fact a bad idea.
I agree about the pitfalls of not seeing something usable until it's very late and how to measure progress. The opposite is also true however, you make some easy non-scalable PoC and it looks like a huge progress when it actually can't or shouldn't be used as a foundation for anything.