One of the benefits of a waterfall development model over these agile strategies is that code review becomes a whole-team, front-and-center piece of the process

One of the benefits of a waterfall development model over these agile strategies is that code review becomes a whole-team, front-and-center piece of the process, not a distraction from other tasks. With each revision of our product spec, we work first to write or modify code to meet the new spec and then, once everybody has tested and merged all their changes, we pause new development to review and verify the code. We tend to end up each working on different modules, so we can maintain complete independence in review by each reviewing others' modules with minimal attention to who authored each individual diff. We just keep a spreadsheet tracking all the different files, their authors, and whether they've changed since the last review; at the start of a new review, we assign a reviewer to each file and then the author and reviewer work the file through review-resolve rounds until there are no further findings. Since everybody is fully focused on the review, it goes by quickly; since there's no expectation of review during development, we can develop quickly without holdups.