15 Hacks Required to Align ITIL and DevOps

DevOps? ITIL? DevOps versus ITIL? There’s still lots of talk around which approach companies should take. But thankfully, there’s a growing appreciation that both approaches have a part to play in better IT service delivery.

The DevOps movement is still only eight years old, and it’s sometimes hard to believe that it’s younger than the smartphone – iOS or Android – in your hand. The ITIL IT service management (ITSM) best practice framework is one of the granddaddies of IT management frameworks, dating back to 1989, with its most recent update published in 2011. But despite the closeness in time of DevOps’s creation and ITIL’s latest edition, and the fact that they’re both part of the same IT family tree, there are a number of obstacles to exploiting both.

In this blog, I’ll share some ideas on how you can bridge and blend help from both approaches. This will take the form of 15 “hacks.” A hack being a clever, virtuosic, sometimes inelegant yet wizardly shortcut to getting something done quicker, and more efficiently!

Please read on to find out more… And be warned, there’s a lot being said in the next 1000 words – probably even more than a picture can paint.

The Theory of Relativity

Relativity, no not Einstein’s – ITSM’s!

In theory, all the “best practice” frameworks and approaches share a common goal – to help an IT organization better serve its customers. They often refer to common concepts and methods, and this is true for DevOps and ITIL. They each contain a core “lifecycle.”

Those familiar with the ITIL framework will recognize the service lifecycle it offers, spanning four major stages (strategy, design, transition, and operations). These stages are underpinned by a fifth “stage,” representing a commitment to measure performance and improve – continual service improvement (CSI).

The DevOps movement generally follows a systems and application lifecycle spanning seven stages, with four representing Dev (Plan, Develop, Build, Test), and three Ops (Release, Operate, Measure).

The above simple representation of both lifecycles helps us to better identify the touchpoints (and also the points of friction), and how each lifecycle relates to the other – the “relativity.”

For example, the DevOps “Plan” stage maps to ITIL’s Service Strategy and Design stages, the DevOps “Develop” stage to ITIL’s Service Design, and so on. Using this simple mapping we can start to unbundle the common touchpoints and uncover the hacks needed to glue together both the underlying concepts and best practices of both approaches.

15 ITIL and DevOps Alignment Hacks

For ease of reading, I’m going to use the ITIL lifecycle stages to offer and explain the 15 hacks I feel are required to ensure a better alignment of ITIL and DevOps thinking. Starting with Service Strategy…

Service Strategy:

1. Some of the responsibilities of the business relationship manager, such as the definition of functional requirements, should be moved to better align the service owner role with the DevOps product owner role. The service owner role should think and act with an “outside-in” bias.
2. Governance rules for making decisions and performing all activities during the service lifecycle – should include how stories are prioritized, sprints assembled, scrums managed, issues reported and resolved, daily stand-up meetings conducted, and reviews and retrospectives
3. The service owner responsibilities should include ongoing acceptance and prioritization (backlog grooming) of stories from CSI, and communication of planned improvements.

Service Design:

4. The Service Design stages should maintain a catalog of user (customer) scenarios to ensure synchronization with the DevOps concepts of stories and user experience design.
5. The designers, developers, and testers of any improvement should be primarily responsible for technical requirements, and be allowed to suggest adjustments to the requirements catalog entries as part of their DevOps continuous delivery and continuous integration
6. The design, development, and testing of an improvement should include key DevOps concepts such as built-in quality (a lean concept of avoiding work starting with ‘re’ such as rework and repair), canarying (a go-live strategy in which a new application version is released to a small subset of production servers or a specific subset of users), and chaos monkeys (where software code intentionally creates different failures and tests the ability to survive them).

Service Transition:

7. The configuration management system and underlying database (CMDB) should support the DevOps concept of containers (a common set of building blocks that can be reused in any stage of development to recreate identical environments for development, testing, staging, and production).
8. The release management system and the core release schedule should support the Agile thinking concept of a release train, representing an agreed timetable of specific incremental improvements delivered through a distinct series of versioned releases and sprint schedules.
9. Release plans should include the timing and orchestration of sprints, daily stand up meetings, showcase (team demo) sessions, and reviews and retrospectives (identifying what went well, what didn’t, how to improve on next iteration), to ensure progress may be tracked and reported upon.

Service Operation:

10. The service support function (help desk/service desk) should be involved during the latter stages of testing and use the DevOps concept of stories to assist in the verification of any organizational change components such as role-based training and key messaging.
11. The incident management system should support the recording of development issues, bug tracking, and similar events during the early life or warranty phase of a release, and be able to relate these to recent DevOps sprints and the stories they contain.
12. The service level manager role should have an added emphasis on real-time, operational performance and incorporate the DevOps review and retrospective concepts of micro and macro problem solving workshops to help prioritize information for the service owner.

Continual Service Improvement:

13. The CSI process and role should synchronize its Plan-Do-Check-Act (PDCA) cadence (frequency and duration) of service reviews and performance reporting with the timings of DevOps iterations (sprint/release combinations).
14. The CSI register should be carefully aligned with the DevOps issue tracking system, and the product owner’s product backlog.
15. The problem management process and its related impact definition method should be aligned with the DevOps problem-solving workshop methods, and incorporated into an overarching continuous improvement system, fed by real-time operational and service performance data.

I did warn you that there’s a lot to say on this, even if at quite a high level. But hopefully it’s enough guidance to get you thinking about where DevOps and ITIL “touch” and what needs to be done to allow them to be used together effectively.

I hope the 15 hacks go some way to bridge the conceptual gaps that exist between the approaches, and to help you to succeed in your pursuit of operating with agility and producing high quality product and services, with an accelerated time to value, and improving levels of customer satisfaction.

Note: Many of the DevOps concepts used in this blog are drawn from the Safe Agile Framework (SAFe® 4.0). More information about this source may be found at their website: http://www.scaledagileframework.com.