ITIL® 4 and DevOps

A cultural perspective

Mark Smalley

Discussion paper
March 2019
Contents
1
Introduction 03

2 The way we do things around here 03

3
Complexity thinking 04

4
IT service management 04

5 Digital enterprise and transformation 05

6
ITIL’s guiding principles 06

7 DevOps’ generative culture 07

8
Mental models 07

9 Learning by experimenting 08

10
More than culture 08

11
Summary 09

12 About the Author 09

13
About AXELOS 10

14 Trademarks and statements 10

02 ITIL® 4 and DevOps AXELOS.COM

1. Introduction
Marketing guru Seth Godin defines culture as “people like us do things like this”. People’s actions are
based a multitude of factors including:

zz deep-rooted values that hardly ever change

zz habitual thought-patterns that sometimes change with new insights
zz emotions that can depend on how we woke up today.

Our behaviour at work is influenced by our organisation’s unique set of interconnected artefacts, symbols,
rituals, language, professed values, beliefs, assumptions and unspoken rules. In other words, “that’s just
how we do things around here”.

2. The way we do things around here

In addition to how our environment influences us, we tend to stick to our habitual ways of working.
When we become used to a particular style of working, it takes quite an effort to change it. Even more so
when the new behaviour is not aligned with “the way we do things around here”. This is crucial in order to
understand Change with a capital C. Here are four examples:

1. Process
If, for instance you are used to working in a predictable organisational ‘system’ where it is effective to follow
predetermined processes. When faced with a problem, your instinct is to tighten up the processes, applying
more control. This is a legitimate approach when the relationship between cause and effect is clear to see.

2. Analyse
Imagine you work with issues that require analysis before you know how to deal with them. You rely on
gathering information to guide your approach. When faced with a problem, your tendency will be to keep
looking until you have enough information. Which is acceptable when the situation is knowable. But this is
ineffective when there is not enough causality to be able to determine all the steps needed for the case in
question. When it is simply unknowable.

3. Experiment
Pretend you work in a highly unpredictable system where you can only make progress by taking one step
at a time. After each step, you closely examine whether the step has changed the circumstances and
therefore the next step. There is no knowable answer, therefore you have to experiment. When faced with
problems, your inclination will be to take a step-by-step approach, even when some analysis could provide
enough information for several if not all steps needed.

4. Dictate
Your environment is dominated by major incidents that need to be addressed very quickly to prevent
damage. There is never enough time for analysis or experimentation. You have to act resolutely and people
have to follow your command, otherwise serious damage will occur. When faced with a problem, even
if it is not a major incident with these potentially disastrous consequences, your reaction will be to take
command and order everybody about.

AXELOS.COM ITIL® 4 and DevOps 03

3. Complexity thinking
If you are familiar with complexity thinking and the Cynefin framework, you will probably have already
recognized four of the five domains of this sense-making framework: obvious, complicated, complex
and chaotic.

Obvious and complicated are predictable domains. Something complicated will need more work to discover
the causality. Complex and chaotic are unpredictable domains, the main difference is that chaotic is
dangerously unpredictable and therefore needs direct action. There is a fifth domain: disorder. You are in
this domain when it is not clear which of the other four domains best describes the current situation.
People’s experience, as described above, will often lead them to believe that they are in the domain in
which they feel most comfortable.

4. IT service management
Many people working in IT service management are used to designing and following processes. ITIL®
v3 guidance describes people, process, product and partners as the four major parts that IT service
management is built on. However, process is often the primary focus. This correlated with the common
mindset that change to an information system is likely to adversely affect its stability. Change therefore
had to be highly controlled, and process is a great tool to control. The premise is that information systems
should fail as infrequently as possible, with Mean Time Between Failures (MTBF) as a metric to monitor
how well this being achieved.

There is nothing wrong with control. As long as what you are trying to control is controllable, or in other
words: predictable. And as long as you are happy paying for control. The cost of control is usually effort
and delay. Effort always costs money, and delay usually does. In the past decade or so, a couple of things
have changed. Demand and complexity. These changes, highly relevant in the digital enterprise, have
influenced how we should think about IT service management.

4.1. DEMAND
Every generation seems to say that life is happening faster than it used to. We need to act quicker. If it
involves taking risks, we should take risks. Playing it safe is riskier. Not only do we need to deliver our
products quicker, their quality also needs to improve. People are placing higher demands on what we do
and how we do it. Just consider your own experience and expectations when dealing with a
digital enterprise.

4.2. COMPLEXITY
In the past, information systems were pretty much self-contained. The hardware and software were in
one room. There were few dependencies on external factors. When things went wrong, we debugged the
system and found out what went wrong. Then we fixed it. There was causality. The mantra was
If-Then-Else.

Now we construct our information systems with building blocks from various sources, most of which we
can’t influence, let alone control. The cloud provider provides the cloud that they want to provide. You can
take it or leave it. We take it. It is convenient. The operating system provides the operating system that they
want to provide. You can take it or leave it. We take it. It is convenient.

4 ITIL® 4 and DevOps AXELOS.COM

The price for this convenience is unpredictability. There are so many interacting and constantly changing
components that it is impossible to predict and therefore guarantee how things will work. The only thing
that we can predict, is that things will go wrong. And they do. We have to live with this uncertainty. The
new mantra is ‘If-Then-Maybe’.

This has changed how we think about IT service management. We no longer try to build fail-safe
information systems. We build them so that they are safe-to-fail and quick to recover. The emphasis has
shifted from Mean Time Between Failures (MTBF) to Mean Time To Recovery (MTTR).

5. Digital enterprise and transformation

We hear people talking about the digital enterprise and digital transformation, but what are they actually
talking about? The terms are poorly defined and loosely used, but here is a definition that some people
agree with.

We talk about a digital enterprise in organisations where IT is significant for their business model.
Technology makes it possible to do different business and do business differently. This often results in IT
becoming an integral part of the enterprise’s products and it is usually part of the channels through which
customer and enterprise interact. For example, a digital enterprise is also one that makes strategic use of IT
to automate the way it manufactures non-digital products that are sold and supported through non-digital
channels. When is the use of IT significant enough to be called “strategic”? If IT is on the board’s agenda. If
it is not, they probably think they have more important things to do.

Digital transformation refers to major change (the definition of transformation) to how a business uses IT
to do different business and do business differently. It is not about major change to how IT services are
provided: that is IT transformation. These two concepts, digital transformation and IT transformation, are
often linked. When digital transformation places higher demands on IT, IT transformation may be needed.
But they are two distinct activities.

Because ITIL and DevOps are primarily for the IT service provider rather than the IT service consumer, they
are concerned with IT transformation rather than digital transformation. But digital transformation often
leads to higher demand and increased complexity, which triggers IT transformation to a radically different
way of working.

AXELOS.COM ITIL® 4 and DevOps 5

6. ITIL’s guiding principles
In 2015, AXELOS published nine Guiding Principles to help practitioners apply ITIL guidance in a
more balanced and effective way rather than just blindly ‘implement’ processes, a misinterpreted but
understandable approach. In ITIL® Foundation, the nine guiding principles have been reduced to seven.
This is mostly a combination of closely related principles and some refinement.

The last principle, Optimize and automate, is worth examination. It builds on the central theme of continual
improvement and advises “to make something as effective and useful as it needs to be”, using automation
where possible and reasonable. As a result it encourages the reader to strike a balance between needs and
available resources. This applies to all of ITIL best practice: you should not blindly follow the examples
in ITIL. It is about taking the time to think for yourself and finding the best solution. And then taking
responsibility for the decision!

The guiding principles are:

zz Focus on value: Everything that the organization does needs to map, directly or indirectly, to value
for the stakeholders. The focus on value principle encompasses many perspectives, including the
experience of customers and users.
zz Start where you are: Do not start from scratch and build something new without considering what is
already available to be leveraged. There is likely to be a great deal in the current services, processes,
programmes, projects and people that can be used to create the desired outcome. The current state
should be investigated and observed directly to make sure it is fully understood.
zz Progress iteratively with feedback: Do not attempt to do everything at once. Even huge projects must be
accomplished iteratively. By organizing work into smaller, manageable sections that can be executed and
completed in a timely manner, it is easier to maintain a sharper focus on each effort. Using feedback
before, throughout and after each iteration will ensure that actions are focused and appropriate, even if
circumstances should change.
zz Collaborate and promote visibility: Working together across boundaries produces results that have greater
buy-in, more relevance to objectives and better likelihood of long-term success. Achieving objectives
requires information, understanding and trust. Work and consequences should be made visible, hidden
agendas should be avoided and information should be shared to the greatest degree possible.
zz Think and work holistically: No service, or element used to provide a service, stands alone. The
outcomes achieved by the service provider and service consumer will suffer unless the organization
works on the service as a whole, not just on its parts. Results are delivered to internal and external
customers through the effective and efficient management and dynamic integration of information,
technology, organization, people, practices, partners and agreements, which should all be coordinated to
provide a defined value.
zz Keep it simple and practical: If a process, service, action or metric provides no value, or produces no
useful outcome, eliminate it. In a process or procedure, use the minimum number of steps necessary
to accomplish the objective(s). Always use outcome-based thinking to produce practical solutions that
deliver results.
zz optimize and automate: Resources of all types, particularly human resources (HR), should be used to
their best effect. Eliminate anything that is wasteful and use technology to achieve whatever it is capable
of. Human intervention should only happen where it really contributes value.

Many of these principles address how to manage IT services in the complex and unpredictable digital
enterprise. In particular start where you are, work holistically, progress iteratively and observe directly.

These principles inform “the way we do things around here” or in other words: the culture.

06 ITIL® 4 and DevOps AXELOS.COM

7. DevOps’ generative culture
DevOps is a hard to define set of cultural norms, principles, technical practices and tooling. It enables fast,
frequent and reliable delivery of software while at the same time providing resilient operational IT services.
It also fosters a healthy IT workforce.

DevOps is often described in terms of culture, automation, lean, measurement and sharing (CALMS).
Automation (for instance of deployment pipelines) is often of great interest and value, however it is culture
that is widely acknowledged as the most significant, and the most difficult to change.

The DevOps community has embraced the work of sociologist Ron Westrum1. Westrum proposes three
kinds of organizational culture: pathological, bureaucratic and generative. The latter is regarded as the most
desirable:

zz Pathological cultures are power-oriented and focus on the personal interests and resources of the
leadership. Information is processed in a way to benefit certain parties within the organization rather
than the whole organization.
zz Bureaucratic cultures are rule-oriented and focus on using standard procedures to process information
throughout the organization. This works in theory but falls short when real-life issues occur.
zz Generative cultures are performance-oriented and tend to be more proactive, focusing on getting the
information to the right people in any way needed. Leaders emphasise achieving organizations goals and
missions, not personal benefits. In generative cultures:
zz information is actively sought rather than ignored (bureaucratic culture) or hidden (pathological
culture)
zz messengers are trained rather than tolerated or ‘shot’ (from the expression ‘don’t shoot the messenger’)
zz responsibilities are shared rather than compartmented or shirked
zz bridging between teams is rewarded rather than allowed or discouraged
zz failure causes enquiry rather than just and merciful treatment, or covering up
zz new ideas are welcomed rather than crushed.

8. Mental models
The characteristics of the desired generative cultures in the ITIL and DevOps communities are, at first
glance, compatible. “Generative” can just as easily be applied to ITIL’s guiding principles. Yet mindsets
often differ. Mindsets, that often represent commonly held beliefs, are very much part of the culture. Take
for example the model about how change affects the stability of an information system, as mentioned in the
IT service management section.

Many IT service management practitioners believe that change disrupts stability, and that stability controls
change. The fewer the changes, the lower the risk to stability. And vice versa, the more controlled the
system, the more difficult it is to change. This is the traditional IT service management perspective: “less
change is good”.

But there is another way of looking at this, one that is very common in DevOps communities. By reducing
the size of change, you reduce the risk of disruption. When you have smaller changes, you have more of
them, so change happens more frequently. The more frequently you change, the better you are at it. In
other words, the organization’s change capability has improved. The increased change capability leads,
in turn, to lower risk of disruption. The model has suddenly shifted from “less change is good” to “more
change is good”. The new mindset changes the organisational culture.

1 A typology of organisation culture, BMJ Quality & Safety 13, no. 2, 2004

AXELOS.COM ITIL® 4 and DevOps 07

9. Learning by experimenting
This change in model is supported by three of the ITIL guiding principles: start where you are, progress
iteratively with feedback, and think and work holistically. Start where you are and observe the current
metrics regarding speed, frequency and reliability of delivery. Progress iteratively with feedback by
experimenting with breaking large changes down into smaller, more frequent changes. Think and work
holistically by observing how the experiment affects other parts of the system.

There may be an initial dip in performance due to the learning curve, but in time results should improve. If
not, or if the improvement is not enough, another experiment is needed. The value of this approach is that
usable increments of functionality are provided quicker than having to wait for the whole large change. In
economic terms, the cost of delay is reduced.

This approach is consistent with the Third Way of DevOps, creating a culture that fosters two things:

1.continual experimentation, which requires taking risks and learning from success and failure
2.and the understanding that repetition and practice are the prerequisites of mastery.
This is an example of how open-minded practitioners can achieve cultural change by experimentation. The
new insights allow them to re-assess and revise their way of thinking and doing. Changing the culture,
slowly but surely. Initially, the change will be restricted to “how our team does things around here” but if it
proves valuable enough other teams will follow.

10. More than culture

In addition to the strong cultural foundations that can be applied across the whole area of IT service
management, DevOps also offers specific guidance in the areas of product and process, architecture,
continuous delivery, and lean management and monitoring. This guidance, often in the form of technical
practices, often adds another valuable dimension to ITIL guidance. Particularly when IT services are
managed in a complex and unpredictable environment.

ITIL guidance has more detail across a broader scope of activities than DevOps’ technical practices. Much
of ITIL’s guidance is presented in the form of practices that describe a set of value streams and processes,
people and organization, partners and suppliers, and information and technology that interact dynamically
according to circumstances. These are examples that should be tailored according to the guiding principle
keep it simple and practical. In complex and unpredictable environments, following predetermined
practices is by definition inappropriate. The ITIL practices (in particular the processes) can be used to
describe possible patterns of behaviour that may or may not occur. It is up to the practitioners to use their
experience and judgement and deviate as appropriate.

08 ITIL® 4 and DevOps AXELOS.COM

11. Summary
Culture is “how we do things around here”. We do things differently in the digital enterprise, so we need
cultural change. Part of the challenge of “digital” is dealing with increasingly complex and unpredictable
systems. The mantra has changed from If-Then-Else to If-Then-Maybe. Rigidly following predetermined
processes does not work. Do the right thing right, not the wrong thing right. Practitioners have to be ready,
willing and able to act on the fly. ITIL guidance, in particular the Guiding Principles, combines well with
DevOps guidance in creating a culture that fosters continual experimentation and the understanding that
repetition and practice are the prerequisites of mastery.

12 About the author

Mark Smalley, also known as The IT Paradigmologist, thinks, writes and
speaks extensively about IT ‘paradigms’ – in other words our changing per-
spectives on IT. His current interests are the digital enterprise, IT operating
models, value of IT, business-IT relationships, co-creation of value, multi-
disciplinary collaboration, working with complexity, and as the overarching
theme, management of information systems in general. People collaborate
with Mark to discover where they are and to visualize where they want
to be. Mark is a Trainer/Consultant at Smalley.IT and Master Trainer for
GamingWorks’ The Phoenix Project DevOps business simulation. He is
Global Ambassador at the DevOps Agile Skills Association (DASA). Mark
has contributed to various bodies of knowledge, the most recent one being
ITIL 4. He has lectured at various universities and has spoken at hundreds
of events in more than twenty countries.

AXELOS.COM ITIL® 4 and DevOps 09

13. About AXELOS
AXELOS is a joint venture company co-owned by the UK Government’s Cabinet Office and
Capita plc.

It is responsible for developing, enhancing and promoting a number of best practice

methodologies used globally by professionals working primarily in project, programme and
portfolio management, IT service management and cyber resilience.

The methodologies, including ITIL®, PRINCE2®, PRINCE2 Agile®, MSP®, RESILIA® and its
newest addition AgileSHIFT® are adopted in more than 150 countries to improve employees’
skills, knowledge and competence in order to make both individuals and organizations work
more effectively. 

In addition to globally recognized qualifications, AXELOS equips professionals with a wide

range of content, templates and toolkits through the CPD aligned My AXELOS and our online
community of practitioners and experts.

Visit www.AXELOS.com for the latest news about how AXELOS is ‘Making organizations
more effective’ and registration details to join AXELOS’ online community. If you have specific
queries, requests or would like to be added to the AXELOS mailing list please contact
[email protected].

14. Trade marks and statements

AXELOS®, the AXELOS swirl logo®, ITIL®, PRINCE2®, PRINCE2 Agile®, MSP®, M_o_R®,
P3M3®, P3O®, MoP®, MoV®, RESILIA® are registered trade marks of AXELOS Limited.
AgileSHIFT® is a trade mark of AXELOS Limited. All rights reserved.

Copyright © AXELOS Limited 2019.

Cover Image: ©Getty/Jenner Images

Reuse of any content in this Discussion Paper is permitted solely in accordance with the
permission terms at https://www.axelos.com/policies/legal/permitted-use-of-white-papers-and-
case-studies

A copy of these terms can be provided on application to AXELOS at [email protected]

Our Discussion Paper series should not be taken as constituting advice of any sort and no
liability is accepted for any loss resulting from or use of or reliance on its content. While every
effort is made to ensure the accuracy and reliability of information, AXELOS cannot accept
responsibility for errors, omissions or inaccuracies. Content, diagrams, logos and jackets are
correct at time of going to press but may be subject to change without notice.

Sourced and published on www.AXELOS.com

AXELOS.COM ITIL® 4 and DevOps 10