Recently we asked one of our XL Release customers, a major North American insurance company, what they gained by going from Excel to XL Release.
“Six months ago, we knew we needed to improve our release process. We were expected to deliver more and more applications quickly and efficiently, and our process just wasn’t cutting it. Like many other organizations, we used a combination of Excel spreadsheets, Wiki pages and emails to coordinate releases, and the same problems kept cropping up over and over again: team members working with outdated versions of the release plan, no up-to-date insight in what the status of currently active tasks was, the discovery during the 9am status call that a particular task hadn’t been performed the day before because the assigned team member was called away to handle other urgent task, etc .etc.
On top of these usual pain points, we also started to look at the efficiency of releases, and discovered that the sheer amount of manual coordination involved was costing us so much that we would not have been able to introduce a Continuous Delivery
policy as part of our Devops
implementation cost-effectively: each release was costing us a small fortune!Our initiative to introduce Continuous Delivery resulted in three goals for our release process:
- To improve the efficiency of our releases through automation and standardization
- To move towards more and, ultimately, fully automated delivery pipelines to enable more fine-grained releases
- To be able to implement our transition gradually, starting with our manual process at the time. Boiling the ocean was definitely not an option
With XL Release
, we were able to describe our existing process in a release template in under 30min, without having to make any adjustments to the process itself. That already saved us from the problem of team members using out-of-date versions of the plan, and dramatically improved insight, collaboration and communication. Almost immediately, we replaced steps in our Excel sheet in which a team member simply invoked a script or carried out a task such as invoking a Jenkins job or creating a JIRA ticket, with XL Release’s provided automated tasks. This rapidly reduced the number of manual steps in our process and highlighted very effectively where we still had “work to do” in order to move towards a fully automated delivery pipeline.
Over the last couple of months, we have used XL Release’s
reports to identify which of these manual steps are actually causing us problems, whether in terms of time spent, number of people working on the task, or simple lack of predictability of how quickly the task will be completed. We have used this information to help make decisions about whether to amend our process, invest in additional automation, or to simply accept these tasks as (current) limitations to our acceleration.
Looking back, it’s clear that a fully-fledged release coordination and orchestration tool such as XL Release
can do so
much more than a Word document, Wiki page or Excel spreadsheet that’s it’s hard to imagine we even regarded them as comparable at the time. For some of our “die hard” stakeholders, we actually export our XL Release
pipeline runs back to Excel, but most of them prefer logging into XL Release’s
web interface and tracking progress on their release dashboard.Do we think XL Release is better than a Wiki page, Word document or Excel spreadsheet? No, we don’t think it’s better…it’s fundamentally different.
We went from manual, highly resource-intensive and stressful monthly releases to weekly, or in some cases daily, largely or fully automated release pipelines, gradually improving our release process to allow us to meet the demands of our customers for more features, faster. That’s not something we could have done with Word, Excel, MS Project, wiki pages, emails, or any combination of those.”