You can, however, strip it down even further and still be effective. Scrum encourages bundling stories into sets and delivering them all at once. I've been moving away from that, and continuously delivering discrete stories/features/changes/fixes/whatever as they are ready.
Decoupling incrementalism from iterations has been a huge change for me.
Different continuous delivery teams do it differently. I don't like having a dedicated QA team/department. QA is an effort, not a role.
The key part of continuous delivery is that the safest change to make to a stable system is the smallest change possible.
So instead of batching up lots and lots of stuff and throwing it over the wall to QA, you make one change, have humans and robots test it, and deploy that change. The mindset shifts from "features per release" to "releases per feature" so with truly friction-less automated deployments, you can release very small changes individually. You don't have to test everything in order to change anything.
As you may expect, multiple layers of test automation are necessary. Each change runs a gauntlet of different kinds of tests before release. A set of "safe to run in production" tests immediately after release. Rollbacks are trivial, but exceedingly rare.
Obviously, this only works in some contexts. If you're pressing things onto gold master DVDs and shipping them in boxes, the QA effort will be more traditional.
Your automatic (unit, functional, system) tests assure stuff doesn't break (too much), and manual QA happens after deploying. If something is broken, you can fix it very fast, since you are deploying continuously.
Stuff might sometimes be broken on production, but you could argue this makes people think twice before pushing to master.
Also, you can deploy to production with a delay (e.g. 1h) and deploy to a QA server first to give the QA people some time to check before stuff goes to production.
Decoupling incrementalism from iterations has been a huge change for me.