In the early 2000’s a new renewed movement for the Agile Sprint and more specifically a faster delivery of new features came into full motion. Companies such as Google and Facebook were developing at a break neck speed and revamping the industry and how software was being released. Enterprise focused applications like Salesforce were also pushing the edge in how often and how quickly patches and features were being released forcing customers to take a different approach to delivering software.
When I was your age…
Releases came once every 4 or 5 years at best. Large Enterprise software updates, especially on mainframes where hours of line by line patching was required, extensive parallel environments and dedicating teams of business users were needed to test the new system for weeks prior to releasing it.
On the PC and consumer end, things were slightly faster. Windows 95 was followed by Windows 98, followed by Windows XP 3 years later. Salesforce initiated a “seasonal” release, although it is actually 3 releases per year not every season. But this was a sign of the times to come.
Take a look at Google’s release schedule for Chrome compared to Microsoft’s Internet Explorer!
Even Chrome’s early days, the releases were few in number (~ 4 per year). Today they average 24 per year.
The need for Speed
Speed and iteration aren’t just about fueling development teams with more pizza and tighter timelines. It was implemented for several great reasons and other no so great reasons.
- Faster releases allow customers to receive fixes to issues they are facing with much faster.
- Customers are re-assured that continued investment in their software of choice is being made with the addition of new features, especially those they suggested or need.
- Making the releases smaller in amount of changes makes it easier to test the changes and easier to implement.
- Makes the workload more manageable for the development and QA teams.
- Makes customer adoption gradual as opposed to having to re-learn an entire application each time.
The not so good:
- Even small changes can cause a disruption.
- Internal and Customer teams may not be available for each specific release to test and ensure that all is well.
- Changes that are thought to be an improvement turn out to be a disruption.
- Harder to implement larger changes in a short amount of period.
In the end, you can implement scrum and daily stand-ups to your heart’s content, but we still have to face the issue of ensuring that most things need to be tested each and every time.
The ClicData Challenge
ClicData’s challenge goes beyond a simple Software as a Service (SaaS) application that stores data about your financials, invoices or customers. We are not a CRM or Financial application where the input of data is controlled by the application. We do not have a field for the Customer Name, the Invoice number, or the purchase date. In fact, we do not know what data our customers will load on ClicData! All we know is that the data can come from a wide variety of data sources (over 250 types of data sources each with their own standards), that you can use thousands of formulas and combinations to work on the data and combine it in a near infinite number of ways, that you can visualize it in over 50 widgets each with thousands of settings and combinations, formulas and interactions and that you can use any of the available different browsers (Firefox, Chrome, IE, Safari, Opera, …) across multiple versions (that change 24 times a year) and devices.
No I am not whining… we love what we do. It’s a challenge for sure but we love it. But it is very hard to keep up with the changes on all the different operating systems, browsers, new standards, APIs, and data sources in addition to our own changes.
Our Release Schedule – Then and Now
Since 2015, we have been delivering a new release every 2 weeks. We felt it was a great pace for us and we still feel that we could continue at this pace, but we also realize that if we had more time we could do better and more work. Our customers have also told us that although they appreciate our fast moving pace, they too need time to organize their teams to ensure that new releases have no impact on their data and dashboards.
As such, starting January 2019, we will release once a month. We feel this is a great compromise to give us more time to developer better and bigger features, have more local, unit and integration testing using our suite of test data and dashboards and to give us more time to review the release prior to the actual date.
Below you will find the release schedule which is every last Tuesday of the month.
The areas in green are where we develop the features for delivery at the end of the month. This is followed by a Release Preview Environment (RPE) where internal and customer teams can log in to an environment to test the new features, review data and dashboards and overall test specific functionality. This process and environment and pricing is currently under development for customer access – more information on the RPE will be made over the next few weeks.
It is during that week that specific work items will be either accepted, fixes applied, or rejected for release. The release numbering will change from its current incremental number 4.9.x to reflect the year and month and individual build, for example 2019.1.200 (the 200th build during the month of January, 2019)
Additionally, and as always, we have our entire development and testing team on standby during and for 2 days following the release to ensure that if anything needs immediate patching we will address it immediately.
We love speed. We love giving our customers new features and ensure that everything works as expected. Changing the release cycle to monthly is a sign of maturity but more importantly it is a sign that we listen to our customers and that we prefer to deliver things right than faster, that we want to make sure that everyone understands the new functionality and that we have time to deliver bigger features.
As always, please feel free to let us know your thoughts on our new release schedule directly with me at telmo.silva[/at]clicdata[/dot]com