Another Day, another set of Keynotes! Let me just say, every year I’m blown away by the response to the Keynote Recaps, and yesterday’s post was no exception! Today I’ve lined up both the ITSM and Software Keynotes. So let’s dig into the ITSM Keynote
Just going to say it – having your CI/CD tools generate a change request rather than your Dev Teams (or more likely, a bespoke integration you have to build and maintain yourself) does sound like it would save a lot of time.
First: A note for Atlassian for Future Team events. If you are announcing something new, put it full screen for those of us remote.
Second: It took me a bit to understand the context hear. Atlassian’s exact words here are that their “Risk Assessment Engine” has new advanced rules that can auto-approve a change, let a change “soak” (their words) in Staging, or go to a human as a High Risk. At first, my thought was, “Shouldn’t every change go through Stage?”
But as I thought on it longer, I think what they meant by Soak was “Leave it in Staging for a while longer,” not as I originally thought they were saying, which was having Stage as an optional step. If this is true, they could have done a better job explaining it, but it does make sense as a Feature.
For High-Risk changes, Atlassian is working to provide you with more information than ever. For example, Jira Service Management here is aware of your Project dependencies, and can see and alert you to an incident in a dependent service, and even let you drill down and see details about that incident and service.
Atlassian also announced Change Scheduling, which lets you see in a calendar view all the changes planned, so you can slot your change in at a time where it makes the most sense.
When you do schedule, Jira – which again is now aware of your Project dependencies – can alert you to conflicts and incidents that might affect your change.
Another new feature is using Atlassian Analytics, which allows you to graph your changes over time to know how fast your teams are working.
Now, again personal opinion, but More code deployments does not mean Better code. I see this being a tool being used to push Devs to their absolute limit, which means they are going to start taking shortcuts. And Dev shortcuts tend to reappear as Tech Debt, Bugs, and Vulnerabilities.
So having a blind metric of “Changes per month” without any context of how your team size changes, environmental factors, or anything else seems like a problem waiting to happen.
Now we moved from Operations to Support – the other use case for JSM. Their first announcement was the fact they are expanding their Catalog of pre-built forms for teams. To which, I say “Yes, Please!” As a Jira Admin, I can build anything my teams need, but if you can get me 90% there, that saves me time and energy. I can still do the last 10% to make it perfect for my teams, but they are well on the way to having value-added right off the bat.
Now we see where they are using ProForma in allowing you to modify your Form. This is FAR more flexibility than the old Screen setup ever allowed.
Isn’t this….just Confluence? I could have sworn JSM Server/DC had something like this for years when paired with Confluence. But at least it’s built-in now.
Yes, it’s literally powered by Confluence. I mean, having it built-in is one step closer. But I can’t help thinking this isn’t really a win…
Now we have the Halp Acquisition showing up. Getting help from Slack or teams could be a big win for your teams’ customers.
Again, we are getting a new feature for JSM built off of a recent Acquisition. Percept.AI allows you to set up a virtual Agent to handle the simple requests.
The idea is the agent can use both clues it can find on users in tools like Insight, Identity Management, and Jira, and figure out what the user wants and how to best serve it.
And if the issue is too complex, it forwards the issue seamlessly to a human to add further details.
No code customization of the Bot behavior is a definite benefit , as is the Natural Language Processing engine.
They then go into how Enterprises use a myriad of tools, and how it’s impossible to standardize on one tool for Service Delivery. Let that sink in, Atlassian, the tool many companies have chosen to standardize on, is saying “Yeah, don’t.”
And that leads to the inevitable question – Where do you get help when you need something specific?
So Atlassian wants to help you not standardize by providing a standardized gateway to all the non-standard places. Yes – it took me a second to fully wrap my mind around.
The concept is that you can take in requests from a number of channels…
…and route them to the appropriate resource based off of the context of the ticket. But take note – it can route the request to more than just Jira Service Management. Again, think about it, a central portal that can route a user to the tool they need easily. And Atlassian is saying it doesn’t have to be their tool, either. This could be big – if it’s set up right.
And that was their final Announcement. To be honest, I initially found the ITSM keynote a bit light on substance. It wasn’t until a rewatch that I really came to appreciate it fully. Most of it still was “See these great features we purchased,” but honestly, why reinvent the wheel?
If you missed it live, here is the youtube video for it to rewatch yourself!
I still owe you a Jira Software Keynote, but that will be coming as soon as I can get it out. But until then, my name is Rodney, asking, “Have you updated your Jira Issues today?”
The Jira Guy 