1 of 1 people found this helpful
Hi Marie, thanks for sharing your observations. I think you bring up a great question, and I am also interested to hear more about this topic from community members.
As an ice breaker from my side: one thing that I hear from the customers I talk to, is how they can show value and change perception of ITSM in organizations/teams that follow a DevOps/Agile approach. Development teams that follow this approach often have a certain negative perception about ITSM, often rooted in misunderstandings (no, you don't need to have CAB meeting and approval for every change request).
Peter Adams we can talk sometime about devops if you want, being I came from that environment. It is definitely an evolving and changing area. Devops itself tends to be a failure in the eyes of product, program and project managers and even those managing budgets, at an almost 80% failure rate, even more so with the emerging adoption of agile Devops. Devops tends to operate in its own bubble that floats outside of the mainstream. Change Management tends to have no visibility with DevOp and Infrastructure as Code (IAC) thus risk can be high to critical. However, the issues with Change Management, DevOps and IAC are far more complex. The root of the failure is within the organization not the tools and framework. When you take a traditional company/organization that approaches an agile and modern framework the challenges are incomprehensible to the traditional entity and vise-versa. Changes with IAC and DevOps are agile AI-ish and done in a series following different storylines. Remedy CM is designed for the old traditional infrastructure and traditional release methodology. However the CM process needs all to participate or failures will continue because visibility is lacking. I am working on this very situation now, there are many layers of roadblocks on both sides.
One roadblock (there are many) to adopt the traditional “Change Management” process for developers is that developers, stereotypically are not good at documentation, processes and communication.
For many years, I and many others rely on tracking tools that look at what has changed from one release to another and tools like JIRA can automate this and then automate with TFS to release it across a hybrid environment, much of which is based on usage; thus if there are 10 users in London it will release it there automatically however if there are no users in Rome it will not release it there. Traditional CM doesn’t comprehend this “usage/demand” release and it is viewed as difficult and more work, which programmers view as pointless to document it in an inefficient tool (referring to CM) when they already have it documented well in another tool.
I have many many other customers to talk to about this but, I do have some new disruptive rough designs, which are game changers making this an automated, intelligent and proactive change process.
I’d love to hear from anyone on this topic to add to their needs to the design.