How ITIL 4 incorporated Agile, Lean, and DevOps practices
ITIL 4, launched at the beginning of 2019 and has positioned itself differently to its predecessor, ITIL V3. ITIL V3 seemed designed to encompass other frameworks and fit them into its comprehensive lifecycle model. In contrast, ITIL 4 seems keen to acknowledge its position as one framework among many, anxious to be seen as fitting into a broader structure – in short, to be supportive rather than dominant. That attitude allows ITIL 4 to refer to other frameworks rather than repeat or re-invent the wheel. For those who already know other frameworks, or want to see how ITIL 4 has incorporated ideas, it can be interesting to pick a few and show the linkage and correlation between the frameworks.
Change of attitude more than content
ITIL 4 does use concepts from other practices, such as Agile, Lean and DevOps, and I’ll share some examples below. It’s worth noticing, however, that the change in ITIL 4 is largely one of attitude. The vast majority of ITIL has always been consistent with what would now be viewed as DevOps cultural attitudes, per this extract.
“Staff may well find themselves allocated (fully or partially) from operations tasks to support a design exercise and then follow that through service transition. They may then, via early life support activities, move into support of the new or changed services they have been involved in designing and implementing into the live environment.”
Those words are from ITIL V3, written during early 2007 before Patrick Dubois had even coined the phrase “DevOps.” Given that much of the sentiment was already in place, what is there in ITIL 4 that will make the DevOps or Lean aficionado feel at home?
Changes to terminology
There are some changes – that require readjustment by those used to ITIL V3 and that have been made to be consistent with Agile attitudes.
Incident and Problem
The traditional ITIL definition of incident gives equal value to an actual or potential impact on the user community. The focus from other frameworks is much more on addressing issues that do affect users immediately. It’s important to see potential causes as something with which to address through problem management – seeking errors in code or infrastructure that will appear on product backlogs for remediation according to a wider sense of priority.
Deployment and Release
DevOps, especially in relation to the “continual” spectrum – from continual integration to continual deployment and even continual release – has developed precise and distinct for these two terms that were combined and indistinct in previous ITIL versions. The DevOps conventions have been adopted in ITIL 4, where Deployment puts something (typically software, but the term works equally well for other aspects of a service) in place. Release is when that item becomes available for use.
Value
The biggest change, and one that Lean thinking heavily influenced is the central positioning of value and value-based tools in ITIL 4. Not, of course, that the term “value” is at all low profile in previous ITIL versions: customer value is considered paramount, but ITIL 4 goes much further.
The centerpiece of ITIL 4 is the Service Value System (SVS), and its heart is the service value chain, a concept that will be immediately familiar to anyone who has learned about Lean thinking. Value streams are the ITIL 4 tool of choice for documenting activities. One key benefit of the ITIL 4 structure for the SVS and value chains and streams is that it shows how the practices – all 34 of them – are tools to be used and applied across the value stream. In doing so, it helps prevent the development of siloed thinking. Critical to a DevOps philosophy, ITIL previously was typically read as advocating separation and silos – Service Design, Transition, and Operation. While that was never the intention (see the earlier quote), nonetheless, the new presentation format helps greatly to stem that tendency to see silos where they should never have been.
For DevOps and Agile thinking to be successful, measurement must be at a higher level than has often been associated with ITSM: individual measurement and reward is one of the most powerful forces for separation and internal competition, whereas DevOps rests on the pillars of Transparency, Inspection, and Adaptation. Above all, there is a team ethic. That – effectively – not only requires all parties to contribute to all efforts, but also to receive the resulting value. ITIL 4 refers to this as “co-creation of value” and it is a fundamental concept for wide collaboration to be successful.
ITIL V3 mentioned suppliers creating value for the benefit of customers. Just reading it, the divisiveness of the concept is clear. By ensuring that the value creation process rewards everyone, collaboration is reinforced and teams targeting towards shared goals becomes ever more possible.
Two-way traffic
Of course, this should not be seen as ITIL becoming subservient to other frameworks. In fact, the concept of seeking content from other frameworks has been employed in the IT space for many years. Those attending a DevOps course will be expected to learn about ITSM, Agile and more. There is no reason to re-invent the wheel when merely linking to a perfectly serviceable approach delivers the required value. What ITIL has done is to recognize a good common-sense approach – as exemplified by the DevOps culture – and adopt it. This is yet another example of how ITIL 4 is a framework living comfortably with its neighbors.
Blog cover by Nidhi
