See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/321438790

Toward an Agile IT Service Management Framework

Article  in  Service Science · December 2017

DOI: 10.1287/serv.2017.0186

CITATIONS READS

7 4,053

1 author:

Bertrand Verlaine
University of Namur
12 PUBLICATIONS   61 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Bertrand Verlaine on 12 August 2018.

The user has requested enhancement of the downloaded file.

Contents
1 Introduction 2

2 Motivations: On the Road Towards Fully Agile Organizations 4

2.1 Project Management: A Focus on the IT Industry . . . . . . . . . . . . . . . . . . . 4
2.1.1 Presentation of the Agile Theory and Methods . . . . . . . . . . . . . . . . . 4
2.1.2 The Agile Theory and the Service Science: Similarities in the End and in the
Means . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 The Agility in the Architecture of Information Systems . . . . . . . . . . . . . . . . 5
2.3 What About the Operational Management of IT Organizations? . . . . . . . . . . . 5

3 The Generic ITSM Structure 6

3.1 The Key Activities in ITSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 The Main Reasons Explaining the Generic ITSM Structure: Viewpoint on, and Rela-
tions with, the Stakeholders and the Project Management . . . . . . . . . . . . . . . 7
3.3 Agile IT Service Management: Is It an Oxymoron? . . . . . . . . . . . . . . . . . . . 8

4 The Outline of an Agile ITSM Framework 8

4.1 Revisiting the Agile Values and Principles From an ITSM Context . . . . . . . . . . 8
4.2 Towards Agile Practices for ITSM: Propositions and Discussion . . . . . . . . . . . . 11

5 Conclusions 13
5.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1
 SERVICE SCIENCE
2Vol. 00, No. 0, Xxxxx 0000, pp. 000–000 INFORMS
Author: Towards an Agile IT Service Management Framework
Service Science 00(0), pp. 000–000,
c 0000 INFORMS
doi 10.1287/xxxx.0000.0000
issn 2164-3962 | eissn 2164-3970 | 00 | 0000 | 0001
c 0000 INFORMS

Authors are encouraged to submit new papers to INFORMS journals by means of

a style file template, which includes the journal title. However, use of a template
does not certify that the paper has been accepted for publication in the named jour-
nal. INFORMS journal templates are for the exclusive purpose of submitting to an
INFORMS journal and should not be used to distribute the papers in print or online
or to submit the papers to another publication.

Towards an Agile IT Service Management Framework

Bertrand Verlaine
Department of Business Administration, PReCISE Research Center, University of Namur, Belgium,
bertrand.verlaine@unamur.be

For a couple of decades, information technology (it) as well as its management are evolving towards more
agility. Cloud computing and service-oriented computing enable to increase the agility of, respectively, the
hardware and the software components of our information systems and it services. Similarly, companies
use more and more often agile methods for managing their it projects. This means that a major part of
it organizations can follow the values and principles of the Agile theory, which shares many similarities
with the service science. However, regarding the management of the it operations, the existing solutions
are largely process-oriented and focus on the control and the respect of the initial commitments. Thereby,
these solutions, called it service management methods, are not aligned with the agile values and principles.
In response, we propose the basics of a future agile it service management (itsm) framework. To do so, we
revisit the values and principles of the Agile Manifesto to best suit the itsm context. We also identify some
practices applied in the current itsm methods which (partially) block the evolution towards more agility in
itsm. These practices are discussed and rewritten accordingly.
Key words : Service Computing, Service Management, Service Operations, Theory and Principles
History : Paper history.

1. Introduction
The Agile theory provides some interesting answers to problems often encountered during it
projects (Juricek 2014). As examples of these problems, we can mention the lack of engagement
of the stakeholders (Dybå and Dingsøyr 2008), the difficulty to understand the real needs of cus-
tomers and users (Schwalbe 2015, Chap. 4 & 6), and the lack of agility and reactivity of the it
solutions compared to the high velocity of the current business environment (Johnson 2003, Lu and
Ramamurthy 2011). Besides other advantages, the Agile theory proves to be an efficient solution
to increase the dynamicity of Information Systems (is) (Abrahamsson et al. 2009). As underlined
by Coram and Bohner (2005), it also enables to improve the requirements elicitation and the rela-
tionships between the it teams and the project stakeholders. There are also solutions to make
the it components and is more agile such as the cloud computing (Zhang et al. 2010) and the
Service-oriented Computing (soc) (Zhao et al. 2007).
In fact, being agile or, in other words, the agility, is the ability to respond rapidly and in a flex-
ible way to changes in the business and technical domains, but also the ability to induce the
change when it favours the competitive advantage of customers and users (Highsmith and Cock-
burn 2001, Henderson-Sellers and Serour 2005, Dingsøyr et al. 2012). Cockburn (2006) explained
that, by definition, the agility must be light and supple in terms of structure in order to enable
the manoeuvrability and a high speed of response to any kind of change.
Next to the project management and to the architecture of the is used, a third important it
domain is the management of the it operations. This last domain is commonly identified by the
Author: Towards an Agile IT Service Management Framework
Service Science 00(0), pp. 000–000,
c 0000 INFORMS 3

expression “it Service Management” (itsm). itsm is a collection of behaviours, skills, activities
and technologies applied by organizations in order to manage the creation, the delivery and the
support of it-based services aiming at reaching the business goals and at satisfying the customer
needs (Conger et al. 2008). Galup et al. (2009) argue that the itsm research field is de facto a
subset of service science, for which one of the types of service resources –i.e., technology–, takes
a prominent place compared to the three other kinds of resources –i.e., people, information and
organization. This explained why, in the term “it service”, “it” is added before the term “service”,
that Vargo and Lusch (2004) define as “the application of competences for the benefit of another”.
Several authors consider itsm as the description of processes, measures –such as Key Performance
Indicators (kpi’s)– and control activities, enabling an end-to-end coordination and operational
management of the creation, the delivery and the support of it services. As an example, we can
mention Galup et al. (2009) who concluded one of their papers by saying that “the focus of itsm
is to provide specific processes, metrics and guidance to enable and manage assessment, planning,
and implementation of it service processes to optimize tactical and strategic it asset use”. An
analysis of the values and practices behind this view on itsm clearly shows that some of them
are contrary to the Agile theory. Although Verlaine et al. (2016) described how an it organization
willing to work with an agile project management method can make some major modifications
to the structure of the most used itsm method, being agile is actually more than a question of
processes and structure of the it operation activities.
We argue that this is rather a question of values, principles and practices. Actually, this viewpoint
on itsm is rather new and original. A few authors –e.g. Göbel et al. (2014) and Izza and Imache
(2010)– tried to introduce more agility in some itsm practices. One of the research directions
followed by these researchers is based on the agile manufacturing theory which is often defined
as the ability “to respond quickly to changes in information from the market” (Naylor et al.
1999). However, agile manufacturing is grounded on the capacity of an organization to quickly
change its processes and product quality requirements (Yusuf et al. 1999) and, in response to new
environmental information, to modify its processes. These foundations are clearly different from
the Agile theory summarized by Beck et al. (2001) and, hence, from the viewpoint advocated in
this paper. A second research direction followed by, e.g., Izza and Imache (2010), is the creation of
agile is based on the cloud computing or Service-oriented Computing (soc). But, creating agile is
or having agile it is different from respecting the Agile theory.
This original approach of the Agile theory applied to itsm results, first, in a review of the
values and principles stated in the Agile Manifesto, initially written in a context of it project
management. We adapt them to an itsm context and justify each of the modifications made. Then,
we discuss the main practices commonly applied in the existing itsm methods. These practices
are rewritten to fit the values and principles of an agile itsm framework. In a nutshell, the main
research objective of this paper is thus to create the framework characteristics of a future agile
itsm based on the definition of the values, the principles and the key practices of that framework.
By following this viewpoint and thus developing an agile itsm framework, it organizations could
tomorrow apply the agile values and principles in the three main areas of interest of their daily
work. That is to say i) the management of the it projects, ii) the structure of their is, both in terms
of software and hardware resources, and iii) the it operations conducted during the whole life cycle
of the is and it services. The main advantage of this approach lies in the unified and coherent set
of organizational values and principles that would be followed in the it organizations. Indeed, a
coherent and unified set of values and principles are essential in any organization as underlined by,
e.g., Ashforth and Mael (1989), and Jones (2010), Chap. 2 & 7.
This research objective is reached through four parts. First, in Section 2, we detail our moti-
vations, which bring the reader to our (broad) research question as well as the specific research
scope covered in this paper. Then, in Section 3, we detail the generic itsm structure. In Section 4,
we revisit the agile values and principles, originally written for the management of it projects, to
best suit the itsm context. In this section, we also identify, discuss and adapt some current itsm
practices which prevent the existing itsm methods to comply with the agile values and principles.
Lastly, Section 5 concludes this paper and presents the next steps of our research project.
 Author: Towards an Agile IT Service Management Framework
4 Service Science 00(0), pp. 000–000,
c 0000 INFORMS

2. Motivations: On the Road Towards Fully Agile Organizations

2.1. Project Management: A Focus on the IT Industry
2.1.1. Presentation of the Agile Theory and Methods The basics of the Agile theory
has been summarized into the Agile Manifesto by Beck et al. (2001) in reaction to the key problems
identified in the traditional methods for managing software implementation projects (Larman and
Basili 2003b). By traditional methods, we designate the ones which requires a precise determining
of the requirements and the final objective(s) at the beginning of the project. As examples, we can
mention the well-known Waterfall model described by Royce (1987), the Spiral Model of Boehm
(1988), the incremental approach obviously initiated by Walter Shewhart in the 30’ (Larman and
Basili 2003a) or the multiple variation of the V-model. Note that well-known specific methods,
e.g., prince2 (AXELOS 2009) or the pmbok (PMI Standards Committee 2013), also requires
a full descriptions of the objectives and requirements at the beginning of the project. In these
working environments, one of the main goals of the project team, which is also the key element
used for its evaluation at the end of the project, is the respect of the initial commitments –i.e.,
the time, the scope and the resources– determined at the early beginning of the project (Koskela
and Howell 2002). In fact, some problems were identified by researchers –e.g.,Koskela and Howell
(2002), Coram and Bohner (2005), Pichler (2010) and Dingsøyr et al. (2012)– working on the Agile
theory and related domains. For many of the project management models mentioned above, there
is a too long delay between the start of the project and the first release delivery. The project
teams also face many difficulties to take into account the requirement modifications once the
project started. This is the fundamental observations which motivated the creation of the Agile
theory in order to propose “better ways of developing software by doing it and helping others
do it” (Beck et al. 2001). The Agile theory is actually a project management philosophy rather
than being an effective project management method (Juricek 2014). There are several effective
project management methods considered as agile, which have to respect the values and principles
of the Agile Manifesto. As examples, specific agile methods are scrum (Schwaber and Sutherland
2016), extreme programming (Beck and Andres 2004), Crystal Clear (Cockburn 2004), and so
on. According to Dingsøyr et al. (2012), the main objective of the Agile theory is to “create
business value by delivering working software to users at regular short intervals”. This objective is
promoted and framed through four basic values and twelve principles stated in the Agile Manifesto
(Tables 1 and 2 available in Section 4.1 respectively contain the four agile values and the twelve
agile principles). In short, they are guidelines for delivering high-quality software through an agile
structure of the implementation tasks.
A comparative analysis between the Agile theory and the service science shows similarities in
their end and in their means. Section 2.1.2 reports this observation.
2.1.2. The Agile Theory and the Service Science: Similarities in the End and in
the Means The first principle of the Agile theory states that the “highest priority is to satisfy
the customer through early and continuous delivery of valuable software 1 ” (Beck et al. 2001).
With regard to the service science, Vargo et al. (2008) underline that two very important concepts
are “value co-creation” and “value-in-use”. Therefore, a legitimate question comes immediately to
mind: is the notion of valuable software mentioned in the Agile Manifesto similar to the notion of
value and/or value-in-use such as understood in the service science?
Verlaine (2017) deeply discusses this issue. He justifies that the concept of value is similarly
understood in these two research domains. Although Woodall (2003) explains that this concept is
rather elusive in the literature, it can be defined as “a new condition of an entity (i.e., a person, a
group of people or an organization) and/or of its belongings, which is estimated by this entity as
better than before” (Verlaine 2017). From a service-dominant logic, this value should be co-created.
This means that the value is generated through the integration of the competencies and resources
of the provider and its customer(s) by bringing them together in order to mutually and reciprocally

1
Emphasis added.
Author: Towards an Agile IT Service Management Framework
Service Science 00(0), pp. 000–000,
c 0000 INFORMS 5

create valuable outcomes. In the scope of the software implementation, Verlaine (2017) rewrites
the concept of value co-creation as follows: “the software release (i.e., the main outcome of the
project) is created by a group of people bringing together the software development team and the
stakeholders of this future software, to whom the value is provided when the software release is
deployed and really used”. In fact, and as underlined by Abrahamsson et al. (2002), the Agile
Manifesto recommends to create the software release by bringing together the development team,
the business representatives, the project sponsor and the future users. In this document, it is men-
tioned that the working software is the primary element to measure the progress and to satisfy the
customers. This working software has to ease and support the work of its customers and users, that
is to say providing them a new condition which is estimated as better than before. In the scope of
a software implementation project, the value co-create during the software implementation project
is embedded in the developed software; later, this value will be progressively extracted through the
effective use of the software.
Verlaine (2017) also argues that all the principles of the value co-creation theory are enabled,
favoured and/or promoted in the Agile theory. The reader can refer to this work for more infor-
mation.

2.2. The Agility in the Architecture of Information Systems

An increasing agility is also observable in is architectures (Goel and Rishiwal 2012). Indeed, soc
can be used to improve the agility of the software components, while the cloud computing has
similar consequences towards the hardware architecture. These affirmations are justified hereafter.
Erl (2007) presents soc as a rather new generation of software architecture. The central soc
component is the (Web) service. It is the basic construct to enable the development of “rapid, low-
cost composition of distributed applications” (Papazoglou 2008, chap. 1) called service-oriented
system. In this specific research domain, the notion of service should be understood as a self-
describing and self-contained modular software component able to execute some well-delimited
tasks once invoked over a network (Papazoglou and Georgakopoulos 2003, Steen et al. 2005). From
a business viewpoint, Bieberstein et al. (2005) define soc as “a set of flexible services and processes
that a business wants to expose to its customers, partners, or internally to other parts of the
organization, and the same services can be recombined and supplemented to support changes to or
an evolution of business models and requirements over time”. In the scope of this work, the relevant
soc design principles are service loose coupling, service composability, service autonomy, service
discoverability and service reusability. All together, they enable to create software applications
which should be modifiable with ease or, in other words, to create agile applications. soc is also a
software architecture solution to design and specify new business models upon the service concept
(e.g., the service intermediaries (Verlaine et al. 2014)), which interprets the service notion in a
similar way that in service science.
Regarding the cloud computing, Zhang et al. (2010) explained that this is a computing model in
which resources “are provided as general utilities that can be leased and releases by users through
the Internet in an on-demand fashion”. In the scope of this work, the relevant characteristics of the
cloud computing are the high scalability, the easy access, the quick configurability and the rapid
resource releases (Buyya et al. 2010), enabling to have access to agile computing resources.

2.3. What About the Operational Management of IT Organizations?

Besides the management of it projects leading to the design and the implementation of it solutions,
it organizations also have to manage the ongoing operations such as the management of the changes
applied on it resources or the management of the incidents and requests. These management
methods are grouped under the name itsm. itil v.3 and the norm iso/iec 20000 are currently
the two most used itsm methods (Galup et al. 2009) –note that several companies use itil as
foundations for creating their specific model such as ibm with the Process Reference Model for it,
Microsoft with the Microsoft Operating Framework or Hewlett Packard with the ITSM Reference
 Author: Towards an Agile IT Service Management Framework
6 Service Science 00(0), pp. 000–000,
c 0000 INFORMS

Model. In the scope of this paper, we do not take into account the it governance and maturity
since we only focus on the management of the it operations. We let these issues for future work
(see Section 5.1).
itsm frameworks and traditional project management methods leverage a process based approach
to fulfil the organization goals and allow people to collaborate in order to provide value to customers
and users. The major difference between the project management and itsm frameworks concerns
the temporary nature of project management aiming at delivering an unique objective, while the
it operations management is based on an ongoing life-cycle approach without any predetermined
end time.
As underlined in Sections 2.1 and 2.2, both the it project management methods and the main
is components can be agile. Recently, Verlaine et al. (2016) study the relations between the agile
project management and the most used itsm framework, that is to say itil v.3. They analyse how
itil can be combined with agile project management. They conclude that, from a conceptual and
structural view point, they could not be more different: Agile methods are loose and very flexible,
while itil, like the other itsm frameworks, is rather procedural. The Agile theory provides value
by quickly implementing what customers and users really want. itsm frameworks provides value
by delivering stable it services respecting the negotiated set of functionalities and the quality lev-
els initially endorsed in service-level agreements. Moreover, the Agile Manifesto favours informal
interactions between the project stakeholders as opposed to a high formalism, which is advocated
by itil v.3. However, they share a common objective: both of them aim at providing business value
to its customers and users.
Verlaine et al. (2016) justified some major modifications in the structure of the itil v.3 life cycle in
order to align it with agile project management. These modifications enable to organize the infor-
mation exchanges and the work coordination between the steps of the agile project management
method, and the phases and processes of itil v.3. However, it is essential to go a step further.
Instead of modifying the itsm structure from an external viewpoint without questioning the under-
lying values and principles followed, there is a dire need to examine the possibility to work with a
new generation of itsm methods, which would respect the agile values and principles, and would
follow agile practices. This leads to the next (broad) research question:
What would be an agile itsm method?
In this paper, we conduct an initial investigation which provides a part of the answer. In the rest
of this paper, we define the characteristics that an itsm framework should respect to be qualified
as agile. In other words, we draw up and describe its values, principles and practices. Based on
such an agile itsm framework, specific agile itsm methods could be proposed afterwards.
In the scope of this research project, the notion of value, defined by Graeber (2001, chap. 1 and 3),
is as a conception of what is ultimately good, desirable and appropriate for a human organization2 .
A given value is naturally influenced by the fundamental objective searched by its author(s), hence
the term “desirable” in the definition given above. A principle is an elementary rule to respect
in the design of, i.e., a system of reasoning, which is a management framework in the scope of
this work. It frames the practices of the management framework. A practice is defined as a way in
which work must be done when an organization applies the managerial framework containing this
practice.

3. The Generic ITSM Structure

Existing itsm methods –for instance, itil (Cannon et al. 2011, Hunnebeck et al. 2011, Rance et al.
2011, Steinberg et al. 2011, Lloyd et al. 2011) and the iso/iec 20000 standard (The International
Organization for Standards 2011)– intend to ease the delivery of high quality it services at a

2
This notion of value, related to a managerial framework, is different from the notion of value such as understood in
the service science –in this scope, we define the term value as a new condition of an entity (i.e., a person, a group of
people or an organization) and/or of its belongings, which is estimated by this entity as better than before.
Author: Towards an Agile IT Service Management Framework
Service Science 00(0), pp. 000–000,
c 0000 INFORMS 7

controlled cost. Many organizations use itsm methods to align the business and it (Kashanchi and
Toland 2006). These existing itsm methods as well as the related literature recommend to follow a
process-oriented structure (Addy 2007, chap. 1 & 2). According to Galup et al. (2009), this uniform
set of processes assembled under an it operations management method enables the delivery of it
services in a constant and consistent way over time, both in and between it organizations.
The service improvement structure inspired by the “Plan-Do-Check-Act” wheel is another key
itsm characteristic. Its consequence is that the check step is carried out by comparing the results
observed with the initial objectives thanks to the use of kpi’s. This shapes the structure of the
control activities currently implemented in many it organizations.
In the rest of this section, we first briefly recall the main itsm activities (§3.1). Then, in §3.2,
we explain why the current itsm methods are sequentially structured on the basis of a process-
orientation. Lastly, we discuss the possibility to create an agile itsm framework (§3.3).

3.1. The Key Activities in ITSM

As a reminder, the content of itsm methods commonly covers the following activities, organised
as a sequence of steps including controlling tasks: Service level management, Budget and finance
management, Capacity management, Availability and service continuity management, Information
security management, Release and deployment management, Incident and problem management,
Request and access management, Customer and supplier relationship management, Change and
configuration management, Service catalogue management, and Measurement and reporting of the
performance of the it services.
By taking these activities as a whole, the final goal of any itsm method is to create and, then, to
optimize it service components which satisfy the business requirements of the customers. Through
them, it organizations try to reach a better alignment between the it capabilities and the organi-
zational objectives (Kashanchi and Toland 2006).

3.2. The Main Reasons Explaining the Generic ITSM Structure: Viewpoint on, and
Relations with, the Stakeholders and the Project Management
There are two main reasons explaining the current sequential structure promoted in the itsm litera-
ture. The first one is related to the most favoured perspective. There are four major perspectives in
all it organizations and, therefore, in itsm: the processes, the people, the products/technology and
the partners/suppliers. Here is a brief description of these four perspectives (Addy 2007, Hunnebeck
et al. 2011, The International Organization for Standards 2011):
1. People perspective: definition of the roles, functions and responsibilities of all it service
stakeholders (e.g., the staff, the users, the customers, and so on).
2. Partners/suppliers perspective: management of the relations with external partners –
mainly suppliers– which are involved in the creation, the delivery and/or the support of it services.
3. Products/technology perspective: management of the it assets used to create, deliver
and support it services.
4. Processes perspective: description of the processes and activities for creating, delivering
and supporting it services in order to have an end-to-end flow.
Currently, itsm is very often organized around the processes perspective given that it mainly
consists of a set of formalized structures of activities and tasks such as explained by Betz (2011)
who describes the “process architecture” currently applied in many itsm solutions –the reader can
also refer to itil v.3 and its procedural structure (Cannon et al. 2011). The coordination between
these activities and tasks is based on predefined inputs and outputs. The three other perspectives
usually receive less consideration. Moreover, the people perspective has a different interpretation in
comparison with the service science –which considers the stakeholders, including the customers and
the future service users, as co-creators of value thanks to their collaboration with service providers.
Regarding the existing itsm methods, the stakeholders are rather considered as resources which
carry out some tasks, provide information and feedback, make decisions, and so on.
 Author: Towards an Agile IT Service Management Framework
8 Service Science 00(0), pp. 000–000,
c 0000 INFORMS

The second reason is related to the traditional way of managing it projects. Historically, Turner
(2009) explained that most of these projects were managed thanks to Waterfall-based methods –the
most used being the pmbok (PMI Standards Committee 2013) and prince2 (AXELOS 2009). The
itsm structure is therefore inspired by the project management structure used for designing, imple-
menting and releasing it services. The consequence is that the existing itsm methods are indirectly
inspired by the sequential structure of the Waterfall. Moreover, the most used itsm solutions only
considers this Waterfall model for managing the it projects. According to the itil v.3 books, a
“project has a lifecycle that typically includes initiation, planning, execution, and closure” (Rance
et al. 2011, p. 324) that should be managed with a method such as prince2 or pmbok. Verlaine
et al. (2016) studied this question and concluded that itil v.3 is in line with the Waterfall model.
We are convinced that a similar analysis conducted between the iso/iec 20000 standard and the
Waterfall model would result in the same conclusion. This sequential approach is clearly the basic
structure of the existing itsm solutions, which are built upon processes.
Note that, in one itil book (Hunnebeck et al. 2011, §3.11.3), the existence of agile solutions for
managing projects is (very!) briefly mentioned –that is to say the Rapid Application Development
method (rad)3 of Martin (1991) and the extreme programming (xp) method created by Beck and
Andres (2004). However, there is no explanation or discussion concerning the way for combining
one of these two agile methods with itil v.3. Such as explained by Verlaine et al. (2016), the
current structure of itil v.3 does not fit with agile methods.

3.3. Agile IT Service Management: Is It an Oxymoron?

As explained in Section 3.2, the focus is essentially put on the processes perspective in the current
itsm methods. This means that the activities of these itsm methods are organized based on
processes and procedures, which have to be controlled through measurement artefacts such as kpi’s.
Several target figures are determined in order to measure the performance of each activity, process
and it service. Then, the gathered data are analysed and compared to these target objectives in
order to improve these activities and the it service quality. This way of organizing the work is
based on the pdca cycle of Edward Deming. This is one of the basic ideas of the most used itsm
framework (Lloyd et al. 2011, Chap. 3 & 5).
Based on that observation, it is rather clear that, if the process-orientation remains the dominant
perspective, the association of the concepts of “agility” and “itsm” is definitely an oxymoron.
Indeed, one of the most important characteristics of the pdca cycle applied to processes is to do
and to check such as planified (Johnson 2002). There is therefore little space for any adaptation
or agility during the pdca cycle.
However, there are other perspectives which could receive more importance, in particular the
people and the partners/suppliers perspectives in order to design an itsm framework that one wishes
to be agile. This change in the equilibrium between the itsm perspectives, which are currently
not balanced, should enable to associate the word agile and itsm. Indeed, the Agile theory puts a
very strong focus on the people, whatever they may be, as well as on the relations between them.
Instinctively, we can expect that an itsm framework favouring the people and the partners/suppliers
perspectives will be much closer to the Agile theory and, indirectly, to the service science, than
the existing itsm methods. In order to shape that kind of itsm framework, we revisit the agile
values and principles to adapt them to an itsm context, and we identify and discuss the current
itsm practices in order to modify them accordingly (see Section 4).

4. The Outline of an Agile ITSM Framework

4.1. Revisiting the Agile Values and Principles From an ITSM Context
In Section 2.1, we explained that the Agile theory has been created as a reaction to the traditional
methods for managing software implementation projects. It is a philosophy of thinking used to

3
rad is not always considered as fully agile, but this discussion is out of the scope of this work.
Author: Towards an Agile IT Service Management Framework
Service Science 00(0), pp. 000–000,
c 0000 INFORMS 9

Table 1 The values of the Agile theory adapted to the ITSM context
Value Agile values of the Agile theory Agile values of itsm
#1 The individuals and the interactions are The individuals and the interactions are
privileged over processes and tools. privileged over processes, control activities
and tools.
#2 The working software is preferred to com- The working it services are preferred to
prehensive documentation. comprehensive documentation.
#3 The customer collaboration takes a promi- The collaboration between employees, as
nent place instead of contract negotiation. well as with customers and suppliers, takes
a prominent place instead of internal and
external agreement negotiation.
#4 Responding to change is favoured compared Responding to change is favoured compared
to following a plan. to following plans.

organize the work of people, originally in a software implementation context (Juricek 2014). As
underlined by Abbas et al. (2008), the basic ideas and foundations behind the Agile theory are older
that the publication of the Agile Manifesto. They also explained that a significant part of the agile
principles are based on several research domains such as the organization theory, the psychology,
the communication, and so on. The scope of the Agile theory is hence larger than the management
of software implementation projects. It can be considered as a philosophy for organizing the work
of people, at least in it environments. Therefore, in order to create the foundations and the outlines
of agile itsm, it is necessary to rewrite the values and principles of the Agile Manifesto to adapt
them to the context of the management of it operations. Thereby, each (future) agile itsm method
will have to respect those agile values and principles.
But, before discussing them, it is important to define the concept of agility in an itsm context.
In the software development context, Conboy (2009) defines agility as “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
(economy, quality, and simplicity), through its collective components and relationships with its
environment”. In an itsm context4 , the concept of agility becomes:
the continual readiness of the management of the it operations to rapidly or inherently create
change, proactively or reactively embrace change, and learn from change while contributing
to perceived customer and user value (economy, quality, and simplicity), through its collective
components and relationships with its environment.
In Tables 1 and 2, we rewrite, respectively, the agile values and the agile principles set out in the
Agile Manifesto in order to adapt them to the context of organizations creating and providing it
services. Regarding the original agile values (see the left side of Table 1), Beck et al. (2001) explain
that the items on the right part of each value are often prominent compared to the items on the
left side, whereas their manifesto aims at reversing this trend.
Concerning Values #1 and #3, we highlight the emphasis put on the collaboration between the
employees, whatever their functions and their level of responsibilities, that will very likely lead to
the definition of new roles for managers. In an agile itsm environment, they should take a role
which is more oriented towards coaching and facilitating, instead of being a centralized unit of
responsibilities and command in charge of the monitoring and of the control of the work carried
out by their subordinates (Meyer 2014, chap. 4).
As regards the twelve agile principles of the Agile Manifesto, we have to mention some limits.
First of all, they are not all considered as real principles by some authors such as Meyer (2014).
Although this discussion is out of our research scope, we take into account the remarks made in

4
Note that a full generalization of this notion is a very interesting research issue, but it is out of the scope of our
current research scope reported in this paper.
 Author: Towards an Agile IT Service Management Framework
10 Service Science 00(0), pp. 000–000,
c 0000 INFORMS

Table 2 The principles of the Agile theory adapted to the ITSM context
Principle Agile principles of the Agile theory Agile principles of itsm
#1 Our highest priority is to satisfy the cus- The highest priority is to satisfy cus-
tomer through early and continuous deliv- tomers and users through early and con-
ery of valuable software. stant delivery of valuable and working it
services.
#2 Welcome changing requirements, even late Welcome changing needs and constraints,
in development. Agile processes harness whatever the moment, and be structured
change for the customer’s competitive to harness changes in order to reinforce
advantage. the customer’s competitive advantage.
#3 Deliver working software frequently, from /
a couple of weeks to a couple of months,
with a preference to the shorter timescale.
#4 Business people and developers must work Business and technical people must work
together daily throughout the project. together daily.
#5 Build projects around motivated individ- Give to the individuals the environment
uals. Give them the environment and sup- and support they need to be motivated
port they need, and trust them to get the in their daily work, and trust them to get
job done. the job done.
#6 The most efficient and effective method Promote face-to-face conversations to
of conveying information to and within a convey information to and within teams.
development team is face-to-face conver-
sation.
#7 Working software is the primary measure The primary measure of success has to be
of progress. the value provided to users by the deliv-
ery of quality it services.
#8 Agile processes promote sustainable Promote sustainable work by considering
development. The sponsors, developers, that all the it service stakeholders should
and users should be able to maintain a be able to maintain a constant pace indef-
constant pace indefinitely. initely.
#9 Continuous attention to technical excel- Promote the simplicity and the techni-
lence and good design enhances agility. cal excellence to create good it service
designs, and to implement and support
them.
#10 Simplicity –the art of maximizing the /
amount of work not done– is essential.
#11 The best architectures, requirements, Let the teams be self-organized for the
and designs emerge from self-organizing design, the implementation, the delivery
teams. and the support of it services.
#12 At regular intervals, the team reflects on At regular intervals, favour moments of
how to become more effective, then tunes reflection during which teams discuss
and adjusts its behaviour accordingly. on how to become more effective, and
let them then tune and adjust their
behaviour accordingly.

the literature related to the Agile Manifesto when we rewrite these principles in an itsm context.
Secondly, original principles numbered #1, #3 and #7 (see the left part of Table 2) are partially
redundant. Moreover, Principle #3 is not applicable in an itsm context. Therefore, we summarize
them in the first agile principle of itsm. This means that there is no more principle numbered
#3, and that the seventh principle focuses on the value and quality characteristics rather than
Author: Towards an Agile IT Service Management Framework
Service Science 00(0), pp. 000–000,
c 0000 INFORMS 11

on the working characteristic of it services. The last remark concerns the tenth principle, which
contains an error. Indeed, it implies that the definition of simplicity is “the art of maximizing the
amount of work not done”. This assertion is clearly not accurate, although we completely agree
with the essence of this principle saying that “simplicity is essential”. This key idea is introduced
in Principle #9, which therefore becomes a fusion of the original principles numbered #9 and #10.
As a conclusion, it is important to underline that the agile values and principles of itsm outline
the scope of the means to an end, but they cannot be the end them-self. The end is, and remain,
to provide value –term to understand from a service science perspective– to customers and users
through it services, whatever the means used. Therefore, the key issue is to determine better means
to do so. This is tackled in Section 4.2.

4.2. Towards Agile Practices for ITSM: Propositions and Discussion

We review the main practices applied in the common itsm methods based on, i.a., the itil v.3
official books (Cannon et al. 2011, Hunnebeck et al. 2011, Rance et al. 2011, Steinberg et al. 2011,
Lloyd et al. 2011), on the iso/iec 20000 standard (see the report of The International Organization
for Standards (2011) as well as the other parts of this standard), the books of Addy (2007) and of
Meyer (2014), and the works of Galup et al. (2009), and of Kattenstroth and Heise (2011). For each
practice which does not respect the values and principles of agile itsm, we adapt it. The results of
this analysis are summarized hereafter.
,→ Practice #15 :
• Common itsm practice: each itsm process has a manager who is in charge of its operational
management, including the coordination and the planning of all activities required to meet the
process objectives as well as the monitoring and the reporting of the process performances.
• Agile itsm practice: the workers are constituted in self-organized teams, which are in charge of
some kinds of tasks collectively defined; each team has a collective responsibility to make decisions
about their behaviour. Senior workers and managers have a coaching role. They are available on
demand, but also in case of major problems or when a team asks for information and/or advice.
• Explanation: this practice is modified because of Values #1 and #3, and Principles #5, #8
and #11. Taken as a whole, they determine that a team is the best organizational level to define
what to do operationally, and how to do it. Of course, defining the work carried out by each
team should be defined at a higher level because of coordination reasons. Managers –if this term
continues to be used– have a coaching role to advise the teams and help them to improve. It seems
obvious that this agile itsm practice makes sense only if the teams are partially composed of senior
workers. We therefore recommend to compose teams that are balanced between junior and senior
workers.
,→ Practice #2:
• Common itsm practice: the “Plan-Do-Check-Act” wheel is used to structure the improvement
movement of the it services and processes thanks to the creation of kpi’s and their comparison,
by the managers, with the collected data.
• Agile itsm practice: the workers regularly have periods of time to analyse together the perfor-
mance results of the whole organization and of their own team. They are collected through some
conjointly defined kpi’s and some appreciations and opinions of users and customers. By team,
they are collectively in charge of the management of the possible poor performance results related
to their domains of competences and make decisions about the improvement solutions that they
would like to apply.
• Explanation: this practice is modified because of Values #1 and #3, and Principles #5, #6, #7,
#11 and #12. Taken as a whole, they favour an empowerment of the workers in the improvement of
the it services and processes. In an agile itsm method, managers and company leaders should trust
5
The discussion of each itsm practice follows the same structure based on three bullet points: the first one contains
the common itsm practice, the second one is the modified itsm practice, which respect the agile values and principles
previously defined, and the third one justifies the changes made to the original itsm practice.
 Author: Towards an Agile IT Service Management Framework
12 Service Science 00(0), pp. 000–000,
c 0000 INFORMS

the teams which best know their daily work to identify possible dysfunctions and to collectively
find ideas to solve them. As a reminder, they have a coaching and advising role.
,→ Practice #3:
• Common itsm practice: the value provided is evaluated by comparing the performances of the
it services used over the thresholds defined in the contract signed with customers –this contract,
called Service Level Agreement, defines, at least, the minimum availability, capacity and security
levels to reach.
• Agile itsm practice: the value is indirectly provided to customers and, directly, to service it
users –sometimes, the same person has both roles at once. The value is thus mainly evaluated by
users when they make use of the it services, including the possible contacts that they can have with
the organizations providing it services. This means that, if a contract is signed with customers, it
has to consider the users’ opinions concerning the use of the it services.
• Explanation: this practice is modified because of Value #3 and Principles #1 and #7. The
respect of a contract is not the primary indicator of value6 extracted by users (directly) and
customers (indirectly). The primary indicator of value is the appraisal made by the users when
they effectively use the it services as well as when these users and the customers interact with
the it organization. Of course, these evaluations are subjective and qualitative, although it can be
translated into quantitative measures (e.g., “On a one to five scale, please evaluate the relevance
of the answer provided by the service desk”).
,→ Practice #4:
• Common itsm practice: the business and it alignment is reached through the elicitation of
the business requirements of the stakeholders and, subsequently, the creation of the it service(s)
accordingly to these requirements.
• Agile itsm practice: the business side and the it side of organizations, including the external
customers and users in situations where it services are provided to external partners, have to work
together on a daily or weekly basis and in harmony7 .
• Explanation: the business and it alignment is often defined as “the degree to which the it
mission, objectives and plans support and are supported by the business mission, objectives and
plans” (Reich and Benbasat 1996). A sequential structure of the alignment is very often recom-
mended (Henderson and Venkatraman 1993), which is commonly accepted in the itsm litera-
ture (Addy 2007, chap. 3) and applied in many of the existing itsm solutions –e.g., Cannon et al.
(2011), The International Organization for Standards (2011). One of the problems often raised is
the time delay, often substantial, between the expression of the business strategy and requirements,
and the delivery of the it services offering the requested functionalities. In an agile itsm practice,
the objective is to create a continued cooperation, in harmony, between the business and it people
in order to enable the it teams to quickly react, but also to be more proactive given that they
work together and know each other, including their respective work situations. This justification
is promoted by Values #3 and #4, and Principles #1, #2 and #4.
,→ Practice #5:
• Common itsm practice: the work is mainly structured according procedures, derived from the
reference itsm solution applied, and that the workers have to follow. These procedures are fully
documented and taught to new employees when they start to work in the it organization.
• Agile itsm practice: the teams are self-organized and work together to reach the business
objectives collectively discussed and agreed with it service owners. The coordination is primarily
achieved via face-to-face conversations between the elected team representatives.

6
In this practice, the notion of value should be understood according to the service science literature (see Section 1).
7
In this research scope, harmony is defined as a relationship in which various individuals exist and act in cooperation
without destroying one another. This understanding of harmony is dissimilar to its use in the scope of the business
and it alignment literature (for more information, see, e.g., the work of Luftman et al. (1993)).
Author: Towards an Agile IT Service Management Framework
Service Science 00(0), pp. 000–000,
c 0000 INFORMS 13

• Explanation: this practice is modified because of Values #1 and #2, and Principles #1, #5,
#6 and #11. As mentioned in Practice #1, the teams are self-organized and are in charge of some
defined kinds of tasks. These responsibilities enable each team to define their own way of doing
and to adapt themselves when it is deemed as needed following a meeting about their practices
and behaviour (see Practice #2).
,→ Practice #6:
• Common itsm practice: the knowledge is collected by an is, called a knowledge management
system, which is then used to scatter this knowledge among workers and stakeholders.
• Agile itsm practice: the knowledge created and discussed into the teams can be registered in
an is, which could be then used to scatter this knowledge among workers and stakeholders.
• Explanation: this light modification is justified by Value #1, and Principles #6 and #9. The
objective is to underline the importance of the face-to-face discussions and exchanges of information
in the Agile theory. The discussion of some specific situations should improve the knowledge of
each worker, but also to proactively improve the technical quality of the teams taken as a whole.
,→ Practice #7:
• Common itsm practice: there is a clear separation between the operational teams, which man-
age the it services, and the projects teams working under the supervision of a Project Management
Office (pmo).
• Agile itsm practice: the workers can be part of both operational and projects teams depending
on the workload and on the operational events.
• Explanation: if existing, the pmo –i.e., “a management structure that standardizes the project-
related governance processes and facilitates the sharing of resources, methodologies, tools, and
techniques” (PMI Standards Committee 2013, p. 10)–, should progressively become an advising and
coaching council bringing together teams representatives. Taken as a whole, Value #1 and Princi-
ples #2, #5, #9 and #12 recommend to create spaces for discussions and information exchanges,
enabling to take collective decisions, during which the workers can improve their knowledge about
the other projects but also about the design of the it services being created.

5. Conclusions
More and more organizations apply the Agile theory for managing their it project and for creating
their is –via the use of the cloud computing and soc. A third area of it organization, which is the
management of the it services, continues to follow a procedural structure.
TODO: continuer quand le reste est termin! => rappeler le pourquoi, ’le case’/motivations
TODO: (to add) The objective of the paper is not to prove that the incorporation of Agile
principles will improve the ITSM, although this could be the case. The paper argues that many IT
services are built upon agile IT resources and that their design and implementation are managed
through agile project management methods. The last important domain in the global IT manage-
ment is the ITSM, which is absolutely not agile. We can therefore expect that integrating agile
principles and values to adapt (or create) an agile ITSM framework will improve the coordination
and the exchanges of information between the three mentioned IT domains. This is the expected
consequences. This argument is detailed in the conclusion of the paper. In addition to that, the
possible risks are also discussed.
expliquer les rsiques et consequences potentielles!
If this paper had to be sum up in one sentence, we can say that the proposed agile itsm
framework outlines the basics of a future agile itsm method. First, we justify the need for a new,
and agile, set of itsm values and principles. Indeed, the it industry currently builds agile is and
manages it projects with agility. In pursuing the goal of having a fully agile it, the current main
missing element is the management of the it service operations. Seeing that the Agile theory and
the service science share many similarities in terms of objectives and means, applying the agile
values and principles to shape an agile itsm framework makes sense when we speak about providing
value through it services. This is why we discuss and revisit the agile values and principles stated
 Author: Towards an Agile IT Service Management Framework
14 Service Science 00(0), pp. 000–000,
c 0000 INFORMS

in the Agile Manifesto in order to adjust them to an itsm context. Then, we identify the main
itsm practices blocking the evolution of itsm towards more agility. We discuss and review them
according to the Agile theory, i.e., the agile values and principles adapted to an itsm context.
As underlined many times, the tasks carried out by the teams remain the same; only the way
to organize, coordinate and manage them has to be modified. Indeed, the agile values, principles
and practices essentially have managerial implications –the roles of managers and workers should
change towards, respectively, a coaching and advising role, and more collective responsibilities.

5.1. Future Work

TODO: ajouter une discussion sur la gouvernance et la maturit orga
=>In the scope of this paper, we do not take into account the it governance and maturity since
we only focus on the management of the it operations. We let these issues for future work (see
Section 5.1).
The next main research stage is the selection of a set of itsm and agile practitioners with whom
the four values and the ten principles of an agile itsm will be discussed. Based on their opinions
and comments, the agile itsm framework could be revised and adapted.
Afterwards, the structure and artefacts of a specific agile itsm method will be described. This
method must be grounded in the agile itsm values, must respect the agile itsm principles and must
observe the agile itsm practices. In other words, it has to comply with the agile itsm framework.
To do so, the key itsm activities (listed in Section 3.1) have to be reorganized around the life cycle
of the specific agile itsm method to create. The artefacts, to be determined, of this agile itsm
method will enable the coordination between these itsm activities. In agile project management,
these artefacts are, e.g., the product backlog, some specific types of meeting or the Kanban board.
Then, the proposed agile itsm method has to face the reality through some experimentations. The
objective is to improve the life cycle proposed, but also to improve the artefacts that are used for
coordination purpose.
A last future work is the analysis of the (possible) consequences of the use of an agile itsm method
with respect to issues in connection with the it governance and the organizational maturity.

References
Abbas N, Gravell AM, Wills GB (2008) Historical Roots of Agile Methods: Where Did ”Agile Thinking”
Come From? Proceedings of the 9th International Conference on Agile Processes in Software Engineer-
ing and Extreme Programming, volume 9 of Lecture Notes in Business Information Processing, 94–103
(Springer).
Abrahamsson P, Conboy K, Wang X (2009) ’lots done, more to do’: the current state of agile systems
development research. European Journal of Information Systems 18(4):281.
Abrahamsson P, Salo O, Ronkainen J, Warsta J (2002) Agile software development methods: Review and
analysis.
Addy R (2007) Effective IT Service Management (Berlin: Springer).
Ashforth BE, Mael F (1989) Social identity theory and the organization. Academy of Management Review
14(1):20–39.
AXELOS (2009) Managing Successful Projects with PRINCE2 (The Stationery Office).
Beck K, Andres C (2004) Extreme Programming Explained: Embrace Change (Addison-Wesley), 2nd edition.
Beck K, Beedle M, Bennekum AV, Cockburn A, Cunningham W, Fowler M, Grenning J, Highsmith
J, Hunt A, Jeffries R, et al. (2001) Manifesto for Agile Software Development. Available at
http://www.agilemanifesto.org/.
Betz CT (2011) Architecture and Patterns for IT: Service Management, Resource Planning, and Governance
(Elsevier).
Bieberstein N, Bose S, Fiammante M, Jones K, Shah R (2005) Service-Oriented Architecture (SOA) Compass:
Business Value, Planning, and Enterprise Roadmap (Upper Saddle River, NJ: Prentice Hall PTR).
Author: Towards an Agile IT Service Management Framework
Service Science 00(0), pp. 000–000,
c 0000 INFORMS 15

Boehm BW (1988) A Spiral Model of Software Development and Enhancement. IEEE Computer 21(5):61–72.
Buyya R, Broberg J, Goscinski AM (2010) Cloud Computing: Principles and Paradigms, volume 87 of Wiley
Series on Parallel and Distributed Computing (Hoboken, NJ: John Wiley & Sons).
Cannon D, Wheeldon D, Lacy S, Hanna A (2011) ITIL V3.0 – Service Strategy (The Stationery Office), 2nd
edition.
Cockburn A (2004) Crystal Clear: A Human-Powered Methodology for Small Teams. The Agile Software
Development Series (Addison-Wesley Professional).
Cockburn A (2006) Agile Software Development: The Cooperative Game (Addison-Wesley Professional), 2nd
edition.
Conboy K (2009) Agility from First Principles: Reconstructing the Concept of Agility in Information Systems
Development. Information Systems Research 20(3):329–354.
Conger S, Winniford MA, Erickson-Harris L (2008) Service Management in Operations. Proceedings of the
14th Americas Conference on Information Systems, AMCIS 2008 – Learning from the past & charting
the future of the discipline (Association for Information Systems), paper 362.
Coram M, Bohner S (2005) The impact of agile methods on software project management. Engineering of
Computer-Based Systems, 2005. ECBS’05. 12th IEEE International Conference and Workshops on the,
363–370 (IEEE).
Dingsøyr T, Nerur SP, Balijepally V, Moe NB (2012) A decade of agile methodologies: Towards explaining
agile software development. Journal of Systems and Software 85(6):1213–1221.
Dybå T, Dingsøyr T (2008) Empirical studies of agile software development: A systematic review. Information
& Software Technology 50(9-10):833–859.
Erl T (2007) SOA: Principles of Service Design (Boston, MA: Prentice Hall).
Galup SD, Dattero R, Quan JJ, Conger S (2009) An Overview of IT Service Management. Communications
of the ACM 52(5):124–127.
Göbel H, Cronholm S, Manfredsson P (2014) LeAgile Management: An IT Service Management Perspective.
Proceedings of the 17th QMOD Conference on Quality Management and Organizational Development
(Taylor & Francis).
Goel R, Rishiwal V (2012) Cloud Computing and Service Oriented Architecture. International Journal of
Recent Technology and Engineering 1(1):137–139.
Graeber D (2001) Toward an anthropological theory of value: The false coin of our own dreams (New York:
Palgrave Macmillan).
Henderson JC, Venkatraman N (1993) Strategic alignment: Leveraging information technology for trans-
forming organizations. IBM Systems Journal 32(1):4–16.
Henderson-Sellers B, Serour MK (2005) Creating a Dual-Agility Method: The Value of Method Engineering.
Journal of Database Management 16(4):1–24.
Highsmith J, Cockburn A (2001) Agile software development: The business of innovation. IEEE Computer
34(9):120–122.
Hunnebeck L, Rudd C, Lacy S, Hanna A (2011) ITIL V3.0 – Service Design (The Stationery Office), 2nd
edition.
Izza S, Imache R (2010) An approach to achieve IT agility by combining SOA with ITSM. International
Journal of Information Technology and Management 9(4):423–445.
Johnson CN (2002) The benefits of PDCA. Quality Progress 35(5):120.
Johnson M (2003) Credibility challenged. Computer World 37(20):22.
Jones GR (2010) Organizational theory, design, and change .
Juricek J (2014) Agile Project Management Principles. Lecture Notes on Software Engineering 2(2):172–175.
Kashanchi R, Toland J (2006) Can ITIL Contribute to IT/Business Alignment? An Initial Investigation.
Wirtschaftsinformatik 48(5):340–348.
 Author: Towards an Agile IT Service Management Framework
16 Service Science 00(0), pp. 000–000,
c 0000 INFORMS

Kattenstroth H, Heise D (2011) Towards a Method for IT Service Management. Proceedings of Fourth
Working Conference on the Practice of Enterprise Modeling, 178–192 (Springer).
Koskela LJ, Howell G (2002) The underlying theory of project management is obsolete. Proceedings of the
PMI Research Conference, 293–302 (The Project Management Institute).
Larman C, Basili VR (2003a) Iterative and incremental development: A brief history. IEEE Computer
36(6):47–56.
Larman C, Basili VR (2003b) Iterative and Incremental Software Development: A Brief History. IEEE
Software 36(6):47–56.
Lloyd V, Wheeldon D, Lacy S, Hanna A (2011) ITIL V3.0 – Continual Service Improvement (The Stationery
Office), 2nd edition.
Lu Y, Ramamurthy K (2011) Understanding the link between information technology capability and orga-
nizational agility: An empirical examination. MIS Quarterly 35(4):931–954.
Luftman JN, Lewis PR, Oldach SH (1993) Transforming the Enterprise: The Alignment of Business and
Information Technology Strategies. IBM Systems Journal 32(1):198–221.
Martin J (1991) Rapid Application Development (Indianapolis, IN: Macmillan Publishing Company).
Meyer B (2014) Agile! The Good, the Hype and the Ugly (Switzerland: Springer).
Naylor JB, Naim MM, Berry D (1999) Leagility: Integrating the lean and agile manufacturing paradigms in
the total supply chain. International Journal of production economics 62(1):107–118.
Papazoglou M (2008) Web Services: Principles and Technology (Great Britain: Prentice Hall).
Papazoglou MP, Georgakopoulos D (2003) Service-oriented Computing. Communications of the ACM
46(10):24–28.
Pichler R (2010) Agile Product Management with Scrum: Creating Products that Customers Love (Addison-
Wesley Professional), 1st edition.
PMI Standards Committee (2013) A Guide to the Project Management Body of Knowledge (PMBOK
GUIDE) (The Project Management Institute), 5th edition.
Rance S, Rudd C, Lacy S, Hanna A (2011) ITIL V3.0 – Service Transition (The Stationery Office), 2nd
edition.
Reich BH, Benbasat I (1996) Measuring the Linkage Between Business and Information Technology Objec-
tives. MIS Quarterly 20(1):55–81.
Royce WW (1987) Managing the Development of Large Software Systems: Concepts and Techniques. Pro-
ceedings of the 9th International Conference on Software Engineering (ICSE), 328–339 (ACM Press).
Schwaber K, Sutherland J (2016) The SCRUM Guide: The Definitive Guide to SCRUM: The Rules of the
Game. Available at http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf.
Schwalbe K (2015) Information Technology Project Management (Cengage Learning), 5th edition edition.
Steen MW, Strating P, Lankhorst MM, ter Doest H, Iacob ME (2005) Service-Oriented Enterprise Archi-
tecture. Stojanovic Z, Dahanayake A, eds., Service-Oriented Software System Engineering: Challenges
and Practices, 132–154 (IGI Global).
Steinberg R, Rudd C, Lacy S, Hanna A (2011) ITIL V3.0 – Service Operation (The Stationery Office), 2nd
edition.
The International Organization for Standards (2011) ISO/IEC 20000-1:2011 – Information technol-
ogy – Service management – Part 1: Service management system requirements. Available at
http://www.iso.org/iso/home/store/catalogue tc/catalogue detail.htm?csnumber=51986.
Turner JR (2009) The Handbook of Project-based Management (McGraw-Hill Professional), 3rd edition.
Vargo SL, Lusch RF (2004) Evolving to a New Dominant Logic for Marketing. Journal of Marketing 68(1):1–
17.
Vargo SL, Maglio PP, Akaka MA (2008) On value and value co-creation: A service systems and service logic
perspective. European Management Journal 26(3):145–152.
 Author: Towards an Agile IT Service Management Framework
Service Science 00(0), pp. 000–000,
c 0000 INFORMS 17

Verlaine B (2017) An Analysis of the Agile Theory and Methods in the Light of the Principles of the
Value Co-Creation. Rozenes S, Cohen Y, eds., Handbook of Research on Strategic Alliances and Value
Co-Creation in the Service Industry, chapter 10, 184–203 (IGI-Global).
Verlaine B, Jureta I, Faulkner S (2016) How Can ITIL and Agile Project Management Coexist? An Adap-
tation of the ITIL v.3 Life Cycle in Order to Integrate SCRUM. Proceedings of the 7th International
Conference on Exploring Services Science (IESS 2016), volume 247 of Lecture Notes in Business Infor-
mation Processing, 327–342 (Springer).
Verlaine B, Jureta IJ, Faulkner S (2014) Optima: A Domain-specific Model for Prioritization and Conflicts
Management in Requirements Engineering for Services Intermediaries. Service Oriented Computing and
Applications 8(2):175–190.
Woodall T (2003) Conceptualising’value for the customer’: An attributional, structural and dispositional
analysis. Academy of Marketing Science Review 7(9):1–42.
Yusuf YY, Sarhadi M, Gunasekaran A (1999) Agile manufacturing:: The drivers, concepts and attributes.
International Journal of Production Economics 62(1):33–43.
Zhang Q, Cheng L, Boutaba R (2010) Cloud computing: State-of-the-art and research challenges. Journal
of Internet Services and Applications 1(1):7–18.
Zhao JL, Tanniru M, Zhang L (2007) Services computing as the foundation of enterprise agility: Overview
of recent advances and introduction to the special issue. Information Systems Frontiers 9(1):1–8.

View publication stats