Decoupling Releases from Sprints
Many software development companies want to move to a Continuous Integration/Continuous Delivery (CI/CD) model, but still have long release cycles. There are several reasons this happens. One example is that the company is holding a release until features are complete and is not using a feature flag system. I’ve also seen that they are holding onto the idea that they can only release at the end of a sprint. While I get the concept from a project management perspective, after all, it does make release tracking easier, it doesn’t have to be that way.
I worked at a place that released every couple of months and had many problems with it. Constant rollbacks, incidents, and bugs were introduced each time. This was a problem, and the solution was to get control of the code. They had to cherry-pick the code before release, which meant their release wasn’t tested properly. It needed to be tested in an integrated and isolated environment, but when you cherry-pick, you introduce potential problems every time.
Once we got the code testing under control, though, we were able to use proper CI/CD. This is where we ran into a new problem. Project management didn’t want to release until each sprint was completed. We ran on two-week sprints, which is standard. At the end of the sprint, they tried to release the code and put together their report on what was released.
The benefit of CI/CD is that you can release smaller chunks of code with a limited impact on an application. The larger the release is, the greater the potential for impact.
So, how did we solve the problem? We built a release candidate as soon as the code cleared testing. It would go to a staging environment where it could be verified by users and project managers. If it was cleared, it just went out the next day. We made sure to build a comprehensive patch note system that automatically updated at each release, and then the project managers were able to take that and add it to their report.
What was the benefit? It was less work for the project managers to wrangle what stories were ready to release. They already had the patch notes ready. It also lowered the bug and incident rates. The Development Operations (DevOps) and Support teams were able to respond better to any issues. If a rollback was needed, it was quick and painless. We were also able to build in Hotfixes quicker, though the need for that fell dramatically when we introduced a faster release cadence.
The key here was that the project management report didn’t have to lead the release schedule; it merely adapted to it and pulled information directly from it.
The company I referred to was releasing every couple of months, adding a lot of scope to their teams to fix issues they kept introducing. After we adjusted the CI/CD process, most of their releases needed limited support and were released twice a week. We could even release on demand as needed (for hotfixes and the like).
This improved everyone’s lives and enhanced the organization’s reputation with its clients. All it took was adjustments to how things work and how project managers think about their processes.
