Lean or agile SaaS: deployment / release features during or after sprint

Question

For SaaS (software as a service), when using a lean or agile development process with short sprints/iterations (e.g. 1 to 3 weeks), which approach produces better quality: deploying/releasing features...

1. during the sprint in which they are developed, or
2. after the sprint (possibly much later if limited alpha/beta release or feature flags are used)?

I call out "features" specifically because with SaaS, we may need to release hot fixes at any moment, 24/7.

What criteria may help determine which choice is better?

Some strawman advantages for deployment (1) during the sprint:

• Gets the entire development team more focused on ushering features all the way through to deployment
• Slightly earlier and possibly more predictable schedule for delivery to downstream consumers (customers, product management)
• If you have a "demo day", you can demo deployed features

...and for (2) after:

• If the release process requires fewer resources than development and testing, then pipelining in this way can lead to higher throughput because development and testing can continue until later in the sprint
• Precise deployment timing can possibly be more flexibly controlled, e.g. for limited alpha/beta releases (but maybe we just say it's "deployed" when it's in alpha/beta), feature flags (ditto last comment), marketing communications
• If release engineering resources are insufficient (e.g. due to illness), release does not have to wait another full sprint but can instead occur as soon as resources are available (of course, the during alternative does not absolutely preclude this)
• Meh, why not? You should be able to release SaaS anytime anyway, right? (A bit tongue-in-cheek there.)

Answer 1

I'd propose releasing immediately on sprint completion, or as soon after as is possible. For these reasons

1. During the sprint puts a requirement on the team to have a potentially shippable increment available at all times during the sprint *See note below on this
2. Too far after the sprint is complete opens you up to issues being reported with work which has been long forgotten by the team. The shorter the gap between someone completing some work and issues being logged with it the fast it will be to fix.
3. Deploying soon after the sprint is completed and then fixing any issues gives you more confidence that all previous work is actually done and isn't going to come back and bite your schedule in the arse.

*Note: If you have your source control processes set up in such a way that continuous delivery is possible then by all means adopt a release train approach where releases go out on some schedule and deploy all recent changes. I'd still suggest deploying as frequently as possible to get work out there and in the hands of customers asap.

I think the general principle here is that complete but undeployed work has no or negative value. It has cost you effort to create but until it is in your customers hands you are not realising the value it can create. So, you should always strive to get work out to customers as soon as possible.