ITIL® 4 and DevOps A cultural perspective Mark Smalley

Discussion paperMarch 2019

ITIL® 4 and DevOps

A cultural perspective

Mark Smalley

Contents1 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

ITIL® 4 and DevOps 03AXELOS.COM

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

z deep-rooted values that hardly ever change z habitual thought-patterns that sometimes change with new insights z 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 hereIn 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. ProcessIf, 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. AnalyseImagine 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. ExperimentPretend 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. DictateYour 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.


3. Complexity thinkingIf 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 managementMany 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. DEMANDEvery 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. COMPLEXITYIn 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.


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 transformationWe 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.


6. ITIL’s guiding principlesIn 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:

z 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.

z 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.

z 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.

z 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.

z 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.

z 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.

z 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.


7. DevOps’ generative cultureDevOps 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:

z 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.

z 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.

z 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: z information is actively sought rather than ignored (bureaucratic culture) or hidden (pathological culture)

z messengers are trained rather than tolerated or ‘shot’ (from the expression ‘don’t shoot the messenger’) z responsibilities are shared rather than compartmented or shirked z bridging between teams is rewarded rather than allowed or discouraged z failure causes enquiry rather than just and merciful treatment, or covering up z new ideas are welcomed rather than crushed.

8. Mental modelsThe 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


9. Learning by experimentingThis 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 failure2.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 cultureIn 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.


11. SummaryCulture 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 authorMark 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.

13. About AXELOSAXELOS 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 statementsAXELOS®, 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


ITIL® 4 and DevOps A cultural perspective Mark Smalley

Documents

Transcript of ITIL® 4 and DevOps A cultural perspective Mark Smalley