Zero Tickets to Paradiseby Jay Cuthrell
This week we take a look at the goal of attaining a near zero ticket developer experience with AIOps.
__Survey results: How many words should Fudge Sunday issues aim for each week?__
The majority of responses landed on close to 500 words but that 1000 words was too many i.e. “less is more”. So, I’ll do my best to judiciously edit down going forward!
Previously, Fudge Sunday has covered the concept of tickets in IT Service Management (ITSM). Last week we covered the concept of a service catalog as part of an internal developer platform (IDP) or developer portal within the larger developer experience (DevX).
The next wave of promises about promises (functional contracts) might be less tickets, zero tickets, or ticketless versions of the developer experience. Regardless of the terminology that becomes commonplace, the goal is the ruthless removal of annoyance in the form of tickets.
Said another way, if you aren’t enabling developers to either _do the work_ or _go directly to an outcome_ it means a shift in the work to _elsewhere_ and _an undetermined length wait state_. Or, in a nutshell this limits the culture of _“working as hard as you can”_ to being a culture of _“waiting as hard as you can”_.
First, consider documentation. Does better documentation lead to less tickets?
In fact, look at a recent study where practitioners were the sample. Tickets to Ops teams are not the way of the future.
[ Reliance upon Ops ] leads to Ops bottlenecks where developers write tickets and then simply wait
After all, documentation can drive automation creation to drive adoption with experimentation and those outcomes can be associated with metrics. Also, metrics can be a means for measuring niche machine learning models as the basis for so-called artificial intelligence (AI) used in Operations aka AIOps.
It’s important to keep a perspective about the sheer number of tickets (annoyances) that AIOps might be able to solve for without any human interaction. That said, developer annoyances are not the same as general knowledge worker annoyances — not to mention the size differences of these two communities.
Lately, the term AIOps has enjoyed a bump in popularity. So, while not specifically DevX related, AIOps could be used to enhance DevX where tickets are presently a part of business as usual to get things done (GTD).
Tickets consume time, energy, and productivity cycles. In other words, reducing tickets is way to gain or recover time, energy, and productivity cycles.
Oh, but where to invest those productivity cycles… Perhaps invest in… DevX that has less tickets quarter over quarter and year over year?
Promoting the notion of a ticket reduced to ticket free or ticketless DevX requires a GTD champion within platform engineering that has executive support. With that in mind, consider the following examples of investments made in AIOps to reduce tickets in Enterprise settings:
- FISERV shares AIOps best practices (Moogsoft)
- Johnson & Johnson shares AIOps best practices (IBM)
- Wells Fargo shares AIOps best practices (Databricks)
- The State of AIOps 2023 (OpsRamp)
So, what will be the next big thing in ticketless DevX with AIOps?
Until then… Place your bets!
I am linking to my disclosure.
✍️ 🤓 Edit on Github 🐙 ✍️
Get Fudge Sunday each week