What is a software release?
For most people a software release is when various changes hit the production servers. At that point the release is done and it is over.
In reality though a release isn’t over at that point but is only beginning. Once the code hits the server, marketing can begin planning and conducting their campaigns, customer success can contact interested parties and sales can plan and conduct their campaigns. All that can and should happen *after* the code hits the servers not in the lead up.
Even with the best QA processes in place, it is better to let changes “live” in the wild for a bit before you go and shout about them. Bugs will be found, stuff that is missed will be identified and leaving time to allow the changes to bed in makes sense. You don’t want to conduct a marketing campaign driving leads to buggy features.
What this means is that sales, marketing and customer success don’t necessarily need to know what or when changes are pushed to production. Their work begins once the changes are on the servers. This gives those teams much greater flexibility to manage their parts of releasing to have the most impact for the business.
What about training? What about documentation?
It is quite right that these are arranged before the code hits the servers. But let’s turn that around. Is training and documentation really related to a software release? No, training and documentation should be considered as part of the development process and a change is not ready for release until the documentation and any training are ready and done.
Using this approach releasing works this way:
1. Changes are made, documentation updated and training made ready
2. The “ready for release” change goes into a “ready to release” hopper
3. The release lead then pulls items from the ready to release hopper to form the “release”
4. The changes are made live
5. Customer success notify interested parties of the changes
6. Marketing team begins planning their campaigns
7. Sales team begins planning their campaigns
And what about product? Well that team will start tracking what impact the changes have on the product.
So a software release isn’t about knowing upfront what will go out when but knowing what did go out and when so the other teams are able to coordinate their work.
Releasing isn’t about throwing code over the wall but coordinating ongoing work across multiple teams.
Releasing isn’t about dates but impact.