1

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.)
Improve this question
2
  • 1
    I edited your question to be less subjective and opinion-based. The criteria you mentioned, backing up an answer with references, is already a criteria of a good answer so that is superfluous and might be considered a resource request. Commented Oct 6, 2015 at 2:00
  • I think it should be driven more by the needs of the customers than the needs of your development team. Depending on the application, they may be happy with constant tweaks and additions of new features, or more managed infrequent releases may be necessary. It also depends on the size and nature of the feature changes. Commented Oct 6, 2015 at 7:06

1 Answer 1

Reset to default
2

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.

Improve this answer
1
  • I appreciate the particular point that "complete but undeployed work has no or negative value." I was thinking of it as no value, but I can see it could have negative value for several reasons: it is potentially piling up essentially technical debt of deployment tasks to be paid later, it carries the risk of having pending changes that may not be well understood (and/or bundling of more risk into a subsequent release), and it complicates communication of what's live with internal customers like product management and support. Commented Oct 15, 2015 at 22:03

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.