We earn commission when you buy through affiliate links.
This does not influence our reviews or recommendations.Learn more.
When it comes to scrum delivery, people usually expect a release execution after the end of a sprint.
This means directly after a successful demo presentation to the client.
But I always wondered how this could be such an automatic expectation.
Especially if you consider the below possible activities that must happen before or alongside.
Now imagine the sprint has two weeks.
Release activities by themselves take time and people to complete.
But it cant take too much.
Does the expectation of release after each sprint still look so automatic?
The problem is that I have never experienced such a perfect state of the scrum team.
If it is actually the case in some small-scale private businesses, I really envy them.
But the reality in the corporate world is that a scrum team wont achieve that level of maturity.
The release is just a stressful act nobody on the team is happy to go through.
So I was after discovering the next best scenario for dealing with releases.
The conclusion was tomake every second sprint the Release Sprint.
Here is what it means.
Separate Code Version For The Next Release
This is about handling separate branches in the GIT repository.
There are many ways to approach the same problem, and all of them can be successful.
Lets call it Release Branch.
It was super clear this would have no chance of working.
But over time, this will become irrelevant.
They will get two sprints of content with each next release anyway, after each second sprint.
Since it is deployed from a standalone branch, this can be basically an unnoticed and invisible activity.
Nobody needs to know.
If that is the case, it is the best possible implementation of the release deployment.
A prerequisite for that is to have created a solid automated DevOps pipeline.
Not only used to deploy to the production environment but also to all the other lower-level environments.
This might include dev, sandbox, test, quality assurance, performance environment, etc.
This shall be a one-click to deploy all solutions for every single environment.
The release should not be a pain point or stress.
Or a nightmare everybody fears and keeps preparing for that day for one week.
It is related to all the fixes that were implemented during the testing period.
At that point, the latest Release Branch serves as an emergency ready-to-redeploy production code.
If an urgent high-priority issue needs to be resolved shortly after production deployment, it can use this branch.
It is simple to take this code and implement the fix inside.
This is still the exact copy of the current production code without any new unreleased content.
The new one is again created as a copy from the current development branch.
Establish Regular Releases
And now we have it a solid process for approaching the release.
The only thing missing is making a commitment to keep it regular.
In this case, after every second sprint.
Also, it is about what proved to be working in real life.
Often, teams start the agile way and do many things wrongly.
Then they evolve, eventually, and start to do things differently.
This series could help some of them to do this change faster.
Neither is this release approach the only one workable, nor is it without problems.
Those will still exist, and the teams have to deal with them.
Then improve what is possible and forget what has no sense.
But from what I know, this approach, although a simple one, proved that change is possible.
