I don't think it's any issue of individual raw productivity. It's about not wasting that work by focussing on building exactly what the customer wants as fast as possible.
With pure waterfall you spend a lot of time writing and reviewing specs, then you spend a lot of time coding, then tests, then deliver. This means a longer lead time to working software and to any sort of feedback, and usually a waste of time in the docs/specs phase. Even trying to write a whole perfect spec before doing any coding prevents you from benefiting from the practical feedback that comes from actually doing.
For some types of software this works mostly fine, but others not so much. Hence why most methodologies since then have feedback loops and try to make then small.
IMHO sprints are not to pressure (though the name may not be well chosen in that respect) but to enforce small-ish iterations rather than spending 6 months developing something in isolation.
> With pure waterfall you spend a lot of time writing and reviewing specs, then you spend a lot of time coding, then tests, then deliver.
(see my reply above, for some context and why I might be wrong :-).
My recollection of Waterfall is that there is always an "acceptance" phase at the end of every "fall"[1] - IOW, there is a sign-off by the stakeholders that what's in the phase is correct.
So your requirements are engraved in stone, your test protocol is engraved in stone, and your UAT is engraved in stone, and your "pilot performance acceptance" is engraved in stone.
If it turns out there is an error in any one of the phases above then that error, and that error alone, is signed off on and goes through all the phases (or "falls"?) again. Since this is more expensive the further in the falls the error is, there is pressure to get as much sign-off as possible for any issue before that issue proceeds to the next phase.
[1] I like the word "fall" to describe each phase of waterfall :-) I'm going to start using it more often and see if it catches on.
With pure waterfall you spend a lot of time writing and reviewing specs, then you spend a lot of time coding, then tests, then deliver. This means a longer lead time to working software and to any sort of feedback, and usually a waste of time in the docs/specs phase. Even trying to write a whole perfect spec before doing any coding prevents you from benefiting from the practical feedback that comes from actually doing.
For some types of software this works mostly fine, but others not so much. Hence why most methodologies since then have feedback loops and try to make then small.
IMHO sprints are not to pressure (though the name may not be well chosen in that respect) but to enforce small-ish iterations rather than spending 6 months developing something in isolation.