It’s that time of year where we look back, learn, and make changes in the new year. One important area we decided to take a deeper look into is the community release cadence. Currently, we release monthly and upgrade your community every other release. We asked ourselves, is this right for our product line to maximize quality and value delivery? In this article, I will be going through our thought processes, explaining the outcomes and orienting you on what you need to know.
What is changing?
Khoros Communities is moving away from a monthly release cadence paired with an every other release upgrade model. We are moving to an every 6-week release with an 100% upgrade target for all customers. This means that every customer will be targeted to get every 6-week release. We believe this will improve quality, value in each release, and the pace of innovation. We will be running this new release and upgrade cadence for a minimum of 2 quarters starting in Q1 2020. We remain committed to continuous improvement and I will be reporting back out to stakeholders on the success and impact of this change and we will reevaluate continuing at that point. For now, we are going to keep the same release naming scheme of year.month (example: 20.1) with a note that this may change in the future.
Looking at the monthly release model
We started this release cadence many years ago to standardize releases and upgrade cadences. This means that we fit all development and regression for each release into every month. Often starting on the 1st and concluding after 4 weeks, upgrades begin the second it is approved. Once released, upgrade notices begin to go out and the first stage upgrades begin. Following customer acceptance production upgrades commence. Due to the complexity in maintaining upgrades, automation tooling, and quality checks we can only upgrade about 50% of our install base on this cadence per monthly release. In aggregate, this means that every customer is actually upgraded to every other community release.
This release cadence has upsides and downsides. The main benefit to this cadence is the frequency in which we can ship value to our customers. On average every customer is no more than 2-4 weeks away from a release and the value of that next bug fix or feature. (It should be noted that we also have an emergency patching process to get urgent code out the door quickly when needed but that is another article). The main downside is that in practice a customer is actually 4-8 weeks away from the next release due to the every other upgrade cycle. Secondarily, the costs to our releasing and upgrades is fairly labor-intensive that takes away from feature development or other value creation activities.
Swinging the pendulum to quarterly releases
One idea to maximally optimize the costs of release is to move to a quarterly release, 4 releases per year. This certainly gives more time back to the development and quality teams to create and test features before release to the tune of weeks per quarter. This “extra” time can now be spent on creating more automation for speeding up future releases or for more time in feature development.
The problems with this cadence are customer demand and the impact of missing a missed release. Our customers are looking for more innovation, faster and this perhaps balances too far away from that demand. Additionally, if a team misses a release deadline the impact is quite high as the next opportunity is minimally 3 months out. This puts too high a penalty for minor overruns in development. In turn, this puts more pressure on a patch process to get this value to customers. We draw a hard line at the practice of patching features into production. The patch process should be reserved for emergencies such as outage causing or security issues.
Just right, 6-weeks
After review, what we needed is a cadence that balanced the costs of release with the ability to ship value (with quality) to customers as quickly as possible. In the community product line, we run with 2-week sprints and a natural cadence for release is 3 sprints or 6 weeks per release. This relieves some pressure on release regression and balances the cost of minor release misses. Along with that, we start to have the time and ability to upgrade all customers to every release. This gets us back to the average time to value we had in the monthly release cadence above. For high priority issues we will continue to have the patch process in case it is needed but we should be able to hold the line on patching features into production off cadence.
Decide, Execute, Iterate
Perfect! Right? Well, this is what we need to see. We need to prove to ourselves and to our stakeholders, you, that this is translating to the goals this change was aimed to achieve. Are we continuing to release with increasing quality? Are we getting more value-packed into every release? Are we leveraging the time given back to improve for the future? Led by our program management team we are poised to track internal metrics, signals from customers, and feedback from internal stakeholders to understand if we are succeeding.
One key part of this change is that we would like to leave it open to evaluate and report back out on the success of the change. Should we find we are not hitting the goals of the change we can always go back to our monthly cadence. However, we would like to make sure we have enough time to evaluate and adjust so we are going to run with this new cadence for at least Q1 and Q2 of 2020.
I appreciate your being a Khoros Community customer and your willingness to pardon our dust that may result from this change. In order to make progress, we need to make a change. Feedback and opinions are always welcome. You can engage here, with me directly, or with your CSM. I believe this will be a positive change and look forward to another year of building great customer experiences together.
... View more
