Release Management in a Scaled up Agile Program!
If you are truly agile this should really not be a problem, there I said it.
Release should be a non-event, but traditionally in enterprises release is a huge event, and makes important feeling people who understand very little about what actually is getting released get in a room to make decisions on when and what should be released. This happens due to two underlying issues which are very much correlated.
- Releases are not very often and
- Releases are Huge
Since releases are not very often everyone wants to get their stuff released as they dont know how many weeks/months it will take till the next one comes along which makes them huge. And since they are huge, it takes a long time to get everything ready for a release and very very hard to predict just when is everything going to be ready.
Imagine you need to take a bus every morning for work (there is only one to go to any destination), but there is no knowing when the bus is going to arrive. Sometimes there is one every 5 minutes, sometimes it takes half an hour; and then there are days where it just doesn’t show up. What will you do if you see the bus coming but its overcrowded, with people almost hanging out of it? You will most definitely try your best to get on it because you dont know when is the next one coming and everyone standing at every stop going anywhere along the line will do the same thing.
Now since the bus is overcrowded with people hanging off it, it will move slowly and cautiously so as to not drop anyone, and will stop at every bloody stop to pick up or drop off people so it will take a lot longer to get where you want to go.
But what if you knew that there will be a bus coming every 2 minutes, and there is a different one for each direction. You wont be pressed to get on the bus in front of you, you will be okay waiting for the next one to come along as well and since this bus needs to make much lesser number of stops, even though you waiting a few minutes you will get to your destination quicker.
The only way to achieve this with releases is by Empowering your teams, push them to break features into smaller chunks and release every possible story that gets done (even if its toggled off) out there.
The only way to achieve this is, if you have
- Empowered independent feature teams that own whatever they are building end to end and ensuring that it plays well with other systems in the pipeline
- Robust CI/CD practice across all teams that dramatically reduces the overheads and gives your team that confidence to take stuff live, because most of the heavy lifting for testing would be taken care of by automation
I have been on projects/programs where we were releasing more than 2–3 times a day across the teams and there was no release management function. Teams and product owners used to get together and figure it out, and great automation and robust CI/CD practice ensured we never broke anything by releasing stuff.
All the more, since the releases were small we could predict with great precision exactly when we can push features/stories live, which gave immense confidence to business to get on with planning around it rather than wondering when its going to go live!
