December 23 2017
Why Retrospect Standardized Its Release Cycle
In 2011, Retrospect was spun off into Retrospect, Inc. For seven years, we had operated as a small group inside of a larger company, but at that point, we were on our own. We had just shipped Retrospect 9 for Mac, and we had a lot of ideas for what we wanted to do. One of them was changing our release cycle.
Our previous release cycles had been quite variable. We maintained both Retrospect for Windows and Retrospect for Mac, but we never shipped them simultaneously. Both versions supported many languages, but we never shipped those simultaneously. We added features to both products, but we rarely added the same features in both places. We always planned for regular releases of both products, but we let the schedule dictate the final dates.
All of those release decisions had their reasons, but now we had an opportunity to rethink them. We wanted to change all four: major releases of both products in all languages with feature parity, every year.
Our first release was in November 2012: Retrospect 8 for Windows and Retrospect 10 for Mac. We released both products simultaneously in all languages with our big feature, Instant Scan, baked into both. We slipped the next release from November 2013 to March 2014 while we were putting the finishing touches on block-level incremental backup, but we’ve shipped every March since then, with performance increases, cloud backup, scalable data protection, and hundreds of smaller improvements and fixes.
The constraints of a standardized release cycle have helped every department. Sales gets a consistent release of both products every year, instead of wondering when a particular feature will be in which product. Marketing can focus its energy on a single launch, rather than juggling multiple releases with different features in different languages. Support helps customers with the same feature set in both products. Finally, Engineering can triage new features and bug fixes within a known timeframe. We used to have many Engineering discussions over whether to include yet another feature in a release because the release dates were always malleable. Now we discuss in which release to include the feature.
These are problems that every software company deals with, and when we started making these changes, these results weren’t guaranteed. But having made the switch, we’re incredibly happy with the new process. By standardizing our release cycle, we accepted a set of constraints that streamlined many internal processes and made the company far more efficient at delivering features consistently across multiple platforms and multiple languages.
