Keywords

1 Introduction

Organizations delivering it services often apply an it service management (itsm) framework. It describes how to manage quality it services that meet the business needs “through an appropriate mix of people, process and information technology” [1]. In this paper, we refer to itil, which is often considered as the most used itsm framework.

Besides the management of the organizational processes, it organizations also have to manage their projects. Some of them consist of implementing software. In recent years, these kinds of projects are more and more often managed thanks to agile methods. This means that they respect the agile manifesto and its twelve principles [2]. Taken as a whole, agile corresponds to “the continual readiness of an information systems development method to rapidly or inherently create change, proactively or reactively embrace change, and learn from change while contributing to perceived customer value [...], through its collective components and relationships with its environment” [3]. There are several agile methods: eXtreme Programming (xp) [4], scrum [5] and Feature-Driven Development [6], to name a few of them. Each adheres more or less strongly to the agile manifesto and principles. Presently, scrum is the most popular agile method in the it industry [7]; this justifies its use in the scope of this paper.

If we compare agile methods and itil v.3 from a conceptual and structural point of view, they could not be more different. Agile methods are seen as loose and very flexible, while itil is rather considered as bureaucratic and procedural. However, they share a common objective: both of them aim at providing business value to its customers and users. As first and main principle, the agile manifesto states that its “highest priority is to satisfy the customer through early and continuous delivery of valuable software” [2]; itil v.3 “is adopted by organizations to enable them to deliver value for customers through it services” [8]. However, the way of doing is very dissimilar. The former provides value by quickly implementing what customers and users really want, while the latter provides value by delivering stable it services respecting the negotiated set of functionalities and the quality levels. The agile manifesto favours informal interactions between the project stakeholders as opposed to a high formalism, which is advocated by itil v.3. Therefore, the following research issue is naturally raised.

How can itil v.3 and agile project management coexist in an it organization?

Contributions. In this paper, we analyse the itil v.3 best practices by focussing on the relations between them and the structure of software project management methods. We conclude that itil favours methods which are based on the Waterfall life cycle or, at least, methods which recommend a full software design before its implementation. Based on four recommendations in order to adapt itil v.3 to the principles of the agile manifesto, we discuss the alignment of scrum and itil v.3. We identify, define and justify eight interfaces between them, as well as the modifications to the itil v.3 life cycle in order to enable agile project management. This work aims at helping people wishing to follow the itil v.3 best practices associated with scrum in their it organizations.

Organization. First, we present itil v.3, its point of view on software project management, and scrum (Sect. 2). Then, in Sect. 3, we describe the relations between itil v.3 and scrum while emphasizing the adaptations to itil v.3. Finally, after the related work (Sect. 4), the conclusion and some directions for future research are discussed (Sect. 5).

2 Presentation and Discussion of the Reference Frameworks

In this section, we describe the two main references used, namely itil v.3 (Sect. 2.1) and scrum (Sect. 2.4). In Sect. 2.2, we describe the relations between the relevant itil processes and the project management structure advocated by itil. In Sect. 2.3, we make four recommendations in order to adapt itil v.3 to an agile project management method.

Fig. 1.
figure 1

itil v.3 life cycle (based on an official illustration of itil [9])

Full size image

2.1 A Short Description of ITIL V.3

itil is a collection of itsm best practices which requires to focus on the customers and users and, more specifically, on the value that they get by using it services [10]. A recent empirical study [11] demonstrates that itil strongly helps companies delivering it services to improve their processes and to increase their benefits. itil Footnote 1 v.3 is structured into five phases, each being composed of processes. An itil process is defined as “a structured set of activities designed to accomplish a specific objective. A process takes one or more defined inputs and turns them into defined outputs” [9]. These five itil v.3 phases along with their processes are depicted in Fig. 1 and described below.

  • Service Strategy: This phase aims at guiding the whole it service creation and delivery strategy through an effective management of its life cycle. Topics covered are mainly the creation and management of the it strategy, the analysis and the development of the markets (including the internal customers), the feasibility analysis related to the conception of it services and the financial management [9].

  • Service Design: This phase provides the guidance for the conception of services and their future management [1]. The conception lies in defining how the organization assets will be transformed to bring value to customers through the use of the future it services. This phase also defines how to improve the existing it services.

  • Service Transition: This phase explains how to organize the implementation of the designed services and how to manage the changes applied in existing services [12].

  • Service Operation: This phase focuses on the delivery and support of it services [13].

  • Continual Service Improvement: This phase aims at maintaining and improving the value delivered by it services to its users and customers through the measurement and the analysis of the service solutions and the processes followed [14].

2.2 ITIL V.3 Viewpoint On, and Relations With, Project Management

itil defines the notion of project as “a temporary organization, with people and other assets, that is required to achieve an objective or other outcome. Each project has a lifecycle that typically includes initiation, planning, execution, and closure” [12, p. 324]. This definition is very similar to the ones proposed in the pmbok [15] or in other related references (e.g., [16, 17]). The notion of Project Management Office (pmo) is another important notion in the scope of this work. From the itil point of view, the purpose of the pmo is “to define and maintain the service provider’s project management standards and to provide overall resources and management of it projects” [1, p. 254]. Actually, it is a combination of two processes, namely, Design coordination and Transition planning and support. The former focuses on the creation of the service design package while the latter focuses on the effective implementation of it services and of their modifications. A quick look to the pmbok indicates that this notion is similarly understood: a pmo is “a management structure that standardizes the project-related governance processes and facilitates the sharing of resources, methodologies, tools, and techniques” [15, p. 10].

Concerning the project management, itil suggests to combine its best practices with a methodology such as prince2 or pmbok [12, p. 324]. Although itil aims at managing the whole life cycle of an it service, the projects leading to the effective creation or modifications of it services are not directly managed through the itil processes. This is consistent with the project notion; the pmbok explains that “a project is a temporary endeavor undertaken to create a unique product, serviceFootnote 2 or result” [15]. Actually, itil supports this creation by, e.g., providing information, but it not directly manages projects. In the itil Service Design book [1, Sect. 3.11.3], the project management in an iterative, incremental and/or adaptive life cycle is briefly discussed. The Rapid Application Development (rad)Footnote 3 [18] and xp [4] methods are mentioned. However, there is no explanation concerning the way for combining one of these two methods with itil. The structure of the itil v.3 processes, as illustrated by the left side of Fig. 2, does not fit with agile methods. Indeed, this structure corresponds to a Waterfall life cycle, also called “conventional development” in the itil literature: the requirements are elicited, then the system-to-be is specified, which leads to its implementation and, lastly, to its testing and deployment. This is illustrated by Fig. 2 and discussed hereafter. The legend of Fig. 2 is available in Table 1, and is also applicable to Figs. 3 and 4.

Fig. 2.
figure 2

Relations between the itil v.3 processes and the Waterfall life cycle

Full size image
Table 1. Legend applicable to Figs. 2, 3 and 4
Full size table

Description of the IT Service Implementation Flow. The left side of Fig. 2 depicts the itil processes and relations when a new it service is created or when an existing it service is reworked. As a reminder, these processes are mentioned in Fig. 1 within their belonging phase. There are two possible starts. The first one lies in a customer request managed by the Business relationship management process; the second one is a positive decision concerning an it service improvement proposal. In both cases, the main starting process is Service portfolio management. It receives the information provided by the other processes of the Service strategy phase. Its main output is a Service Charter, i.e., “a document that contains details of a new or changed service” [9, p. 452], which is sent to the service design phase. The latter has to support the creation of the Service design package. It is a (set of) “document(s) defining all aspects of an it service and its requirements through each stage of its lifecycle[, which] is produced for each new it service, major change or it service retirement” [1, p. 418]. At the organizational level, the design tasks are coordinated by Design coordination. The other processes are used to provide information about the expected service level and the four quality properties; these information exchanges are managed by Service level management.

Once created, the Service design package is transferred to Change management for its implementation, which is coordinated by Transition planning and support. The workflow is as follows. First, the Service design package is transformed into several requests for change, which is “a formal proposal for a change to be made [on a configuration item, which contains the] details of the proposed change” [1, p. 415]. Once authorized, they are grouped under a service release and, then, they are effectively implemented. Service validation and testing is in charge of validating the deployment of the service release. This leads to the Service operation phase, which is out of the scope of this paper.

The right side of Fig. 2 depicts the Waterfall model [19, 20], which is the main project life cycle model behind the structure of prince2 and of pmbok: these methods recommend to design first the software and, then, to implement it. That is, if the software specifications are sufficiently detailed after an in-depth requirements analysis, it will be coded such as. In this context, we consider the software engineering as a linear process with possible steps backward. The first steps focus on the requirements engineering and their specifications (see the right side of Fig. 2). Then, the specified software is coded and tested. The last step is the software deployment. One should move to the next step only when the previous step is achieved, although a step back is always possible in order to improve or to remake a previous output. However, returning to a former step often involves additional costs and delay. The lack of contact with the stakeholders is also a drawback often underlined when using this software engineering model.

In Fig. 2, the arrows with a double line illustrate the relations between the itil processes and the steps of the project management workflow. The first information transfer occurs when the service charter is communicated to the step Definition of the requirements, so that the software engineers can elicit the requirements and design the future software during, respectively, the steps Requirements analysis and Software design. This specification work is facilitated and supervised by the processes of the service design phase, coordinated by the Design coordination process. The next step, Software implementation, lies in the coding of the designed software by respecting the service release previously defined. This leads to its test through the step Software testing and, lastly, to its deployment through the step Software deployment.

2.3 ITIL Associated with an Agile Project Management Method: Recommendations

To be considered as agile, a project management method has to respect the agile manifesto [2] and have to be incremental, iterative and adaptable [21]. Based on the observations made in Sect. 2.2, we make four recommendations in order to associate itil with an agile project management method. Note that itil v.3 adaptations are allowed if we respect its main principles and ideas. Indeed, the itil content is not prescriptive, in the sense that it organizations are encouraged to adopt the main itsm principles and “to adapt [the best practices] to work in their specific environments in ways that meet their needs” [12, Sect. 1].

  1. 1.

    The Service design package has to be created incrementally along with the software implementation and testing.

  2. 2.

    The software development team should be able to modify the Service design package, and thus the requests for change, even when the implementation has already begun.

  3. 3.

    The phases Service design and Service transition have to be conducted in parallel.

  4. 4.

    Service managers have to progressively release their it services, on the same pace that the underlying software implementation is carried out.

Fig. 3.
figure 3

The scrum process framework (based on [5, 22, 23])

Full size image

2.4 An Introduction to SCRUM

scrum is an agile process framework for managing software development projects. It consists of roles, events, rules and artefacts [24]. Its main objectives are the transparency, the inspection and the adaptation during the software implementation [5, 24]. Figure 3 illustrates the scrum framework and its steps, which are described hereafterFootnote 4.

When a scrum project starts, the vision of the product, which corresponds to the future software to be created, is determined. The client and the scrum team have to write down how the future product is going to support the client’s organization strategy. This is the essence of the business value that will be got from the product use. In particular, this includes the definition of the targeted users and customers of the product, the main use situations addressed by the product, the business model, its “must-have” characteristics, its desired qualities and a comparison with the possible competing products [22]. Note that the scrum team is composed of (i) the product owner—s/he is in charge of the product backlog management—(ii) the scrum master—s/he is responsible for ensuring that the scrum team correctly follows the scrum philosophy and its rules, without any hierarchical relation—and (iii) the development team—the latter is composed of professionals who carry out the work leading to the product implementationFootnote 5. All scrum teams have to be self-organized and cross-functional.

The second scrum step is the feeding of the product backlog, which is a prioritized list of requirements. It is managed by the product owner. It is continually updated even after the start of the product development, hence the fact that scrum is an adaptive software project management method. Product backlog updates come from the customer or from the Sprint review (see further for a description of this scrum event). These updates include modifications, additions and removals of product backlog items.

Once the product backlog is defined and prioritized, a first Sprint may be organized. The dotted line in Fig. 3 represents its life cycle. This scrum iteration is a fixed period of time (about four weeks) during which a subset of the product backlog, called the Sprint backlog, is analyzed, designed, implemented and tested. A Sprint begins with its planning and ends with the Sprint review and, after that, the Sprint retrospective. The Sprint review is an inspection of the product increment created during the Sprint. This inspection is achieved by the customer and the product owner with the help of the development team. The second meeting, i.e., the Sprint retrospective, is held by the scrum team to inspect and to improve their way of working for the next Sprints.

After the Sprint review and the Sprint retrospective, the customer and the product owner decide if the product increment is deployed as a new product release, and thus made immediately usable. Then, the customer has to determine if the current version of the product meets his expectations, or if an additional Sprint is needed in order to integrate some more backlog items to the product and/or in order to improve it. The closing of the scrum project corresponds to, i.a., the creation of the documentation.

3 Coexistence of ITIL and SCRUM: Alignment and Description of the Interfaces

In this section, we describe the alignment between scrum and itil v.3 as well as all the interfaces between them through which information exchanges occur. In Table 2, we sum up these interfaces, which are numbered in Fig. 4. In this picture, we illustrate how to combine itil v.3 with scrum. The left part of Fig. 4 contains some differences compared to the left part of Fig. 2 illustrating the structure of itil v.3. These differences, detailed hereafter, are due to the recommendations made in Sect. 2.3. The right side of Fig. 4 is exactly the same than Fig. 3 illustrating the scrum method.

Fig. 4.
figure 4

Alignment of, and interfaces between, itil v.3 and scrum

Full size image

At the beginning, there is not difference compared to the traditional life cycle of itil v.3 detailed in Sects. 2.1 and 2.2: the Service strategy phase is covered as usual. Afterwards, there is a key difference in comparison with the traditional structure of itil v.3 (cf. Fig. 2). There is no more a direct relation with the phase Service design before the start of the software implementation projects. In other words, the Service charter is sufficient to start a scrum project. The Service charter document is used to establish the vision of the product in scrum (see Interface 1 in Fig. 4 and its summary in Table 2). Of course, it is also transferred to the next itil phase and, more precisely, to Service level management. This difference is explained by the fact that the service design will be progressively achieved along with the carrying out of SprintsFootnote 6.

Then, the product backlog has to be created and fed based on the Service charter and on the communication between the product owner and the identified stakeholders. For utility and quality considerations, information provided by Service level management should be used (e.g., service improvement opportunities, service quality plans, reports on operational level agreements and underpinning contracts, and so on [1, p. 121]). This is captured by Interface 2, which is referenced by its number in Fig. 4 and in Table 2. After the next scrum step, i.e., the Sprint planning, the first Sprint starts.

During a Sprint, the Sprint backlog is implemented; this includes the analysis, the design, the coding and the testing of the objective(s) introduced in the Sprint backlog. There are several information exchanges with itil processes during a Sprint. The first main concerns Design coordination (cf. Interface 3). Indeed, for analysis and design tasks achieved during the Sprints, this itil process coordinates the transfer of knowledge about the design of a service—or of a service modification—in order to reach the adequate service level. The second main information exchange involves Change management (cf. Interface 4). Indeed, the designed changes made during a Sprint have to be assessed and authorized by the Change Advisory Board (cab), which is “a group of people that support the assessment, prioritization, authorization and scheduling of changes” [12, p. 306]. In the context of our work, the scheduling of changes is automatically determined: the authorized changes are carried out during the current or the next Sprints. Similarly, it is not relevant to prioritize changes achieved during projects seeing that it is an itil artefact applied for operational changes.

A second key difference is the removal of the direct relation between Service level management and Change management, i.e., between the itil phases Service design and Service transition. In the common itil structure, the phase Service design ends with the completion of the Service design package, which is then transferred to the Change management process in order to be transformed into Requests for change. When associating itil v.3 with scrum, the activities of Service design and Service transition are conducted in parallel. The service design package is thus gradually created as the number of Sprints increases. As a reminder, one of the agile principles favors “working software over comprehensive documentation” [2], but this does not mean that there is no more documentation produced [24]. This remains indispensable for, e.g., the it service operation management or its further modifications [13].

Once a Sprint is ended, the next scrum step is the Sprint review during which the development team, the product owner and the stakeholders inspect the newly created product increment. This step is supported by the process Service validation and testing (cf. Interface 6). In particular, it provides automated testing solutions to support the Sprint review. If the product increment is validated for release, it is deployed thanks to the support of the process Release and deployment management (cf. Interface 5). It is important to automate the deployment of software seeing that this activity proves to be more frequent with an agile project management method.

After the Sprint retrospective and, if so decided, after the deployment of the product increment, a new Sprint can be planned. Note that, along with the Sprints execution, the product backlog is regularly updated, always with the support of the process Service level management (cf. Interface 2).

Table 2. Description of the interfaces between itil v.3 and scrum; the numbers (#) correspond to the digits used to identify the interfaces depicted in Fig. 4
Full size table

Once the last version of the product fulfils the stakeholders’ expectations about the software-related utility and warranty provided, the scrum project may end by its final deployment (cf. Interface 7). During this last scrum step, the Service design package is finalized according to the operational conventions prescribed by itil (cf. Interface 8). The objective is to make accessible the it service description, including the documentation created during the Sprints, in a single and comprehensive source of information. It is indispensable for further support and maintenance activities carried out during the operation activities structured around the itil phase Service operation.

4 Related Work

Several research works deal with itsm frameworks and agile principles in order to integrate the latter into the itsm processes and environments (e.g., [25, 26]). These works are quite far away from the topic tackled, seeing that we study the consequences of associating an itsm framework with an agile project management method.

In [27], there is a description of how to manage projects and services in an agile way. To do so, they explain how to combine three frameworks: itil v.3 edited in 2007, prince2 and dsdm atern (Dynamic Systems Development Method). The latter is an agile project method for delivering software. This book does not directly describe the relations between itil and an agile project management framework, seeing that prince2 is used as an intermediary between them.

In [28], Pollard et al. argue for a deeper focus on itsm issues, including the consequences of new project management methods, such as agile methods, on the common itsm structure and operations. They underline the need for solutions taking into account both highly structured itsm frameworks and agile frameworks, which provide minimal guidelines according to the authors. In the same line, [29] is a claim for combining itsm frameworks with agile methods in order to improve the business and it alignment (bia). However, the author does not explain how. He focuses on the technological issue in bia through an agile service provisioning system based on the principles of the service-oriented paradigm.

In [30], the authors describe how to apply scrum in the it support, which is one of the components of an itsm. This work covers the operational processes of itil v.2 and discusses the use of scrum during the maintenance and incident management, and when a small modification to an existing service has to be carried out.

Another related paper contains a large discussion about itil v.3 edited in 2007 and software implementation methodologies [31]. A part of the discussion is about agile software implementation methodologies. They stay at a very high level without describing practically how to integrate itil v.3 with an agile method. Nevertheless, the observations made in this paper are similar to our four recommendations (see Sect. 2.3).

Lastly, [32] reports an experiment about the use of xp combined to itil v.2, and concludes that agile methods share more similarities with itil than often believed.

5 Conclusion and Future Work

How can ITIL v.3 and agile project management coexist in an IT organization? By tackling this research issue, we argue for an adaptation of the most used itsm framework, itil v.3, in order to facilitate its coexistence with an agile project management method, scrum. Although itil and agile methods share the same main objective, i.e., providing business value to customers and users, the way of doing is very different. This is explained by their respective structure. Basically, itil favours the complete design and specifications of an it service before starting its implementation. Unlike itil v.3, agile methods favour a parallelism of the design, specifications, implementation and testing activities, which are indeed carried out at each scrum iteration, i.e., at each Sprint. The main contribution of this paper is the identification and the description of eight interfaces, i.e., information exchange channels, between itil v.3 and scrum, which can be put into action thanks to some described adaptations in the structure of the itil v.3 life cycle.

This paper also opens the way for several future works. Applying scrum is only possible for the management of software implementation project and not for other kinds of projects, such as the installation of hardware. Studying the structure of itil v.3 in order to organize both agile and traditional project management is relevant. Indeed, many it organizations face both software and hardware projects, sometimes mixed.

Another future work is the generalisation of the itil adaptations for other agile project management methods. In this context, the integration of this work with the alignment between itil v.3 and the service implementation life cycle proposed by the same authors in [33] is an interesting research direction. The objective would be to map the life cycle of the itsm procedural structure of an it organization, of the service implementation life cycle in a service-oriented system, and of the agile management of software implementation projects.

A last future work is the execution of a case study in one or several it organizations working with itil v.3 and willing to conduct their software implementation projects with scrum. Based on this work, the theoretical propositions made in this paper would be improved thanks to the comments provided and the observations made. Note that this could be a good opportunity to conduct a validation of the scrum method seeing that, taken as a whole, the agile research lacks of empirical validation [34, 35].