In classical companies deployments are very strong coupled with Development Cycles and they again with the availability of new features. But this coupling is only feasible when the company is small or best case one person is responsible for all of this three things. But in companies where the responsibilities are scattered across departments (Product Management, IT-Operations and IT-Development) you should de-couple the outcomes of this departments to be more flexible.
What happens if all three things are coupled? The obvious thing is that planed deployments happens only when a development cycle ends. And because development cycles are also coupled to new features we get deployments only when new features are available. In a world where nothing unexpected happens and where no bugs are possible this process fits perfect. If you find one let me know!
If you decouple deployments from development cycles you can decrease the live time of bugs. Why? Because you have not to wait until one of the development cycles are done (or starting one of the complicated hot-fix release processes). The only thing you are waiting for is a version with the bug fix or maybe the bug is unrelated to development at all, like heartbleed then you can deploy just the infrastructure code. With this in mind your goal should be to be able doing multiple deployments per day.
When you go one step further and also remove the coupling between new features and development cycles you can roll out the code of the new features when ever it’s done but someone else can schedule when to activate the feature. This means you can roll out even smaller batches, you’re reducing the lead time of features again and it’s still complaint to all agile processes (even scrum) and I would say even ITIL. Bussword for this idea is “feature toggle”.