As I work with Scrum Team's, I find a common thread in teams that believe our releases are "tied" to the Sprint time-box. This is not the case. Releases are independent of the Sprint time-box. If you have something that meets the team's definition of done, the Product Owner has reviewed/accepted the functionality, and the team has the engineering skills to release frequently, RELEASE!
Origins
When Scrum first was being developed in the late 1980's and early 1990's, the most common length of the time-box was 30 days (1 month). It was typical then to release at the end of the Sprint. My theory on this is that the development tools we had back then might have precluded a team's ability to fully release frequently throughout the Sprint. The idea was that the team would work together in a cross-functional style to deliver the intended Sprint Goal and upon completion of the Sprint, they would release.
Modern Times
I also believe that agile / empirical processes gained footing in the early 1990's because IDE/Development Tools fostered a more rapid delivery process. No longer were we taking punch cards in the hundreds to a shared CPU to schedule our job, run it, find out it failed, and do it all over again. Tools have drastically changed even from 2004 when I first began developing. Today, I find more and more teams rapidly develop features in a sprint; 1-3 days into the Sprint that meet definition of done in the target environment (which might not always be Production). As long as the Product Owner reviews the feature and accepts it as meeting the need, my opinion is that can be released any time during the Sprint. It has to touch all the "bases" but we don't have to necessarily wait until the Sprint Review.
Do We Still Have the Review?
I still firmly believe in the final Sprint Review at the end of the Sprint to keep the cadence and allow Stakeholders/Customers/Product Owner/Team to collaborate on what we might work on next based on the feedback from the increment delivered. After-all, the outcome of a Sprint Review can be a completely revised Product Backlog. Even if the Product Owner has signed-off and released the features, I feel it is still a good practice to review the Sprint (remember the Sprint Review is more than just a Demo). It might go a lot quicker if the customers have already been using the features in Production. You can even ask if anyone wants to see the demo of the feature (if everyone has already seen it, then just gather feedback and input).
One day, Scrum might be revised to have the Sprint Review go the way of Product Backlog Refinement. It's an activity that needs to happen, but the Scrum Team determines the best times to have it. Let's not forget the stakeholders through the process though, so it's more than just about our team agreeing that we have built a done increment. It's about feedback and collaborating with the stakeholders as well.
