ITSM for high-velocity teams
In search of a cure for the pains of ITSM system upgrade season
What a product owner learned about alternatives to traditional ITSM system upgrades.
I was a Product Owner for a Scrum team that developed capabilities for several service management practices using a legacy ITSM system. As the last sprint of the calendar year wrapped up, my team enjoyed an innovation sprint in which we could learn and experiment with new functionality. I used this innovation sprint to look at our ITSM system’s new release. At first glance, there appeared to be tons of new functionality. On closer reading, the new functionality wasn’t useful to our stakeholders and would result in more technical debt.
Once it was clear that our legacy ITSM system had inherent supportability issues, I realized I had two options – accept this and fill my desk drawer with antacid and ibuprofen tablets, or look for a more robust, flexible solution.
My head started pounding in anticipation of the numerous meetings with our process owners and other stakeholders. Just the thought of explaining the content of the new release, the disruption to our development schedule, and what would ultimately be only a small useful impact of all this new work stressed me out. Regardless of how many features we could consume, the tedious process and lost productivity of upgrade season were always the same.
The pains of upgrading a traditional ITSM system
For those who haven’t dealt with this, some of what I describe may seem exaggerated, so below is a snapshot of my team’s upgrade process.This involved many tasks that I’ve distilled into eleven broad steps across three phases from pre-release to release to post release.
Just looking at this makes me tired. And it doesn’t even capture the whole picture. Teams managing upgrades spend significant time and effort addressing organizational change management concerns. End users become frustrated with the twice-yearly disruptions to their service deployments which they perceive to be of little value.
I used to think that my team’s issues with upgrades were isolated, but after attending user group meetings, and reading blogs, I realized that a painful upgrade process was ubiquitous. Some customers complained of upgrades taking over eight weeks and grumbled about lost productivity for their teams.
In some cases organizations are going so far as to “reboot” their legacy ITSM systems to ease upgrades. For example, customers are still trying to figure out how to consume ServiceNow’s Next Experience UI that was included in the San Diego release March 2022. Some enterprise customers are opting to switch off the functionality until they can determine the impact to their users.
As I looked for a resolution, I saw there were band-aids to this problem – leverage partner services for upgrades, forgo any system modifications, use piecemeal automated testing capabilities, etc. Unfortunately, none of these options felt comprehensive enough, and some just introduced more work in another direction.
Seeking relief – a better approach to ITSM systems
The way I saw it, I had two options. I could either accept the inherent challenges of our ITSM system and fill my desk drawer with antacid and ibuprofen tablets, or look for a more robust, flexible solution. In frustration I took to Google, read analyst reports, and consulted with friends in the ITSM space, which led me to Atlassian’s ITSM solution, Jira Service Management.
Frankly, I was skeptical that it could alleviate our issues. I have worked with enterprise ITSM systems for more years than I care to count, and I have also worked in Jira Software for a few years. So I felt confident Jira Service Management wouldn’t address our issues.
I poked at the Assets feature in Jira Service Management for a while, and it seemed easy to configure and load data. Then I started creating projects and service assignment groups. After only a few hours of configurations (and glancing at any documentation), I had developed a working service catalog and service desk that included IT assets and CIs and major incident capabilities.
Jira Service Management incorporates elements from Agile methodology, like “start where you are” and offers out-of-the-box ITIL practices. It was apparent that Atlassian embraced a team-centric approach rather than a tool-focused solution.
Atlassian Approach to Jira Service Management Upgrades | Legacy ITSM Vendor Approach to System Upgrades |
|---|---|
| Agile vs. Waterfall | |
| Atlassian follows Agile methodology for Jira Service Management upgrades that optimizes flexibility, collaboration and efficiency. | Legacy ITSM Vendor Approach to System Upgrades Legacy ITSM vendors use a waterfall approach for upgrades that focuses on structured, sequential releases. |
| Changes on your schedule vs. Required yearly updates | |
| Jira Service Management customers can control their rate of change by setting their environment’s desired release track.Continuous-Products receive changes and features as soon as they become available.Bundled-Products receive changes as a group on the second Tuesday of each month. | Legacy ITSM Vendor Approach to System Upgrades Legacy ITSM vendors generally provide software releases that contain new features twice a year. |
| Ongoing feature releases vs. As-available bug fixes | |
| Atlassian’s approach provides customers with improved business value through shorter, predictable release cycles; smaller, higher-quality code sets; and more transparent, responsive feature delivery. | Legacy ITSM Vendor Approach to System Upgrades Legacy ITSM vendors provide code patches and hotfixes which occur on as as-needed/available- basis. Generally, these patches and hotfixes contain bug fixes but no new features. |
| Loosely-coupled architecture vs. Tightly-coupled code sets | |
| Jira Service Management is based on a loosely-coupled architecture where individual components are built independently from one another.Loosely-coupled applications allow teams to develop features that deploy and scale independently, which provides more efficient code delivery/upgrades. | Legacy ITSM Vendor Approach to System Upgrades Legacy ITSM system architectures are tightly coupled such that functions are rigid and interdependent. When one component changes, there is a ‘domino’ effect of more changes across the application which increases the overall code modifications and risk. |
| True cloud product vs. Siloed SaaS offering | |
| Jira Service Management is designed and created for Atlassian's cloud platform, so customers can scale confidently with embedded security, built-in compliance, multiple instances up to 150 per product, and simplified per-user licensing and simplified per-user licensing. | Legacy ITSM Vendor Approach to System Upgrades Legacy ITSM system are often designed to run on-premises, and vendor simply host the applications remotely.These are not true cloud solutions and can’t provide you with the same benefits - scaling, upgrading, pricing, and security - as a true cloud system. |
A healthier approach to ITSM system upgrades
Getting into the issue of upgrades, Atlassian plans for technology evolution, so when new capabilities are available the functionality can be seamlessly introduced to the platform and products. Atlassian’s cloud roadmap is public, so customers can always see what’s coming. Jira Service Management’s cloud-based system means that features are available for customers to consume continuously or on a scheduled basis. Customers can:
- subscribe to weekly release notes for the most up-to-date notes on coming changes
- create an isolated environment (aka Sandbox) to experiment with feature changes before hitting production
- control their rate of change by setting their production environment’s release track (continuous and bundled)
- benefit from small, incremental updates that provide continuous improvement
Because Jira Service Management is based on loosely-coupled code sets, it provides improved code flexibility/reusability and more efficient application upgrades.
We all want to accelerate digital transformation so our organizations can “work smarter rather than harder”. I have found that Jira Service Management’s agile incremental change and improvement upgrade approach allows us to continue to validate releases and engage with end users – simply at a more continuous, faster, and non-disruptive pace.
If you’re embarking on a digital transformational journey, I recommend reviewing each application’s core architecture and implementation approach as well as the total cost of ownership. Consider your business initiatives that you are trying to achieve and choose a system that meets your needs and adds value to every customer interaction.
Learn more about Atlassian’s approach to service management The complete guide to Atlassian for ITSM.
Atlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
Read the whitepaperWhat is service request management? A guide
Service Request Management enables IT teams to quickly and easily fulfill customer requests. Check out the process and best practices.
Read the article