Many well-meaning people think they can be the First Person Ever to combine waterfall and Scrum, name their new process with some catchy name, start teaching this Frankenstein system, then cause internal organizational chaos or sloth.
It comes from a serious misunderstanding of what agile/Scrum methods are. Agile methods are a form of production science, where you measure end-user value production in short, fixed iterations, then use your measurements to diagnose problems, adjust your production methods and forecast. Waterfall’s long production cycles make it impossible to do this feasibly.
You may think that Frankenprocess (waterfall + Scrum) can first measure design, then measure development, then measure testing, then measure deployment. The problem is that these measurements don’t help highlight hidden dangers fast enough to avoid disaster. You certainly can’t forecast delivery time with Frankenprocess measurements. You won’t have tried or measured any of the very-different later stages of your project before formulating your early forecasts. You’ve just guessed. That’s what waterfall is: a bunch of unproven guesses with no early verification/correction. You bet the project outcome on your guessing ability.
You may think you can do mini-waterfall, like a series of 4 two-week Scrum sprints where the last sprint is, say, testing and deployment. If you do that, you basically have created an 8-week Sprint. The velocities of the first 3 sprints are meaningless. You have no certainty that the 4th Sprint will actually be shippable, so you can’t rely on any of the velocities in the first three Sprints to forecast or diagnose. Finally, you dictate different processes in different Sprints and therefore lose the flow and rhythm of highly-effective teamwork where the whole team tries to get something shippable together.
If you do mini-waterfall and only measure the velocity of the last mini-waterfall cycle, I think mini-waterfall is sort-of OK. But then, you really ought to be honest with everyone, say “We have an 8-week Sprint.” This honesty allows us to do what agilists worldwide do: We try to reduce the cycle time, so we can identify and eliminate problems faster, and so we can more rapidly adapt to market and environment changes.
I hope this helps.