In this chapter, we will discuss different delivery models that are defining agile ways of working and that are also introducing new roles into the system. The topics that will be covered in this chapter are as follows:
As ITSM has evolved, there arose a need to complement rapid digitization and emerging needs. Organizations identified gaps that needed attention such as fragmented ITSM tools, limited standardization, etc., and looked at alternates to ITSM. While classic ITSM was well accepted by many organizations, there was a growing need for agility. Organizations looked for guidance to run their Service Delivery phase effectively in an agile way. This gave birth to agile ITSM, which borrowed some of the importan principles of agile and constructed a methodology that stressed streamlining, optimization, and integrations. Organizations adopting agile principles found it easy to link up with various ITIL stages and use this new agile ITSM way of working.
Agile ITSM = Agile software development + ITSM
If agile talks about “working software,” then ITIL stresses “focus on value.” Hence, organizations are finding it easy to gel both agile and ITIL principles. As shown in Figure, an agile methodology like Scrum was tied to different phases in ITIL. While the product vision is mapped with the Service Strategy phase, the actual Scrum process starts with the Service Design phase where user stories requirements are recorded and prioritized in a backlog. The Service Transition phase has the sprints in a time-boxed schedule. The final phase is Service Operations, where the product is deployed through approved requests for change (RFCs).
The only concern initially with this approach was that agile focused on iterations and ITIL executed in a sequential manner. Organizations adopting agile ITSM found a way out from this too. They motivated teams to work with a DevOps mindset that always targeted stability and agility. The infrastructure operations team is involved in the Service Design phase and provides all the necessary inputs that are needed for the warranty requirements. If ITSM revolved around stringent release and change management to control change, this agile ITSM was tackled by deciding on the amount and frequency of change control needed. This change control often is led by the product owner to manage the product as well as the sprint backlogs. In fact, it is the product owner who approves the CAB requests since the product owner manages the sprint backlog. The agile ITSM method is a success since it ties the best practices of both ITIL and agile worlds, driven by a DevOps mindset. The associated roles in both methods also converged. For example, the roles of a product owner in the Scrum methodology and the service owner in ITIL were merged since the expectation from both roles was to be the voice of the customer.
IT4IT is a reference architecture that illustrates an operating model for managing IT. It is a powerful modern tool that helps organizations to manage their digital journey. This standard is being accepted and implemented by organizations of varied sizes with a key focus on driving interoperability, improving existing capabilities, and rationalizing applications. The standard also means to solve issues such as slow and manual activities linked with code management, packaging, deployment, and configuration management. (The IT4IT framework and its value streams come from https://www.opengroup.org/it4it, and IT4IT is a trademark of the Open Group.) The framework comprises four value streams that iteratively operate to deliver value and measures to improve, as shown in Figure
Strategy to Portfolio (S2): Interconnects different functions that are involved in managing a portfolio of services delivered to fulfill an enterprise strategy. This value stream allows IT to contribute to enterprise strategy and planning. It also provides a holistic view on IT portfolio activities to understand the relationships between all the teams under the IT umbrella. It also comprises key functional and auxiliary components that drive the key activities.
Requirement to Deploy (R2D): Controls the quality, schedule, and cost of services regardless of delivery model. The idea behind this value stream is to accelerate sourcing and service delivery with best practices. Successful R2D is possible through a clear definition on scope, service blueprints, policies, and problem statements. Like S2P, R2D also has various functional components that process and deploy data objects.
Request to Fulfill (R2F): Emphasizes time to value, repeatability, and consistency for customers needing IT service support. It focuses on the relevance of deploying standard changes rather than delivering normal or custom changes. It helps organizations move toward a service broker model. It primarily focuses on system of record integrations between the functional components.
Detect to Correct (D2C): Increases efficiency, reduces cost and risk, and drives continuous improvements. This is achieved through automation, self-service, faster time to market, reducing MTTR, defining clear ownership, and improved management. A key goal of D2C is to manage IT efficiently by monitoring and automating key services, correlating, and managing incidents or events effectively and quickly.
