Release Planning and Agile don’t have a relationship.
When I say Release Planning I hear a lot of “hey, we’re doing Agile, Release Planning is obsolete”. Well, no.
Agile is about being fast to the customer, with exactly what your customer needs. How you do this is by having Agile Leadership and implementing Agile frameworks, ways of working, artifacts, events, roles etc.
When a Stakeholder ask the question “Hey, when do you think it’s gonna be ready?” you cannot answer with “don’t know man, it’s gonna be ready when it’s gonna be ready…“. That’s hippie Agile, as a trainer of mine said to me in the past. That’s not building trust, you’re not sending the message that “I can count on this guy”.
You need to be predictable with your product. Predictability is an outcome of discipline! And Agile way of working is a disciplined way of working, contrary to what people believe. If you are disciplined in your process of developing a product, you will have a DEEP backlog of activities, you will have a stable velocity, you will have an accurate Roadmap for the near future and you will have a plan to deliver your functionalities to your customers, a.k.a Release Plan.
How it was done in Waterfall was short and easy: 2 Major Releases per year, with this scope committed in them, anything else that is urgent we call it Hot Fixes and don’t plan it. And then pray that nothing changes and we can follow this plan.
How we do it in Agile is deliver in short iterations so we can get feedback and improve/fix based on this and by following a plan that responds to the changing environment. We call these Sprint increments and that’s one type of Release that we have in Agile. Every Sprint we release some value to our customers.
The Sprint Releases are really important, that is what helps in creating a discipline of continuous delivery of value to the customers.
Every 3-5 Sprints you might feel the need of creating a bigger picture, a bigger context for your product. And you will integrate all of your increments from the last sprints and deliver a solution. You can choose in this case from multiple Release strategies, like canary release or toggle-feature. I call these Integrated Release and this can be planned every 3-5 Sprints.
This happens a couple of times per year. But now, unlike in Waterfall, is just the moment when you acknowledge all the Sprint Releases and the Integrated Releases from the last months, you remove all the toggles, you deliver to all of you customers, you promote the functionalities and you celebrate the major breakthrough you had. Everything is already in production, bug free, all the feedback integrated and all the NonFunctional Requirements satisfied. You did not build on stock and now make a big bang with all the stuff. This should be a formal moment when past strings are cut and the future just arrived.
Release Planning means that you, as an Owner of a Product, have a plan in regards to delivering your product to your client. Because fail to plan is plan to fail. You can call it Release Planning, or you can call it whatever you like, but you need to have such a plan based on your Roadmap and, Sprint Release, Integrated Release and Major Release are one way of viewing this.