You will want to make a release map - a list of things that you do to plan, build, and release a change. This can have contain a lot of details about steps for review, testing, and deployment. Or, it can be very simple, and high level, like the diagram below. You will look for steps that you can shorten or remove.
Often, you will find that you have "waterfall" stages that are delaying each release. In the diagram below, we see that the "Program" stage is not very long. The programmers may even be using continuous integration and continuous delivery, so they can show changes quickly. However, the other stages of this process take longer.
After you have the release map, you can use four basic tactics to remove the waterfall stages. Think of it as SLAB - Skip, Lag, Automate, Blend.
Sometimes you get lucky and you can just skip a step. In the diagram below, we skip "Plan", and instead we let contributors pull tasks when they are ready.
We can Unblock! the release by lagging some tasks so that they come after one or more releases. Marketing and "launch" should always be lagged. Localization is often lagged. In the diagram below, we lag documentation and do it afterward, on a different schedule.
Automate as much as possible. You want to be able to finish a task as fast as you can run a script. In the diagram below, we apply automation to both testing and deployment.
You can blend one task with previous stages, so that it disappears as a waterfall stage and does not block anything. You can do manual testing while you are doing design and development, so that the QA person acts as a consultant, and not a gate.
After applying all of these tactics, we might end up with a top-level release map that looks like this: