Bringing DevOps principles into your IT service and engineering teams is proven to dramatically improve service quality, team morale, problem-solving, and business productivity. In fact, companies that adopt DevOps principles report an average of 45% higher customer satisfaction, 43% higher employee productivity, 41% improvement on defect rates, and 38% less IT-related costs.

With stats like those, integrating DevOps principles into IT service management is a big win for companies. But it can also sound like a complicated change for teams. The good news? It’s not as complicated as it may seem. The keys to higher-performing services are so simple, they might surprise you. 

What is DevOps?

So, what exactly is DevOps? It’s a set of practices that bring together two frequently siloed teams with a long history of butting heads—development and operations. The goal is collaboration, open communication, and finding ways for both departments to meet their respective goals.

As our experts explain: “DevOps is a set of practices that automates the processes between software development and IT teams, in order that they can build, test, and release software faster and more reliably. The concept of DevOps is founded on building a culture of collaboration between teams that historically functioned in relative siloes. The promised benefits include increased trust, faster software releases, ability to solve critical issues quickly, and better manage unplanned work.”

Why DevOps for IT support?

From a business perspective, the numbers speak for themselves. 45% better customer satisfaction. 43% more employee productivity. 38% cost reduction on IT-related costs. The DevOps movement has helped business bottom lines in a significant way. Which is probably why 4 out of 5 companies say they are using at least some DevOps principles.

Equally as compelling for teams themselves, when done well, DevOps improves employee and team satisfaction, collaboration, and recognition. It smooths out rough processes, speeds up tasks, and removes a layer of bureaucracy that has long caused tensions across IT, development, and other interrelated teams. 

Where ops teams used to get frustrated by new releases they knew nothing about and weren’t prepared to support (and, which, according to Gartner, cause 85 – 87% of incidents), DevOps opens the lines of communication and prepares IT operations for what’s coming. Where development teams were frustrated by operations push-back that slowed launches, now teams can work together for faster launches that don’t put SLA promises and SLO goals at risk.

DevOps for IT service: best practices

Prioritize cultural change

The biggest challenge of DevOps integration is the cultural shift. 

Traditional IT organizations are often siloed, with the development team working within its own separate ecosystem and ops taking over—often with little to no warning of systems changes before they happen—once a change is launched. 

DevOps organizations, on the other hand, prioritize collaboration and cross-team communication (through practices and tools like hack days, stand-ups, and chat rooms).

Embracing this change means embracing new tools, new processes, and a new cultural perspective that prioritizes cross-team communication and shared success.

Automate where you can

The productivity gains of DevOps are, at least in part, due to a philosophy that prioritizes automation. Embracing DevOps means encouraging teams to constantly ask: where can we automate? 

Can we automate code review for common errors? Can we automate systems to link problems, incidents, and requests to the changes or releases that may have triggered them? Can we automate checks and balances that keep us from releasing code that doesn’t meet security or legal requirements? Can we automate systems to freeze new releases when we’re dangerously close to our SLO targets?

There are dozens of ways to automate and improve DevOps metrics. Three of the most common are:

• Workflow (for example: moving support tickets through the service desk faster)
• Knowledge (when an incident comes in, your service management tool should automatically surface relevant knowledge and documentation)
• Escalation (if there are only two people in your organization who can solve a problem, a smart system should escalate it straight to them instead of following rigid, linear escalation paths)

Track important metrics

As development and IT operations work together, good practice dictates they also track how things are going. 

Common DevOps key performance indicators (KPIs) include MTBF (mean time between failures), MTTR (mean time to recovery, repair, respond, or resolve), MTTF (mean time to failure), and MTTA (mean time to acknowledge). Many companies also rely on figures such as the number of alerts or requests generated in a certain time frame, the cost of downtime per minute, or the cost of support per call/request. 

The metrics your teams will need to track depend on the teams themselves, the promises made to customers in your SLA agreements, the SLO goals you’ve agreed upon with the organization, and any specific trouble spots you’re targeting. It’s also important to realize that metrics are a moving target. As things shift within the company–from the products IT is supporting to stakeholder needs to any external legal or security obligations–the metrics you track and how you track them may also need to shift. 

Prioritize sharing

DevOps is about bridging the gap between creation and maintenance, creators and supporters. It’s about creating shared views, goals, process, and vocabulary. It’s about sharing knowledge and communication. It’s about shared toolsets, resources, and codebases. And, perhaps most importantly, it’s about shared ownership—which means shared responsibility and shared successes.

For many traditional organizations, making the shift to DevOps will mean re-thinking how you define, reward, and track those shared responsibilities and successes. Are the goals of the development and operations teams at odds? Does success for one team make success for the other team more difficult? 

For example: If the development team is tasked with launching new features as quickly as possible and the IT operations team is tasked with maintaining uptime, those two goals may have a negative impact on each other. Operations may want to slow developers in order to exceed uptime goals and development may resent operations for keeping them from meeting their launch goals. 

The solution for many DevOps teams is an SRE approach, where as long as uptime is within SLO goals, development teams can launch as much as their hearts desire. And when uptime drops to unacceptable levels, all launches freeze until teams work together to get uptime back to where it needs to be.

ITIL vs. DevOps

If you follow ITIL perhaps you’re wondering where DevOps fits in. For many companies, ITIL and DevOps practices can work together. In fact, here at Atlassian, we see a lot of companies embracing the upsides and strengths of both.

As this piece on DevOps vs. ITIL explains: “We need both. We’re talking about complementary, not competitive boxes. We need to be able to work smarter and quicker, but we also still need process and control. Modern, high performing teams and organizations are starting to realize this and use elements of both – they’ve moved beyond the either/or ultimatum.”

ITIL tends to address best practices for operations, support, governance, and other core business functions. DevOps brings to the table things like continuous delivery, blameless culture, collaboration tools, and agile practices that enhance and build upon the practices long built into the ITIL guidelines.

Tools for DevOps-oriented organizations

Embracing a DevOps approach may also mean embracing new tools—for communication, automation, and cross-team collaboration. 

When assessing new tools, it’s important to ask questions like:

• Does this tool work in our environment and integrate with existing tools?
• Does it meet our needs?
• Do all new tools work together in a comprehensive, cohesive toolset? 

We may be biased, but at Atlassian, we use Jira Service Desk for incident and change management, Confluence for knowledge management, Jira Software for software development, and Bitbucket for our code repository.

Part of the reason these tools work so well is that they work well together. And when you’re moving away from silos within your team structures, you’ll also want to move away from silos in whatever tools you choose.

Source: atlassian