Choosing the Right Release Cadence for Your Project

On software projects, choosing a release schedule that works for both your team and your client is essential to long-term project health. Release too often, and you risk coming off as frantic and harried to your customers, your clients, or both. Release too seldom, and you risk appearing stodgy, inflexible, and unresponsive.

There are several different approaches, each with pros and cons. Here’s an overview that might help kickstart the discussion when you start your next project.

Option 1: Release When the Product is Done

This one scares me. The idea of waiting until a product is completely and entirely finished before releasing it to an end user seems like an untenable goal.

Releasing software is an incredibly complex business. Even a phenomenal team is going to find out things they didn’t anticipate about their software once it’s out in the wild. Even so, there are some products and environments that merit this sort of release style:

  • Custom hardware
  • Embedded software that’s difficult to update
  • Consumer software in a fad-driven category
  • Rocket firmware

When the difficulty of changing your code or design after the fact is high, it’s worth at least considering an approach in which you only release to customers once the entire project is ready to go. Architects often deal with this kind of a tradeoff. In his memoir of the famous architect Frank Lloyd Wright, Edgar Tafel quotes Wright as often repeating that “the architect’s most effective tools are the eraser in the drafting room and the wrecking bar on the job.”

If your project is easy to change before release and tremendously difficult to change after release, consider using an eraser rather than the wrecking bar and waiting to release until it’s really finished.

Option 2: Release (Only) at the End of a Sprint

Sprint boundaries present a natural opportunity for releasing new versions of a custom software project. If your goal is a stable, predictable release schedule, this is a great way to go. Facebook’s mobile apps are a good example of this style of release. Every two weeks, without fail, there’s a new version of Facebook for iOS.

Releasing on sprint boundaries is especially useful when you have an expensive release process. If releasing a new version of your app requires extensive manual testing, a lengthy client approval process, or synchronized marketing releases, then having an agreed-upon release cadence can make life easier for everyone on the team.

It’s also worth considering your client’s internal progress reporting structure. If your contact reports progress only once every two weeks, releasing more frequently than every sprint might not actually provide meaningful value to the organization as a whole.

On the flip side, releasing only once per sprint has its risks. If there isn’t universal agreement on the purpose for a given release cadence, it can feel inflexible and unresponsive as issues arise. Bugs can linger in production after they’ve been dealt with in development, which isn’t awesome for users and can eat away at team morale. Steady releases can also make the team seem slower than it actually is, especially if it’s working on features that happen to straddle a sprint boundary.

Option 3: Release Early, Release Often

Releasing features and bug fixes to production as soon as they’re ready is another popular strategy. If your goal is to test a lot of ideas in a short period of time, or if you need to be super-responsive to customer feedback, this may be a good option. GitHub’s “release early, release often” strategy is an excellent model of the pros and cons of this approach.

Releasing features and bug fixes as soon as they’re finished minimizes manual testing surface area. It’s much easier to do a targeted test of an app when the amount of changes is small. Releasing earlier can also help validate guesses and challenge assumptions. Unsure whether customers prefer auto-save or the confirmation confidence induced by a save button? Release both and see what happens.

Frequent releases tend to boost team morale. On longer-running projects especially, this can be an important factor to consider.

Like all release strategies, rapid-release also has its downsides. Releasing as soon as a feature or bug fix is ready can come off as frantic to clients that aren’t used to dealing with a rolling release schedule. This can be largely mitigated by good communication, but it’s something to keep in mind.

If you have an expensive release process, this strategy will make it painfully obvious. If releasing a new version of your app involves a lot of manual work, you’ll incur that overhead multiple times a sprint instead of just once, at the end.

Rapid releases also contribute to network load. This factor tends to be more important where network connectivity is either expensive or spotty. If your project serves people in either of those situations, releasing a multi-megabyte website update or an even larger app update can be a real burden on your user base.

Fitting the Strategy to the Situation

Every release strategy has plusses and minuses, and none of them are universally applicable. Whenever we start a new project, we carefully consider the release strategy that works best for each client given their marketing goals, risk tolerance, management structure, and a host of other factors. How do you manage software releases? Let me know in the comments.