Sign in

Shift-left: Move closer to the source with ITIL and DevOps White Paper

White Paper

Shift-left: Move closer to the source with ITIL and DevOps White Paper

White Paper

  • White Paper
  • Behaviour
  • Customer engagement
  • Customer needs
  • DevOps
  • Processes
  • Service management
  • Value
  • ITIL

Author  Barclay Rae

February 26, 2020 |

 12 min read

  • White Paper
  • Behaviour
  • Customer engagement
  • Customer needs
  • DevOps
  • Processes
  • Service management
  • Value
  • ITIL

As models, standards, and frameworks continue to proliferate, it often takes the emergence of a hybrid buzzword to create a common understanding and collaboration around best practice. The IT world thrives on the brief lives of such terms. It includes terms such as BPR, client-server, hybrid cloud, digital transformation, orchestration, and many others that are often used interchangeably and have multiple definitions.

Shift-left is a buzzword that is now frequently used. This term is valuable as it is often open to multiple levels of understanding and application.

Shift-left approach
An approach to managing work that focuses on moving activities closer to the source of the work, in order to avoid potentially expensive delays or escalations. In a software development context, a shift-left approach might be characterized by moving testing activities closer to (or integrated with) development activities. In a support context, a shift-left approach might be characterized by providing self-help tools to end-users.

The widely accepted definition is that shift-left involves moving the delivery of work to the most appropriate and optimum place to meet the customer or business needs. Usually this involves improving the quality, efficiency, and speed of the delivery of work to improve customer experience.

The transformation to a shift-left approach requires activities such as:

  • reviewing current practices and identifying issues
  • journey mapping to review and improve flow
  • gathering and building feedback and performance data
  • decision-making to drive shift left strategy
  • combining ITIL 4 practices into value streams
  • cross-functional team collaboration
  • changes in structure, roles, processes, practices, and tooling
  • organizational change management activities to get buy-in and to enable change
  • value demonstration of the benefits achieved.

Image of Figure 1.1 Shift Left diagram

Figure 1.1 Tiered support in a traditional support model

Shift-left means moving work to the best place for it to be done, often closer to the customer so it is faster, better, and cheaper. As a result, delays, issues, and costs that are often caused by existing operational structure and processes are removed . This results in a reduction in unnecessary delay, irritation, waste, and extra cost. A service desk team will require the smallest amount of time to fix an incident. If the service desk is not allowed or unable to resolve the incident, then this time may be increased by hours or days through the escalation process. Delays also add to the cost of delivery. For example, in a traditional support model many issues can be removed by simply moving the work to the right place. Yet, this is often far from simple . The effort required to succeed involves several skills, practices, and disciplines. In effect, shift-left represents the broad spectrum of IT and SM, ITIL, and DevOps in a microcosm, where there is a need to focus on people, structure, and culture as much as on tools, automation, processes, and practices.

Image of Figure 1.2 Shift left diagram

Figure 1.2 Shift-left support options
Note: KB in the figure above refers to knowledgebase.

The shift-left approach can similarly apply to development work, as both approaches require avoiding bottlenecks and gaps by reviewing the overall flow and making appropriate changes. ITIL 4 has a strong focus on shift-left, both in terms of how it can be deployed as an IT and service management artefact, and how this relates directly to approaches such as DevOps and Agile.

Shift-left, ITIL 4 and DevOps

DevOps focuses on several areas that are exemplified in the shift-left approach. Often, it is possible to inform traditional IT and SM teams that if they are attempting a shift-left delivery, then they are effectively using several DevOps techniques.

The areas that include an overlap between shift-left and DevOps techniques are:

  • flow shift-left involves the optimization of workflow across a value stream (i .e. an end-to-end combination of processes and practices)
  • feedback this is used to identify customer and operational issues that can be improved
  • customer focus a central element in journey mapping and service design
  • results and measurement used extensively in DevOps to identify improvements in quality and performance
  • collaboration and respect getting small, cross-functional teams to work closely together and share their work and skills. Collaboration requires trust and mutual respect
  • automation and optimization used extensively in DevOps for testing, promoting code, and provisioning. Shift-left highlights many new opportunities to automate IT and SM processes to focus on quality and accelerate responses to customers.

ITIL 4 refers to shift-left, highlighting the key professional requirements and tools needed for successfully implementing service management, that is holistic and incorporates a broad set of disciplines. This includes value stream creation and delivery, which effectively is what shift-left involves. This is defined in ITIL 4 Specialist: Create, deliver and support (CDS) . CDS also includes several broad areas for consideration and development, which surpasses processes and even practices as key to developing a balanced approach to professionalism.

To be successful at creating value streams it is important to use a combination of practices and skills, including the elements of teamwork, collaboration, and cooperation if required. Success also requires an understanding of the different approaches to organizational structure and cultural change. It is important to be aware of tools and current developments to keep skills up to date and to identify opportunities to provide new solutions for customers.

There is also a strong focus on employee satisfaction and developing customer orientation in all aspects of service management, as well as a refocus on communications skills. These capabilities are essential for tasks such as receiving approval for initiatives, such as shift-left.

Most importantly , the guiding principles in ITIL 4 reflect a modern, flexible, and context-based way of working. These are closely aligned with the Agile and DevOps ways of working and can be traced to key concepts such as transparency, flexibility, using feedback loops, working holistically and with a customer experience focus, using automation as much as possible; and using a Lean approach to remove waste by keeping things simple. The guiding principles can be used as a guide to successful shift-left implementation. For example, both approaches encourage holistic, iterative, and inclusive work, focusing on customer and business value, using automation where appropriate, and improving collaboration by using a Lean approach.

Delivering Shift-Left

Shift-left is not an individual process, value stream or practice. Neither is it a technology or a training programme, organizational change, customer focus, continual improvement, efficiency drive or quality management system. It is not IT and SM, ITIL, DevOps or Agile. Shift-left incorporates all of these elements mentioned above to create a holistic transformation approach, which embraces several ways of working and combining elements from IT and SM and DevOps.


3.1.1 Reviewing and identifying areas for improvement

This involves reviewing the workflow of specific value streams and identifying areas for improvement, such as: customer experience, speed, efficiency, employee engagement, and business value. This could be achieved by reviewing how and where defects are classified and resolved. For instance, allocating the early investigation of bugs to the design and build teams, or using testing feedback to redefine the scope and acceptance criteria for workstreams. As a result of the change in working practices, this may improve the quality of product delivery and reduce the impact of rework. This could also include moving the resolution of incidents from third line analysts to front line service desk agents, which could result in a reduction in: lead times for customers, impact on projects, cost of services, and improving the job satisfaction levels for service desk and third level people.

3.1.2 Agreeing on a plan of action

This step would require visible management support, probably investment in areas such as training, salary adjustments, and tools and organizational change management. It is important that all risks, issues, and potential outcomes are considered as part of the decision-making and planning for change. Some issues to consider are:

  • Fear and resistance from people in current roles. How will their job change, what skills are needed? Will their job still exist? Will they gain or lose perceived status or responsibilities?
  • The ability to make structural changes as needed. Some job descriptions and responsibilities will need to be changed which may have financial implications.
  • Teams will need to agree on new interdepartmental communications processes, such as how to triage and escalate work (for example requests, defects, and incidents) . New categories and escalation procedures could be created to reflect these changes.
  • A major area for attention will be knowledge management, which is the creation of appropriate content that provides relevant knowledge and practical guidance when needed.
  • Knowledge transfer will be required on a cross departmental basis to move tasks seamlessly from one area and group of people to another. This can require retraining, the creation of new knowledge articles, buddying, and mentoring.
  • Successful knowledge transfer usually benefits from target setting to drive change. For example, this could involve setting targets for the number of resolution incidents or knowledge articles that third level teams need to transfer every month, or the percentage of defects that are transferred from testing, to coding, and design teams.
3.1.3 Initiating and implementing shift-left

This involves engaging and preparing all stakeholders, colleagues, and partners for the required changes, identifying what this means for them, and their part in it. This step also requires making the relevant process, role, structural, and tooling changes. This involves:

  • The reasons for changing value propositions and content. What are we doing? Why are we doing this? What will the benefits and outcomes be? Why is this better for the organization and its people?
  • The change involves consulting with and selling the changing to employees. Stakeholders must embrace the change. Yet, time and effort is required to build the stakeholder 's trust so that they understand the reasons for change, as well as the mechanisms involved in the change.
  • The change will require the development of the employees' skills and capabilities so that they can deliver the work that is moved to their area. This may be challenging for certain employees and can result in the need to employ different skillsets (and employees) in existing roles.
  • The removal or change of the restrictions on access can result in fewer delays and the quicker delivery of work.
3.1.4 Reviewing and demonstrating value from shift-left

The success and value of the change can be demonstrated by measuring and reporting certain areas such as:

  • Work transfer targets are vital for implementing activities that move items of work, train employees , and so on. For example, it can be useful to track the number of knowledge articles, defects, or incident types that each team disregards every month.
  • The success of the initiative can be demonstrated by identifying its value. This could be shown by reporting improved resolution times, reduced defect numbers, increased customer satisfaction ratings, lower costs, and so on.
  • Value can also be identified by tracking progress and reporting any positive changes, that have arisen as a result of the change to employees and customers.
  • Shift left is also valuable for employee satisfaction, providing more direct customer resolution to front line staff, as well as freeing up technical staff to do more project-based work. This can also improve job satisfaction and engagement across teams.


Clearly, shift -left requires a coordinated effort involving skills, people, teams, managers, and stakeholders. This is a multifaceted initiative that will fail without a holistic and inclusive approach. Challenges can arise that threaten the success of the shift-left initiative, some of these challenges are discussed below. The resistance and unwillingness to delegate or transfer work. Many people feel threatened by changes to their roles and responsibilities. This is particularly true if they are perceived as experts and believe that they must convey their knowledge to less experienced people. This approach can be seen as a challenge to their expertise and authority. It is vital to gain their trust by emphasizing the opportunities for them, the benefits to the organization, and the benefits to their customers. Often the problem of resistance manifests indirectly through a lack of priority and slow progress. Target setting for skills transfer is a useful approach here.

Another problem is moving work to teams that do not possess the necessary skills or knowledge. Clearly, this will not work and the team will either require extra training or the nature of the team itself may need to be reviewed.

A third issue is unusable knowledge materials. Knowledge can be transferred but this must include a contextual understanding of the user. For example, a technician's notes may be too technical for a front line analyst.

Another problem is a lack of clarity within roles and the escalation process. Many teams operate with unwritten processes and practices, so it is vital to have written instructions of how these processes operate in a new context.

Also, knowledge systems and articles must be tested and tracked for use and quality. Employees must be able to teach themselves the necessary knowledge, using the knowledge systems and content available to them. Yet, this can only be done if the organization can identify the most successful forms of knowledge content that they have, or that they need to create.

Summary of Key Tips

  • Good collaboration and buy-in is key, as well as a focus on the expected business value and the value for employees.
  • Use organizational change management techniques to gain employees' trust and manage the change with them.
  • Transparency and visible working help to clarify objectives and progress.
  • Use common sense to drive sensible customer focused solutions . Discard transactional and rigid ways of working when they clearly do not work. There is no absolute model for shift-left, move work to where it makes sense.
  • Experiment with new structural models for routing and escalating work, such as swarming .
  • This should ideally form part of a wider shift towards a continual improvement culture.
  • Metrics, such as target-setting, measurement, analysis, and publication of results and outcomes are key to building credibility, support, and the ongoing demonstration of value.

About the author

Barclay has been working within the service management industry since 1994. He works as a consultant, analyst, auditor, and writer for a variety of industrial organizations, and is a board member of itSMF UK. He is the co-author of ITIL® Practitioner Guidance and ITIL Foundation: ITIL 4 Edition; co-author of the SOi's world-class service desk standards; and a contributor to ISO/IEC 20000. He created the ITSM Goodness model in 2013 and is a regular presenter at global industry conferences and events.

Barclay's work mostly involves delivering practical guidance and strategic consultancy to service delivery organizations. As a business owner he is also involved in developing new businesses and fixing established ones. Before IT and consultancy work, he was a musician: performing, writing, and recording his own work.

Author Barclay Rae

Shift-left: Move closer to the source with ITIL and DevOps