Release Frequency

Release Frequency is how often working software reaches real users. Releasing more often is, in the long term, the cheaper and safer bet.

How often should you release? For a long time the answer was: only when we had a large batch of features to sell. In the 1990s, when our software was shipped on floppy disks or CD-ROMs, this made some sense.

In the traditional approach to software development, we did what we called big bang releases, where we waited until the end of the quarter or the end of the year to release our software. We would spend months working on features, doing light testing along the way, then cram much of the real testing and other efforts into the last few weeks. This led to a lot of stress and overtime. In addition, products always went out the door with a lot of bugs. The question was not how many bugs, but how severe they were.

Every release is a batch of changes. The bigger the batch, the worse each of these problems gets.

Problems With Big Bang Releases

• Testing cost grows faster than the scope of the release, because we need to test not just the new features, but also their interactions.
• The more changes there are, the harder it is to find where the defects are so we can fix them.
• The longer it has been since we last worked on a piece of code, the harder it is to understand, and therefore fix, a defect.
• Less feedback from the customer on the features we build. No matter how much User Acceptance Testing we do, it’s not until the customer starts using the product in anger that they tell us what is hard to use and what is missing.
• The customer only ever sees big batches, so they don’t trust you to build a small version of a feature and make it better later. If they don’t demand everything and the kitchen sink in the first release, they don’t believe they will ever get it.
• Some of the features we build will be obsolete by the time we release. The world around us is changing at an ever faster rate, and the longer the release cycle, the more likely it is to contain features that are no longer relevant.

But Users Don’t Want Constant Changes?

The most common objection is that users don’t want to deal with frequent changes. This misses a few key points:

• Not all changes need to be available all the time. Limited use of Feature Flags can delay access to a feature until the audience is ready.
• When we release frequently, most of the changes are small, so they’re easier to absorb. Many are based on feedback from users, and so are welcomed.
• Most people are already used to frequent changes. We use smartphones and don’t notice most of the updates to the apps we use daily.

Release More Often, Not Less

Here’s a rule of thumb the agile community has spent years learning: if something hurts or is hard to do, do it more often. If it’s hard to release, then release more often.

With a Scrum Team that has a good Definition of Done, I would expect to increase the frequency of releases. If needed, go step by step: quarterly, to monthly, to every two weeks, and eventually just move to DevOps.