How long are you willing to wait before you find out your late? (Or over budget, or your the thing you're building doesn't work as specified?)
That's the question that must be answered by any development life cycle in any project domain, in any product context. Doesn't matter if you're planning a mission to Mars or planning a summer picnic, if you don't have some measure of physical percent complete against the planned physical percent complete, you're late before you start, and probably over budget as well.
The reason serial lifecycles are useful for executives is they bound the exposure. The critical success factor for serial lifecycles is to set the time boundaries appropriate to the work rhythms. To make blanket statements about the appropriateness of one lifecycle over another in the absence of the business, technical, and financial rhythms is to basically say -
"I don't really know what your problem is, but I have a solution for you"
So ask and answer the "waiting" question first, then choose a project lifecycle that "fits" the needs to know that answer.
There are other attributes of lifecycle that cannot be generalized as well:
- Risk reduction
- Product production cost
- Resource utilization and absorption
- Cost of Goods
- Supplier capacity to deliver
