It depends. Much like most "scrum" teams don't really do by-the-book Scrum, it was very rare to do by-the-book waterfall. If you defined waterfall to mean -

It depends. Much like most "scrum" teams don't really do by-the-book Scrum, it was very rare to do by-the-book waterfall. If you defined waterfall to mean - get every requirement written up in absolute detail before you do any design - finish the design in great details before you write any code - if the design process identifies problems with the requirements (missing/ambiguous/etc), then stop the design work and go back to requirements phase - write all the code before you start testing. - if during development you find an issue with the design, stop development and go back to design etc Then I never saw any project that worked that way. But it was quite common to have a requirements gathering exercise, write up a document that covered the requirements, get that "signed off", then do a multi-stage design phase (usually we'd start that before requirements were signed off, since the probability of the requirements being rejected in their entirety was pretty low), sign that off, and then move into development to implement that design. And then test the whole thing at the end once it was "done". If at any stage we found missing requirements, that would get raised as a scope change. If, during development, we found that the design was broken in some way, we'd have a design change (which was usually lightweight and was a couple of emails saying "we can't do X, so we're doing Y, OK?")