Agreed, I've been on many projects where a client only had vague requirements and useful clarification only came in response to seeing the app.
This is reasonable, it's human, but does anyone have a good approach to applying an iterative development approach on fixed price contracts?
I've been on many fixed price projects that are "agile" in name only, general issues I've observed:
- Iteration on requirements becomes confrontational (pay for change request) making it difficult to build a good product as we all learn what does/doesn't work for users throughout development.
- Upfront estimate is inaccurate causing time pressure on development resulting in rushed work which negatively impacts code quality and team learning.
The traditional answer is to have the client commit to specific requirements and hold them to it.
But what I'd really like to figure out is a way to acknowledge evolution of requirements will happen so we can work _with_ clients to build great products.
I struggle because this seems incompatible with fixed price and large companies seem to only want to do fixed price.