I want to add one more thought to my previous post on how to achieve weekly (or faster) releases. It’s about the difference between timed releases and scoped releases.
You can read my previous post, but to summarize: a client of mine went from irregular releases that had a specific scope to weekly releases without a predefined scope. Whichever feature or change is done makes it into the release. If something isn’t finished, it’s not a big deal because there is a new release next week.
A scoped release is simply where an organization selects a list of features that should be released together. There might be a rough estimate of when the release will be finished, but the important thing is that the scope of the release is defined.
If the features aren’t finished by the estimated date, the release can be postponed until everything if finished, tested and approved.
Timed releases happen when the organization determines when the next release should happen, regardless of what features are finished. The organization releases the completed features and postpones unfinished features to a next release.
You could of course combine scoped and timed releases. This happens when the organization defines both a date when to release the new version and the list of features that should make it into said release.
This is a tricky choice, because the chances of not finishing on time are high. Estimating the date of completion in software is extremely difficult and it gets more difficult the further in the future you try to estimate.
So if you ask the team when they’ll finish a list of features and then set a deadline, you’re bound to miss the deadline or exhaust your team. Especially because we tend to underestimate the time it will take to finish features.
Many organizations have chosen the combined option. But in my experience, you can’t have both.
So you’ll have to choose between timed or scoped releases.
Timed releases have the advantage of being predictable: everyone knows when a new version will be deployed. But a team might choose to spread out the releases too far, leading to so-called big bang releases which increase the chances of disaster.
The advantage of scoped releases is that you release a feature the moment it is done and you get feedback very fast. A disadvantage could be that the organization isn’t ready for the product changing at such a rapid pace.
If you’re working on a project with technical debt and a long history, I recommend choosing timed releases. Try to release at least once a month and then try to evolve to weekly releases later.
You’ll have to take a good look at your release process and automate it thoroughly: testing, database changes, deployment, monitoring, etc. This might be some work, but you’ll save in time, effort and reduced human errors.
This will also stop you from creating a large list of features that must make it in the release. These big bang releases increase the risk of bugs and these bugs are often more difficult to track down. Timed releases force you to improve the product in small increments.