Speaking to purists on both sides, you could easily come away believing that IT service management (ITSM) and DevOps are two very different practices—perhaps even at odds with each other.
But, many modern practitioners feel differently. They see more in common between the two than differences. What’s more, they believe marrying the two practices together is the only way to truly get the most out of both.
So, which view is correct?
Why might ITSM and DevOps butt heads?
DevOps is all about fast delivery of quality code that adds value for the customer. It relies heavily on automation and the application of Agile principles to streamline the entire software development life cycle.
The priorities of an ITSM practice are different. It provides structure that facilitates (among other things) the orderly collection, prioritization, and management of necessary changes to IT systems. A prominent example of a change the ITSM system seeks to manage is when a critical bug appears and customers are being severely affected.
The DevOps teams, charged with quickly deploying software improvements, may feel they don’t have the time to check with the change advisory board, as ITSM requires, for approval to make the necessary change to the IT environment. Yet the operations people, charged with maintaining a stable, reliable environment under ITSM, can’t just let changes through without any record.
The resulting friction often leads to compromises that can be detrimental to both practices. In some organizations, speed of delivery may trump strict process. This can sometimes result in costly problems with regulatory compliance or poor decisions. Meanwhile, other organizations may prioritize the strict bureaucracy, allowing it to impede the speed and flexibility software development requires to be competitive in modern markets.
To remain competitive, satisfy customers’ needs and desires, and scale effectively, companies need to strike a balance that takes advantage of the strengths of both ITSM and DevOps.
What brings ITSM and DevOps together?
Despite what could be seen as their inherent differences, ITSM and DevOps actually share their most important outcome: delivering customer value consistently.
The customer demands that the product work properly, and that it stays up-to-date with new or refined features that continue to meet their needs. If problems come up, especially if these issues impede the customer’s ability to fully utilize the features that convinced them to buy the product in the first place, they rightfully expect these problems to be solved quickly and not to resurface. If these demands aren’t met, the customer is no longer receiving value and they’re likely to jump ship.
So, both ITSM and DevOps practitioners share the goal of making sure the customer never gets to that point. Accomplishing that goal, especially at scale, requires that they work together.
Achieving the optimal balance between ITSM and DevOps
Back in 2020, Gartner’s whitepaper 3 Steps to Agile IT Service Management, made a bold claim: that by 2023, 80% of ITSM teams that have not adopted an agile approach will find their ITSM practices are ignored or bypassed.
But that doesn’t mean DevOps “wins” this battle. The fact is, “ITSM provides a base set of operational requirements that ensure that the output produced by each product team is stable, operable and supportable,” according to Gregg Siegfried, research director on the cloud and IT operations team at Gartner.
So, experts agree that balance is what’s required.
Ola Chowning, a partner at Information Services Group, or ISG, an IT research and consulting firm, said, “CIOs must modernize their ITSM disciplines, but there’s also a need for changes in DevOps practices. ITSM has traditionally put up high guardrails to ensure control, while DevOps often favors none; they both need to accept at least low guardrails.”
Here are some tips to help organizations achieve that balance:
- DevOps practitioners, learn to embrace some structure. While speed and agility are necessary, flying without sufficient controls is dangerous. Be willing to adapt to the minimal level of controls that will ensure the company maintains compliance and makes the best strategic decisions.
- ITSM practitioners, learn to accept the need for flexibility. There’s no getting around the need for speed and agility in modern software development. The newest ITIL framework actually incorporates a lot of DevOps-related recommendations and language, offering excellent advice to support this change in mindset.
- CIOs and CTOs, support your ITSM and DevOps practices with process refinement and training. The teams looking to strike the balance between DevOps and ITSM can’t do it without sufficient knowledge of how to do so, or while bucking against organizational requirements.
- Make the most of the available tools to support CI/CD within a minimal ITSM structure. Products designed to support ITSM and DevOps are becoming increasingly integrated in support of this vital balance between disciplines. For example, automating the approval process for all but the highest-priority critical changes can speed up delivery and free up those making the approvals to jump immediately onto changes that matter most. A common integrated DevOps toolstack may include
- Discover – Atlassian Jira Product Discovery
- Plan – Atlassian Jira Software and Confluence, or Aha
- Build – Kubernetes or Docker
- Test – GitLab or GitHub
- Monitor – Snyk
- Operate – Atlassian Jira Service Management, Jira Software, OpsGenie
- Continuous feedback – Atlassian Jira Service Management, Slack
If you’re ready to work toward eliminating the friction and balancing your ITSM and DevOps practices, a great first step is learning more about it. Invest some time with the following resources:
- Webinar on demand: DevOps: There and Back Again (A Q&A with Our DevOps Experts)
- Webinar on demand: Tips to Make a Lean, Mean ITSM Machine with Atlassian
While visibility has improved in recent years, it continues to be a key challenge for engineering leaders. There is still much work to be done to ensure leadership is continually aware of certain types of work that are taking time away from established priorities. Here are 3 rules for every engineering leader to increase transparency and build trust and confidence in their teams:
Before we explore options to manage unplanned work using SAFe, it’s important to first clarify what “unplanned work” means.
When might be the right intervals to take snapshots? As I mentioned previously, SAFe does not provide any guidance on this, but one approach that I have observed to be effective is to take a measurement at PI boundaries (at minimum) in order to evaluate how much change has occurred within the backlog. This will enable you to determine how many new requirements/epics have been introduced within that period of time.
Third, the Scrum master role must be seen as an opportunity to advance one’s career by
The traditional
Epic owners will pull the most promising epics into the analysis stage. During analysis, your team members must define the minimum viable product (MVP) threshold, create a Lean business case, obtain preliminary customer validation, and outline the scope of the epic. After analysis, the Portfolio Manager will make a final go/no-go decision.
Of course, an effective leader must act intelligently. That should go without saying, but it’s not always a primary concern when people are hired or promoted. To be successful in a Lean-Agile environment, POETIC Leaders must have a sufficient IQ to support continuous learning, a solid grasp of Lean-Agile values and principles, strong domain knowledge to support the teams’ efforts, and the ability to utilize this intelligence when making business decisions.
SAFe roles, practices, and artifacts come from proven patterns for realizing Agile and Lean principles. There is nothing sacred about the practices themselves. They are practices to help you begin with realizing business agility throughout the enterprise. They are not rules. If you want to adjust, you simply need data to inform your decisions.
In my experience working with Agile teams over the past few years, I discovered a trend that is somewhat surprising – many people believe that
Effective leaders show emotional empathy, which is the ability to understand and share the emotions of others. It requires them to recognize the emotional state of another person and to respond to that emotion in a way that is appropriate and helpful.
Team Thinking Leaders need to help create team ownership.


