Explaining the agile transformation through

management innovation adoption

AKIM BERKANI and DOMINIQUE CAUSSE

Paris-Dauphine University, PSL Research University, Paris, France;
Programme de recherche Aurore, Daylight Consulting, Paris, France

Agile transformation has become an important topic in many large organizations. After
adopting agile methods, many firms are asking the question of standardizing these methods to
all projects. Little research informs us about the implementation process of agile methods.
Knowing that they generate several changes in roles, processes and culture, our paper aims to
answer the following question: How is the implementation of agile methods organized across a
large organization? By integrating theories from diffusion of innovations, and agile methods
literature in information systems, we contribute to re-assess the adoption process of a
managerial innovation (Damanpour and Schneider, 2006). Based on a qualitative research
design via a case study aimed at explaining this complex phenomenon, we analyze the
implementation of agile methods during the last 10 years in a large information technology
services company.

Keywords: Agile methods, management innovation adoption, organizational transformation,

empirical case study

1
Introduction
Initially set up for software development projects, agile methods have gained ground in the last
25 years in different fields of application (for example at Saab, in the construction of aircraft
according to an article by Furuhjelm et al., 2017). These methods1are generally, repositioned
on a set of simplified practices and consider the needs and solutions evolving throughout a
project, relying on multidisciplinary teams with some form of self-management. They are based
on an iterative, incremental and adaptive development process (Takeuchi and Nonaka, 1986)
that require a certain rigor.
The term "agile" comes from the publication of the Agile Manifesto created in 2001 by a group
of 17 software experts seeking to establish a better way to develop software The aim was to
improve the traditional methods of waterfall development and the V cycle. The manifesto
establishes a basic philosophy of 4 values and 12 underlying principles that focus on individuals
and their interactions more than processes and tools; operational software rather than
exhaustive documentation; collaboration with clients more than contract negotiation and
change adaptation more than following a plan. The meaning of "agile" used to characterize
these methods is defined by few academics as the "ability to create and respond to change in
order to benefit in a turbulent business environment" (Conforto et al., 2016).
Companies launched in a digital transformation are subjected to constant pressure from markets
to develop and produce more varieties of new products in shorter delays. These kinds of
products could be mobile applications, software or web services (Majchrzark, 2016).
Nevertheless, the development of these new digital services must be achieved without
compromising fundamental criteria such as quality and value added for end users.
To develop these solutions, agile methods, offer potential answers for facing these challenges
to improve software development processes. During the last 20 years, agile methods have been
widely introduced in organizations. The enthusiasm in the adoption of these approaches comes
from the profits noticed. Indeed, they make it possible to bring value more frequently compared
to projects carried out via "classical" approaches2. They tend to reduce the time to market of
projects, and in other cases, there is an improvement in the quality of the product 3 delivered
(Laanti et al., 2011). Based on these observations, many large organizations (private or public)
are no longer at the level of adoption for a few projects but are rather in an implementation
phase of these approaches at the level of all information system projects.
Many issues can emerge, and at first glance it is the CIOs departments who seize the subject by
experimenting and training technical teams to set up a first approach. When this experiment has
resulted in success, in many cases, agility will gain ground and be more largely adopted by the
Information Systems Department (ISD).
Recently in the literature, a few studies about the implementation of agile methods have been
launched by researchers. These works are mainly in the literature in information systems where
authors named this phenomenon “agile transformation” process (Dikert et al., 2016; Paasivara
et al., 2018; Mikalsen et al., 2018). Studies in agile methods turn mainly around the introduction

1
Most agile approaches are described by practitioners as framework rather than methods, to insist on the
capacity to adapt the set of rules to the problem to be solved, rather than a processing and control philosophy
2
We call classical approaches, predictive methods such as the V cycle or waterfall development
3
In this context, we use the term product to talk about the development of software’s or web services.

2
process. According to recent works from Dikert et al., (2016), research in agile transformation
is under investigated. Indeed, they reported that only six of the 52 existing reports analyzed
were scientific. Most of the selected papers were experience reports published in practitioners'
agile conferences, showing thus their interest in the topic.
Since the release of the Agile Manifesto in 2001, agile methods have been used by numerous
projects in large organizations. We have noticed that many organizations have launched the
implementation of agile methodologies with a wide variety of approaches. For example, some
companies embark on a planned deployment implemented through a transformation program
when others prefer establishing an environment facilitating the emergence of new approaches
through experimentation (Paasivaara et al., 2018; Korhonen, 2013).
There are many parameters to consider when considering the implementation of an agile
methodology: plethora of agile techniques and tools, multiples impacts on culture and decision
process, evolution of roles and organization of work. However, either from researchers or
practitioners, no models or specific framework exist to guide organization in the choice of the
most adequate activities to be implemented, to achieve their strategic objectives.
When agile approaches are introduced within an organization, we hypothesize that this
introduction can be likened to the internal adoption process of a managerial innovation
(Damanpour and Wischnevsky, 2006). The process is characterized by a pattern of three phases:
pre-adoption, adoption and post adoption.
Thus, this article aims to clarify the implementation (post-adoption) of agile methods within
large companies by analyzing its deployment dynamics such it becomes ingrained within
organizational behaviors (Zmud, 1982). The research question can be stated as follows: How is
the implementation of agile methods organized across a large organization?
Driven by our research question, we present in the next part a theoretical background showing
how management innovation literature can help researchers and practitioners to explain agile
transformation. We continue by presenting qualitative research design based on a case study,
and we finish by presenting results and analysis in a third part.

3
Theoretical Background:
Considering the large number of agile techniques and tools, it is not easy for an organization to
select the most efficient implementation initiatives and the most adequate activities to be
implemented to achieve their strategic objectives. Selecting, adopting and deploying, a
consistent transformation plan in line with the organization’s vision and its level of maturity in
terms of adoption of best practices calls for rigor and considerable involvement of the
organization members, as well as a clear vision of the objectives to be achieved.
To meet our ambition to characterize how large companies generalize agile methods approaches
across an organization, the theoretical framework of management innovation is mainly
mobilized among the different studies about innovations diffusion (Rogers, 1995). As early as
the 1960s, authors were interested in innovations that did not involve a technological dimension
(Evan, 1966: Kimberly, 1981: Van de Ven, 1986). But the work of Hamel, Mol and Birkinshaw
(2008) shows the excitement around these management objects (Adam-Ledunois and Damart,
2016).
Research on this form of innovation is still emerging (Damapour and Aravind, 2012, Giuliani
et al., 2018) and the notion of innovation remains relatively vague and polysemic. This seems
to be related to the very nature of managerial innovation, which has an important tacit
dimension (Birkinshaw et al., 2008) and makes it more difficult to identify than other types of
innovation.
Managerial innovation is seen as a central factor in performance and the solution for creating
long-term competitive advantages (Walker, Chen and Aravind, 2015); both as a complement to
technological innovation (Damanpour et al., 2009) and as an independent phenomenon (Mol
and Birkinshaw, 2009).
Research on management innovation as a process explores how innovations are generated,
adopted and diffused. It can be seen as a series of activities, traditionally grouped into two main
phases: generation and adoption (Damanpour and Aravind, 2012, David, 2018). An innovation
is first generated, then it is adopted in the generating company or another organization. This
process has been conceptualized by Birkinshaw et al., (2008) and is defined as a process for
creating a new product, service, technology, or practice and results in an outcome that is new
to at least a population of adopters (Damanpour and Wischnevsky, 2006; Hollen et al., 2013).
While managerial innovations have been particularly studied in terms of their inter-
organizational distribution (Birkinshaw et al., 2008), this is not the case for adoption. Many
authors have brought the process of adoption of a technological innovation closer to that of a
managerial innovation, considering that the different sequences are identical. On the other hand,
the adoption process is often viewed as relatively orderly and as a progression of sequential and
periodic phases (Damanpour and Wischnevsky, 2006).
It is essential to differentiate the adoption process of an inter-organizational managerial
innovation (MI) from intra-organizational adoption. In the first case the inter-organization
adoption explains the mechanisms of generation and diffusion of a management innovation
within different companies, when the second concerns the adoption within one and the same
company.

4
Studying the adoption process of a management innovation forces us to choose a managerial
innovation at the "established" stage following Hatchuel and David (2007). A contextual model
is a model used in an organization. A model is considered as "established" when it is validated
and considered legitimate by actors outside the organization such as other organizations,
academics and / or recognized professionals.

Analysis of agile methods as established management innovation

Justifying the established nature of agile methods as managerial innovations when they are
adopted necessitate historical investigations in the conceptual form. Therefore, we focus in this
document only on the Scrum4 method (Sutherland and Schwaber, 2013).
To consider a management object as innovative, we should not only consider the definition of
its newness. Adam-Ledunois and Damart., (2016), proposed a framework that allows to justify
the innovative character of a management object. A management object can be innovative from
a contextual dimension or a conceptual dimension. In order to justify in which dimension a
management object is innovative, the authors propose to consider 3 sets of elements. They
propose first to analyze a set of attributes of the studied object (set A), that is the definition and
the rhetoric of the management object. Second, a set of practice in the reference domain of use
(set P)¸ these can be practices within an organization in which the management object is being
studied. It can be analyzed with an historical description of the usual practices of the
organization on a field of use or for a particular function, through its history. And third a state
of knowledge in the reference domain (set K), groups together the concepts, theories, principles,
tools, methods, structures, processes, or philosophies developed in the academic literature and
which make it possible to label management objects that serve the same purpose as the object
under study.
Attributes of Scrum (Set A)
Concerning our management object studied, Scrum is a framework within which people can
address complex adaptive problems, while productively and creatively delivering products of
the highest possible value (Schwaber and Sutherland, 2017). It is also defined as a new approach
encompassing a wide variety of organizational and managerial practices in which development
cycles are organized in Sprints. New emerging tools such as the Backlog, which is no longer a
detailed specification (Daneva et al., 2013) but only a needs booklet formalized very lightly are
released. At the roles level, the project manager disappears to make way for new roles like the
Product Owner and the facilitator, which in this case is called the Scrum Master.
Therefore, when a company introduce Scrum, we can find in the previous definition the notion
of novelty that can be verified at the level of the company. Even with regard to the roles; a set
of new organizational and managerial practices in relation to the state of the art; its non-
technological nature; and its intentionality, that is the simplification of project or product
development processes. The goal of this method according to creators is to bring adaptation and
continuous improvement.
Scrum and other agile methods have been widely adopted in large organizations for more than
20 years to structure the design of enterprise information systems (IS). While it is possible to

4
https://www.scrum.org/resources/scrum-guide

5
see a spread of these methods in many companies, it is essential to understand how these
methods are diffused.
Since the 1980s, project management has been heavily supervised by many meta-organizations
(Berkowitz and Dumez, 2016). Among these meta-organizations, the Project Management
Institute (PMI) and its repository the Project Management Body of Knowledge (PMBoK) is
widely distributed in many companies. Agile approaches have also seen a sharp rise in the
number of certifying bodies like the Agile Alliance, the Scrum.org, the Scrum Alliance or the
Scaled Agile Inc playing a crucial role in the diffusion between organizations.

Trends in agile bodies of knowledge (set P):

Agile approaches came out into the design of information systems to counter the many failures
seen in projects. However, it is interesting to take a step back in the different agile methods that
have accompanied the development of projects in recent years.
Many authors are still taking the release of the Agile Manifesto as the genesis of these methods,
the reality is in fact different. In 1994, the Standish Group (2011) published its first report
named Chaos Report. This study was at the time one of the first to give figures on the success
rate of software development projects in the United States. Even if the non-transparent
methodology is open to criticism, the report highlights a considerable rate of project failure. At
the same time, Ken Schwaber and Jeff Sutherland, two experts in software development,
proposed the Scrum framework to counter this "software development crisis." The Scrum
approach has become the most widely used methodological framework today (VersionOne,
2017). Scrum is mainly based on an article from Takeuchi and Nonaka (1987) named the new
new product development game.
Since the 90s, a variety of methods operationalizing the philosophy of the Agile Manifesto have
emerged. It is also possible to discern three broad categories of approaches:
1. Small Scale Approaches (SSA), which refer to Scrum-like methods, Kanban for IT, having
been created for small teams (4 to 9 people).
2. Large Scale Approaches (LSA), which refer to Scaled Agile Framework (SAFe) (Leffingwell
2015); Large Scale Scrum (LeSS) (Larman and Vodde 2015); Disciplined Agile Delivery
(DaD) (Ambler 2012) models, created to extend agility and synchronize multi-teams projects
mainly in information systems department (from 10 to 150 people).
3. Organizations Agile Framework (OAF), addressing how to generalize agile methods at the
organization level and not only for large projects or an IT department. Initiatives have begun to
emerge very recently but are still in a working stage and need to gain recognition (Agile
Business Consortium, Axelos, 2018).
Another recent trend is that agile methods are gaining ground in traditional project management
methodologies and beyond. For examples in recent years traditional frameworks have started
to integrate agile practices (PMBoK version 6, PRINCE2 Agile). Agile Programme
Management is supported by the DSDM method and some frameworks have also begun to
address Portfolio management (AgilePfm, SAFe, Diciplined Agile Delivery)

6
Recent studies in agile methods adoption and diffusion (set K)
The literature dealing with agile methods studies is polarized in three different domains. First,
researchers focused in the adoption of agile methods on team level. Second, a set of papers deal
with transitions models including maturity models. Third a beginning of interest has grown
about agile transformation, focusung on the impacts of a global adoption at the organizational
level.
The literature dealing with the adoption and the deployment of agile methods is mainly linked
to the domain of management of information systems (Diegmann et al., 2018). From 2001, the
number of publications is consistent and is polarized into several themes such as IT Capability
& Agility; Risk, Control & Success Factors in Agile, or Technologies & Applications among
others.
Different frameworks of agile methods adoption may be found in information systems
literature. The Objective, Principles and Practices (OPP) framework is a comprehensive
approach to assessing the “goodness” of a particular agile method for a specific company based
on adequacy, capability and effectiveness (Soundararajan and Arthur, 2019). The Agile
software solution framework (ASSF) is developed to assist management in evaluating the level
of agility they require and how to identify suitable manners to introduce the agility into their
company (Qumer and Henderson- Sellers, 2008). A group of authors identified the absence of
guidance and assistance in the agile adoption process in the scientific literature, and in response
to that created a framework to be used as a structured approach towards successful adoption of
Agile practices (Sidky et al., 2007). The framework consists of two main components: Sidky
Agile Measurement Index (SAMI) for estimating agile potential, and a set of four-staged
processes with a measurement index used to determine which Agile practices may and should
be integrated with the organization.
Beyond the models of adoption and adaptation of agile methods, the literature has also given
rise to several articles on models of large-scale transitions. The empirical model of Gandomani
and Nafchi (2015) based in part on elements of the Scrum method makes it possible to deploy
a transition mainly oriented at the level of team practices. But the model encompasses one
dimension (the teams) and does not allow practitioners to trace and understand the different
phases of the implementation. More recently, Laanti’s model (2017) goes beyond the teams and
takes into account the scope of implementation (teams, programs and project portfolio) and the
level of maturity. They identify 5 levels: Beginner, Novice, Easy, Advanced and World Class.
These different stages rather define the maturity of the project layer of an organization and
therefore does not concern the proposition of a process. Indeed, the model does not consider
the other dimensions mentioned above and seems to neglect the definition / characterization of
the different steps by which the organization will have to go, and how the generalization should
be managed.
Finally, there is an important topic in the field that is recognized in the literature review made
by Dikert et al. (2016), concerning the agile transformation process, where they classified the
challenges and success factors. If the literature on information systems is full of articles about
agile approaches, we find that the question of the generalization is mainly addressed by

7
analyzing the barriers (Dingsøyr et al., 2005; Dikert et al, 2016), via determinants analysis.
However, to the best of our knowledge, few studies apart from Senapathi and Srinivasan (2012)
study the adoption process of these methods, not at the level of the teams, but at the level of an
information systems department.
Jovanic et al, (2017) analyzed via a grounded theory study the transition of organizational roles
during the agile transformation process. And they identified inadequate transition of
organizational roles influenced by two conditions. The first condition is that management roles
are focused on the traditional paradigm. And the second is creating agile teams in the traditional
enterprise. They also found that the transformation process induced evolutions in organizational
roles. But their analyses are based on investigations ex ante to the transformation where we
don’t have a clear view about how the transformation process is organized.
Paasivara (2017), described in their recent research a large-scale agile transformation of an
Ericsson product development program developing a new information technology platform.
They presented the steps taken, the challenges faced, and the mitigating actions taken. They
gave four lessons learned about an international implementation dealing with: Experimental
Transformation Approach, a Stepwise Transformation, the highlighted lack of a Common Agile
Framework, and the Limited Team Interchangeability in the case studied.
In their research, Mikalsen et al., (2018) treated how interdependencies are addressed in agile
digital transformation. They analyzed a case study of a Nordic bank, the findings exemplify the
kind of negotiations that follow from increased interdependencies and suggest the need for
research that focuses on the role of diverse evaluation criteria within these negotiations (Jiang
et al. 2018).

Agile transformation under the lens of management innovation implementation

When an agile method is introduced in the organization and if it’s new to the company, the
adoption process can be assimilated to the adoption process of a managerial innovation. Indeed,
Vaccaro et al. (2012) defined managerial innovation as new to the generating or adopting
organization. The newness of the management object is justified if the organization has not
already adopted the new method.
The adoption of an agile method can be considered as a transition from one state to another
(Sidky et al., 2007). It can be defined as a process, comprising of various sequences of activities,
behaviors and events that lead to a result (Damanpour, 2014). According to Rogers (1995), one
of the greatest advances in innovation research has been the realization that innovation can be
understood in both these forms, but that it is primarily a process.
The process of adopting a managerial innovation (MI), understood as the decision to adopt,
adapt and deploy the use of a MI, has not been the subject of many empirical studies. Many
models have been proposed for this adoption process. According to Damanpour and Aravind
(2012), the adoption processes of technological and organizational innovations are similar. The
adoption process is still considered relatively orderly and as a progression of sequential phases
(Damanpour and Wischnevsky, 2006).
Among the different models in the literature, some authors have proposed reducing the number
of phases from seven to three. We take as an example the model of Damanpour and Schneider.,

8
(2006) to explain the different phases of the process. The first phase is about initiation and the
decision to adopt. It consists of all activities related to the perception of problems or needs, the
search for solutions, the collection of information on these solutions, the training of attitudes
towards these solutions and their evaluation to achieve a decision (Damanpour, 1991). In our
work, members of the organization that we study discover the existence of an agile
methodology, evaluate its relevance, try it out and discuss it with each other until making the
decision to adopt it in a second phase (Damanpour and Schneider, 2006).
The third phase is the implementation and is composed of all the events and actions relating to
the preparation of the implementation. The implementation (or deployment) can be done in an
exploratory manner and different scenarios are possible. The innovation will adapt to the
organization and / or the organization will adapt to the requirements of the adopted
methodology (Damanpour, 1991). In this phase, we can assess whether the members of the
organization agree to use this innovation or show resistance to its use (Damanpour and
Schneider, 2006). The implementation goes until routinization. It corresponds to the fact that
the innovation is used in a usual way, even generalized and that it becomes even a current
characteristic of the organization. The success of the implementation can be judged at this stage.
As a summary of the literature review and following the three sets of attributes given by Adam-
Ledunois and Damart, (2016) framework’s, the literature review contributes to present a set of
elements and combinations of elements that describe agile methods (especially Scrum) on its
different dimensions. The analysis of the different trends in agile bodies of knowledge allows
to identify the different concepts, approaches, and structures associated with agile methods.
And the recent studies in agile methods adoption and diffusion create a set of current knowledge
from researcher. Furthermore, our literature review shows that management innovation is a
coherent framework for understanding the different implementation mechanisms launched by
large companies. What about in practice? Is the implementation of an agile method also
sequential? From which ingredients is made the generalization of an agile method in a large
organization? These are the questions addressed in next part of the article.

9
Methodology

Among different qualitative research strategies, we decided to choose the case study approach.
It is not attached to an epistemological paradigm and may be used to understand, explain, test
or generate a theory (Eisenhardt, 1989). Langley and Royer (2006) choose to define the case
study as a study of at least one case composed of a delimited system, and it allows to not exclude
few qualitative data collection strategies such as archival analysis and historical studies.
Different types of case studies exist, different according to the level of analysis, and whether
the process aspect is considered. Yin (2009) proposes a typology that distinguishes four designs
based on the number of cases, but also their embeddedness feature or not. The objectivity of a
case study rest on « multiple sources of evidence » (Yin, 2012).
We made the choice to set up the analysis of one case that is mainly based on the study of a
Research and Development department (R&D), with
different units of analysis, people working in this entity, the
Project Management Office, and projects in interactions with
the R&D department (figure 1). The advantage of adopting a
design like this one is above all supported by ensuring
consistency with our research object, where the phenomenon
is longitudinal. It seems also appropriate for detailed
reporting of complex organizational processes (Musca,
2006). Indeed, studying the adoption process of an MI
requires a strong presence in the field. The posture of the
researcher within the framework of this work favors access to
the privileged ground. As this research is part of a PhD thesis, FIGURE 1 : T HE CASE AND
we decided to launch a case study after a long exploratory ANALYSIS OBJECTS
phase, where we studied the factors that influence the
adoption process of agile methods (Berkani and Causse, 2017).
Case study introduction:
Alpha is one of the world's leading providers of advanced technology solutions for the travel
and tourism industry. Their products are principally composed of information technologies;
software web services, and tools bound for travel suppliers (airlines, hotels, railways and ferries,
etc.), travel sellers (travel agencies and websites) and travel buyers (businesses and travelers).
The group employs more than 14,000 people worldwide and has customers in more than 190
countries and has established offices in 70 countries around the world.
Our investigation mainly took place on France’s campus (where more than 6000 people are
working), which is the largest development center of the company. We were able to interact
with the initiators of the implementation of agile methods within Alpha. Added to this, we were
able to interact with the deployment agents within the Project Management Office, and we
could have discussions with top managers as an R&D manager. The interest of this case lies in
the fact that Alpha has launched a succession of initiatives for the last 7 years to deploy small
and large-scale agile methods. Thus, our research goal is to investigate how this large globally
distributed firm, organized the implementation of agile methods, to understand how they
engendered an evolution on the organization.

10
Data collection
Data collection began in October 2017 with a short-accelerated period in May 2018. During
this short period, we were in immersion on the campus of Alpha. The adoption of a management
innovation being defined as a process composed of different phases (Damanpour and Aravind,
2012) we collected process data mainly from semi-structured interviews, participant
observations, event narrations and documents. We systematically started our research by
putting in place a retrospective analysis to understand the antecedents as we were coming during
the adoption process. For more details about data collected, appendix A presents all interviews.
To sum up, we collected 10 semi-structured interviews, 5 non-participatory observations and
50 documents (with almost 500 pages in total).
Data Analysis
According to Dumez (2016), analysis based on coding can create a circularity phenomenon. In
order to favor objectivity to understand the phenomenon of agile transformation through the
management innovation implementation lens, we reconstituted temporal mechanisms and
conducted a process analysis coupled with a temporal modelling of major events. Data has been
transcribed and compiled using NVivo software. We have then coded the different verbatims
and documents by coding via a multi-thematic approach (Dumez, 2016). This methodology is
particularly adapted for heterogeneous material et allows us to avoid the circularity effect via a
certain triangulation of the different data sources.
Furthermore, as we are dedicated to study the how of the implementation of agile methods on
a large organization, we privileged a sequential analysis. It is also important to emphasize that
our communication being part of the work of a PhD thesis, analyses are still being formalized
and the results presented are preliminaries.

FIGURE 2 : DATA COLLECTION AND ANALYSIS RESUME

The analysis object of the case is the Alpha R&D department. It has the responsibility of
building innovative solutions for their customers worldwide. R&D is a strategic priority for
Alpha, a key factor in achieving market leadership and sustainable, profitable growth. Teams
conceive, design, develop and maintain real-time information systems, accessed daily by
hundreds of thousands of travels professionals and end users in almost all areas of the travel
industry. Alpha R&D investment is supported by a network of 19 R&D centers across the
world. France has the largest center for R&D activities. The R&D network is deployed
regionally using a model of hubs, with global coverage and transversal activities. All sites work
closely together, and teams for a project can be distributed among various sites.

11
Results

Results are presented by summing up the analysis of the four phases that were identified during
the coding of the data. The diagram below presents the synthesis of the results as a sequential
analysis of facts. This scheme (figure, 3) has made it possible to highlight the phenomenon of
agile transformation analyzed as a process, the different phases will be developed one by one
in the following sections. For each phase, we present the major difficulties found by illustrating
with the verbatim of the interviews conducted.

FIGURE 3 : ALPHA 'S AGILE TRANSFORMATION PROCESS

As a reminder, the analysis of the case was done by taking the phases of the adoption process
of a managerial innovation according to the model of (Damanpour and Schneider, 2006), the
objective was to answer three questions:
• How were agile methods introduced in Alpha? Referring to the answer to this
question will be developed on next session phase 1.
• How was the implementation of Scrum intended? Phase 2, 3 and 4 will expose how
Alpha organized its agile transformation.
• What changes in organizational configurations have led to deployment? In each
phase, we will develop the impacts.

12
Phase 1: From the PMBoK to the emerging introduction of Scrum
During this phase traditional project management methogologies are adopted (PMBoK,
CMMI). Agile introduction emerges progressively, based on individual initiative and
progressively spreads (bottom up) though a viral process.
When Alpha needs to develop a new solution for a customer, a project manager is assigned to
lead the development of the solution. As the organization is in a matrix form, the project
manager is not attached to a technical entity, so he is considered as an outside actor of the R&D
department. A project in Alpha gathers several actors to deliver solutions to its customer. And
each actor is attached to a different entity, we present here a simplified example:
- Developer (R&D): Designs the solution to render the needs in software solution.
- Software Quality Engineer (R&D): Collaborates with development to design and
develop test plans and test cases that guarantee high quality product features.
- Project manager (Business): Plans project resources and budget control and
coordinates internal development teams to ensure the flawless execution of the project.
- Product manager: works closely with the customer, spending time at the customer site
where applicable, R&D and product teams to lead the evolution of product lines.
- Account manager (Sales): Manages the regional commercial, financial, and legal
relationship directly with an appointed customer.
- Customer: Gives needs and scope to collaborate with the project team.

Adopting traditional approaches

Alpha began introducing a project management methodological approach in 2006, heavily
inspired by the Project Management Body of Knowledge (PMBok) version 2 at that time. To
encourage and insure adoption of the best practices listed in the body of knowledge, project
managers followed the PMI Project Management Professional certification.
As a result, the project manager role was more precisely defined. He ensures successful
definition, planning, execution and delivery of customer IT solutions and internal projects. For
project matters, he acts as the main contact point and coordination for all the stream owners
including; commercial teams, development units; implementation specialists and quality
assurance functions as well as the customer’s project teams.
The project management proactively manages the project budget, schedule, scope, risks and
changes; provides clear and consistent communication and direction on the project; and is
ultimately accountable for functional and technical coverage, quality and security of the
projects delivered (According to the PMO).
When they started introducing PMBoK practices, the company did not have PMOs. The
implementation of the project management methodology was not ensured by a specific entity
and there wasn’t yet a deployment and training entity to deploy this methodological framework.
From an organizational point of view, Alpha is structured as a matrix organization. That means
each of Alpha’s product has a transversal team belonging to other entities. However, each
product has multiple customers, and each customer will have many users at the international
level. But that organizational configuration reveals a certain complexity in maintaining
solutions.

13
“When the new R & D director arrived, he realized the complexity and the time it took to change
a feature” (According to a member of the PMO).
In 2007, top managers decided to set up an assessment based on the Capability Maturity Model
Integration (CMMI) evaluation in the R&D entity, this audit evaluates the engineering process
of software development. Following the evaluation, on a scale of five levels, their audit showed
that Alpha’s obtained a CMMI level 2. It means that a discipline is being implemented for each
project and is essentially materialized by a project plan. The project manager has a major
responsibility, he defines documents applies and maintains a plan. From project to project he
capitalizes and improves his project management and engineering practices.
Agile introduction by developers
The introduction of agile methods began in 2009, a team among the R&D department embarked
on the adoption of Scrum for a new project. They formalized the methodology in an excel file
allowing collaborators to share easily the approach among different development teams.
" Scrum was adopted by a team who thought: hey, there's a new agile method, shall we try it?
all the members wanted to experience it and finally it was a success" (According to a member
of the PMO).
The first experimentation of Scrum became a success, and the excel file has spread from teams
to teams. We observe an inter-team viral spread, through which developers shared and
improved scrum practices. At the same time, a notable fact is that the PMBoK is also gaining
momentum by the creation of a project managers community. From 2009 to 2012, scrum was
spreading and, Scrum of Scrum's5(SoS) first experiments were set up. The adoption of this
large-scale agile method is dedicated to synchronizing teams in a larger project. The different
experimentations lead to positives results too. The introduction of Scrum in development teams
is thus principally located at the operational level, without any clear support or sponsorship
from the top management, the idea was to try this approach on a large scale.
This first phase can be explained under the initiation phase of Damanpour and shneider, (2006).
Initiation includes steps such as problem perception, searching for solutions, evaluating the
solutions and selection. In the case of Alpha, the initiation was done by operational actors.

5
Scrum of Scrum is a large scale agile method that allows to synchronize several scrum teams.

14
Phase 2: How has the implementation been intended?
During this second phase, agile deployment was more structured and no longer bottom up.
Objective were given by the management; a maturity assessment was launched and after a first
realignment a first level of stabilization was reached.

Implementation of scrum at the instigation of a new R&D director

From a strategic point of view, Alpha began a strategic shift in 2012, focusing until then on
airline industry with few products, and decided to extend its product line to new types of
customers from airlines to train, hospitals and hotels companies. Still in 2012, a remarkable
fact was the arrival of a new R&D director. He quickly focused on the difficulty in delivering
projects, generated by the great complexity of the matrix organization and development process.
“His observations related in particular to the difficulty to update a feature in a product, it was
necessary to contact many actors in different departments” (According to a member of the
PMO).
As the new R&D director came from a performative software editor, and in accordance to the
turn taken in the global strategy of the firm, he wanted to enable product diversification in R&D
teams. In order to improve the maturity of project management in R&D, he decided in 2012,
under his leadership, to set up a central Project Management Office with local branches at the
international level. Their role was to maintain the methodological framework (at that time still
based on the PMBoK) relayed by local PMOs that promote ownership in a closer way with the
teams.
“He arrived with a certain background that gave Alpha an acceleration in this transformation,
I think it's undeniable” (According to a local PMO).
The spread of agility at the beginning of this phase is still bottom-up. It means, that Scrum is
adopted by teams and it is through teams that the method spreads. Given the presence of Scrum
in few development teams, and the positive effects induced in projects, the R&D director
encouraged the implementation of Scrum to all development teams. In order to simplify the
organization of the designing phase in project, the implementation of scrum becomes planned
by the direction in 2013.The R&D director decided to launch a transformation program to
deploy the agility in the sense of Scrum and Kanban for IT initially adopted. The target is
exclusively R&D oriented.
Structuration of the agile transformation program and achievements:
- Complete training programs, for all roles in R&D, all sites
- Involvement of a few non-R&D stakeholders
- Agile communities’ animation
- Agile coaching offering
- Model for Agile contract,
- knowledge sharing on Agile budget
- Standardization of Scrum and Kanban practices
- Deployment of Agile tooling – Jira

15
The program initiated, relies on coaching and internal events to raise awareness. The goal was
to push a massive implementation of Scrum for small teams. They planned to achieve 80% of
R&D teams working on this new mode.

Assessment of the effective adoption

In 2014, in order to assess the implementation, R&D top managers launched an agile maturity
assessment for all teams. The goal was to measure the effective adoption of Scrum in
development teams and to better understand how Scrum was set up. It was observed that many
development teams adopted Scrum, but the method was not respected faithfully
“We are normally all in scrum but we are not in scrum in the sense that we have no
ScrumMaster for example we have Scrum tester, we still have a team manager […] but if we
really wanted to apply agile as on paper we are not there at all.” (According to a project
manager).
As we introduced details about Scrum in the literature review, there were three main roles in a
Scrum team: The Product Owner, the Scrum Master and the Development Team. However,
many teams do not apply these roles, and others are working with sprints that are not
synchronized with others. A sprint length can vary from 1 to 4 weeks among diffrent teams.
Some R&D department heads have become Scrum Masters keeping a command & control
rather than promoting a shared responsibility. Culturally so far, the command & control
management style is still very present on the part of technical managers, this is due to the
technical expertise of some actors that reinforces their legitimacy.
"the management at Alpha is 20% people and 80% technical" (According to an agile coach).
Even if the goal is to standardize Scrum, the method was not mandatory for development teams,
many of them decided to keep on working in a traditional way revealing that a few actors were
not convinced with this new approach.
At this stage the effective adoptions from teams are far too scattered. Adoption is still
heterogeneous, within different teams, even though there was an implementation action
organized via a transformation program, Scrum is not standardized thus questioning the
ambition of the program.
“Some teams adopted scrum saying that it would give them less constraints in the project, so
it was understood as a let go transformation” (According to the Director of Development
Engineering Services).

16
An implementation initiative forgetting Human Resources:
Many actors during our investigations reported the lack of involvement of Human Resources
(HR). As Scrum proposes new roles, they have been adopted only in a “virtual way”:
“I do not know what they do, but the real problem is that at HR it takes time. It affects the
human to the definition of roles, perimeters, maybe wages[…] It also takes time because we
have very strong unions in France, and I do not even know if one day it will come out or if the
next transformation will arrive sooner.” (According a local PMO).
The virtual aspect refers to the fact that the actors and the processes are not very anchored in
the internal policies of the organization because the scope of deployment remains limited to
R&D. Project managers continue to be trained and certified on the PMBoK creating
dysfunctions in the collaboration between actors composing a project.
“the difficulties are really related to the coexistence of agile and waterfall, because it's difficult
to harmonize everything like monitoring and tracking tools, so for example, teams do not use
the same tools: those that are waterfall are on MS project when agile teams uses Jira.”
(According to a project manager).
Given the evaluation and lack of involvement of some stakeholders in the implementation, the
Agile Transformation Program Manager decided to take a few steps back to restructure a proper
implementation of Scrum.
“Despite the strong incentive to implement scrum, we decided to take a step backwards to
consolidate the achievements, and better prepare the rest of the deployment “(According to the
Director of Development of Engineering Services).
Following the assessment, in 2014 a new measure is created. Before launching a project in an
agile mode, a project pre-evaluation system was set up between the local PMOs and projects to
initiate the launch of the project in agile mode.

Challenges encountered during this phase:

Alpha’s journey to agile teams has not been without problems. As our analysis is still going on,
we summarise some of them in this section. The heterogeneity in the adoption reflected in the
previous paragraphs is divided in too levels:
R&D teams work in agile mode with Scrum whereas actors outside R&D apply the PMBoK
principles, creating real difficulties between actors as they do not use the same tools and key
performance indicators.
Second, in R&D development teams, the planned implementation via the Agile Program
Transformation does not condition the effective adoption from teams and questions how Scrum
is implemented. As Scrum is less formalized than traditional methods, people took Scrum as a
“light” method.
The assessment of the agile maturity level allowed the Agile Transformation Program manager
(including PMOs) to review the ambitions, by questioning for a common base that the projects
must respect. This led to set a better controlled framework for the implementation during the
program. Even if Alpha created a transformation program organization to deploy Scrum, the
implementation follows an experimental approach to the transformation.
17
Phase 3: Scaling and synchronizing Scrum teams
During the third phase, deploying agile at scale in the R&D department was the main objective.
Based on solid ground (especially on teams level) elaborated during phase2, new approaches
were tested and implemented based on mixed methodology: the Scrum of Scrum framework and
the Spotify scaled agile model.
Kicking off a new program to scale agile:
Following the maturity evaluation and the elaboration of a first stabilized set of practice, the
question progressively emerged of synchronizing Scrum at scale on the R&D department. In
January 2015 a new transformation program was therefore launched with the aim to move to a
larger scale. An agile leader used the following expression to explain the choice faced: "to adapt
our agile methodology, it was quite simple, either we could have bought it like SAFe framework
or we could have done it". It was finally decided to adapt existing methodologies for their
internal needs, the new method created being based on the scrum of Scrum framework and
Spotify6, they internally created their model called the Alpha Scaled Agile Model (ASAM) with
agile experts.
Enabling agile at scale implies more synchronized teams, fosters good collaboration, and better
integration of the final customer. Thus, new goals emerged and they were presented as follows:
First development teams should reduce the time to market, in the context of Alpha, the reduction
of the time to market means designing functionality faster. The second objective is to improve
responsiveness and adaptation in development teams, considering the different projects and
customers. And the third one is developing efficiency in project development through
synchronization. Thus, the R&D director decided to deploy the ASAM on a more synchronized
mode.
In September 2015, the Agility Program tried a new organizational form based on their new
internal framework. The result was the creation of Tribes, Guilds, Chapters and Squads in the
R&D department. This framework is heavily based on the Spotify model. Referring to the figure
4.
A Squads is a simple Scrum team with initial roles previously adopted: There is a Product
Owner (PO), the ScrumMaster and Developers (circled yellow on figure 4). A chapter is
dedicated to an area of expertise within a tribe (for example: the chapter of the testers). It is led
by a chapter leader whose role is to lead the group to develop feedback on their domain (actors
in the purple part of figure 4).
The guild is a more transversal community than the chapter because this type of community
crosses both "squads" and "tribes", it is an oriented community of interest (performance, coding
practices etc.) and is open to all who are interested (dotted line in blue of figure 4).
Finally, the tribe gathers all the previous areas described. The tribe is a group of teams working
on a similar product but within a different product perimeter. This grouping into tribes is a way
to manage the complexity, the size of the organization and the problems of coordination
between the teams. A tribe can contain between 40 and 120 people.

6
Spotify model, is an adaptation of agile practices by the Spotify teams to go at scale. It was made public in
2012 by Henrik Kniberg and Anders Ivarsson and has been widely used as a starting point for organizing large
agile teams. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

18
At Alpha, a tribe is dedicated to several project managers, where different teams and actors
work for different projects. Among them, the Product Owner (actor in red on figure 4) is the
person responsible for managing technical value, he works thus with project managers to collect
and prioritize customer needs.
Another new role is created that of the Tribe leader (In green on figure 4). Each tribe has a
leader whose main objective is to ensure that the teams of his tribe have the best environment
possible to exercise and deliver their products7 increments. The tribe leader can manage his
entire tribe and be a point of contact with other tribes. Finally, each Tribe also has an Agile
coach to support high performance. The agile coach (in blue on figure 4) is the agile expert who
will foster best practices.
On this new organizational mode, the PMO changed:
“There has been a big change on the PMO side, at Alpha there are plenty of local PMOs, they
are mainly attached to a unit, to a branch of the organization. Each PMO must ensure that the
guidelines are in place, there are many PMOs who have taken an agile cap. They make sure
that the recommended practices are put in place. Before a team launches, it must see its PMO
and do the pre-launch evaluation.” (According to a local PMO).

FIGURE 4 : ALPHA ’S SCALED AGILE ORGANIZATION

In 2016, nearly 3,000 people were affected by this new configuration at the international level,
representing a total of 13 tribes in total. To support this new form of organization while
involving remote teams, the Jira8 tool has been adopted to foster agile remote collaboration.

Alpha moved from a traditional organizational model featuring sub departments in the R&D
entity such as Software Quality Assurance, Architect, and developers, to a cross functional

7
A product in this context describe the software delivered.
8
JIRA provides a mature, powerful toolset to maintain a backlog, customizations to meet specific project needs.
This includes custom fields, issue types, workflows, notifications, and user entry screens.

19
teams model that shares much in common with the Spotify example. In 2017, the ASAM
organization is maintained, and the objective is to imply the final customer in projects.

Challenges encountered during this phase:

Agile methods were initially thought to work with self-organized, collocated and close-to-
customer teams. It is in this context that the benefits are the most important, and at Alpha, the
project context is moving away from these ideal conditions:
- Tribes will serve several project managers, who serves multiple clients. The project
manager thinks about the imposed scope of his client, when the tribe is totally dedicated
to several projects.
- The unresolved difficulty that has arisen concerns the communication et alignment of
indicators between project managers and tribes in this new phase. Solutions were found,
however a real problematic of appropriation appeared, when the indicators were not
applied.
- In terms of the project's performance indicators, it made the project's approach of project
managers much blurrier: with a sense of “losing control”.
- The difficulty encountered by certain teams concerns the client's desire not to be
involved in the design of their product. Customers are not sensitive to the internal design
approach.
- In parallel, there is always the methodology resulting from the PMBoK set up. In terms
of tools, MS project software is also in place to monitor the progress of the project. So,
the difficulty encountered at this stage is that the end customer is represented by the
project manager who relies on the tool via MS project and the tribes manage the
requirements via Jira.
- Even if some customers may have been informed about he benefits of agile,
paradoxically, the inertia of the external client blocks the proper implementation of the
methodological approach.
- Finally, even if agile methods promote more self-organization, as alpha has been
inspired in the methods chosen, hierarchy is still in place on the R&D department
(Figure 5).

FIGURE 5 : O RGANIZATIONAL EVOLUTION IN ALPHA ’S R&D ENTITY

20
Phase 4: globalization of the agile transformation
Agile at scale deployment in the R&D department has now largely recognized. But agile teams
continue to encounter difficulties that slow down effective agile appropriation. The question of
an agile implementation that covers all the organization, including the business department
(and their project manager) working with R&D will be addressed in the new phase.
In 2018 a new agile transformation program was launched aiming at a more global
generalization of Agile, going beyond the R&D department, including project managers in
business units and final customers. The implementation is still under experimentation and the
R&D director decided to implement a new framework (consistent with ASAM). It was decided
to use the SAFe framework for this new phase and to adapt it to their needs.

This phase, as our analysis is still ongoing. Difficulties lie in the complexity generated by
interaction that are no longer limited to the R&D department. It will be interesting to see how
long it takes for a new level of new level of stabilization to be obtained and if this will first
imply a reduction of ambition, as was the case for the R&D department in phase 2.

The main challenge encountered at this phase, is the fact that the scale is higher than the
previous one: the number of actors; the non-homogeneous culture between services; the
coexistence with PMBoK method and if all the previous challenges unresolved during on phase
3 could hinder the implementation.

Summary of the phases:

FIGURE 6 : ROADMAP AND DYNAMIC IMPLEMENTATION OF AGILE METHODS

21
The agile transformation of Alpha can be illustrated in a succession of phases and stable level
of generalization as illustrated in figure 6. Stable level of implementation, is a stable state on
which the company was able to elaborate the next phases. The following step are clearly
revealed by the observations:
• Step #0 – no agile framework is yet deployed, but traditional project management is well
established.
• Step #1 – agile practice and framework (Scrum) is established ad is used for a planned and
progressive generalization. First level of agile at scale is integrated in an adapted agile
framework based on Scrum of Scrum and Spotify.
• Step# 2 – is not yet established but Alpha is working on the way to define a new version of
the framework enabling a wider adoption of agile methods and organization going beyond
the R&D department.
A dynamic behind the process of generalization seems to appear in the figure above. Even if
the last phase is still in progress, the process can be described as a succession of accelerating
stages followed by a stabilization enabling the next phase of generalization. The dynamic is
therefore not just a linear process but rather an iteration on construct/learn/adapt cycle).

Conclusion
As reminder, this article aimed at answering the research question: How is the implementation
of agile methods organized across a large organization? We proposed a qualitative research
approach via a case study. Based on the literature in management innovation, we explained
from a managerial standpoint the agile transformation phenomenon, by firstly presenting how
Scrum could be considered as an established management innovation (Hatchuel and David,
2007) in the literature review.
This paper makes several contributions to the innovation literature. First, it focuses on the
adoption and implementation of a managerial innovation on a macro level, an under-researched
type of innovation, and includes two major components about it. Our analysis allowed us to
highlight the non-linearity of a management innovation adoption process. The construction of
the sequences allows us to illustrate that the three phases proposed by Damanpour and
Schneider, (2006), are in practice repeated on each sequence of the case analyzed. This result
allows us to propose an extension of sequential model which can be characterized as a cyclic
model with continuous repetition of it.
From a practitioner’s perspective, we contribute to increase the capacity of companies to design
adapted project approaches and present the organizational evolutions engendered by the
implementation of agile methods (organizational engineering). We provide an understanding
grid of the phenomenon to the many organizations starting the implementation of agile methods.
Our research is not without limits as these works are still in progress. As our coding
methodology is partly based on the adoption phases proposed by Damanpour and Schneider
(2006), at the methodological level, it can induce circularity in results. To strengthen the
sequential analysis of the facts, an analysis of counterfeits should be done (Dumez, 2016). The
adoption of a management innovation is a long and complex process, the presence time and the
access to the data must be significant we should so multiply data sources to favor triangulation
and confirm future analysis.

22
References:
Adam-Ledunois, S. and Damart. S., 2016, « Innovation managériale… ou pas ? Design d’une
méthodologie d’analyse critique des objets de management ». AIMS, Hammamet, Tunisie.

Ambler SW (2012) Disciplined Agile Delivery: a practitioner’s guide to agile software

delivery in the enterprise. IBM Press

Berkani, A. and Causse, D., 2018. Enquête sur les caractéristiques du processus de la
transformation agile : focus sur les agents de la transition. In 23ème conférence de
l’Association Information et Management. Montréal, Canada.

Takeuchi, H. and Nonaka, I., 1986. “The New New Product Development Game”. Harvard
Business Review, 64(1), pp.137–146. Available at: https://hbr.org/1986/01/the-new-new-
product-development-game.

Birkinshaw, J., Hamel, G. and Mol, M.J., 2008. “Management Innovation”. Academy of
Management Review, 33(4), pp.825–845.

Boehm, B., 2002. “Get ready for agile methods, with care”. Computer, 35(1), pp.64–69.

Conforto, E.C. et al., 2016. « The agility construct on project management theory.”
International Journal of Project Management, 34(4), pp.660–674.

Damanpour, F., 2014.” Footnotes to research on management innovation.” Organization

Studies, 35(9), pp.1265–1285.

Damanpour, F. and Aravind, D. 2012, “Managerial Innovation: Conceptions, Processes, and

Antecedents.” Management & Organization Review, 8(2) pp. 423-454.

Damanpour, F. and Schneider, M. 2006, Phases of the Adoption of Innovation in

Organizations: Effects of Environment, Organization and Top Managers. British Journal of
Management, 17(3), pp.215-236.

Damanpour, F. 1991, Organizational Innovation: A meta-analysis of effects of determinants

and moderators. Academy of Management Journal, 34(3), pp.555-590.

Damanpour, F. and Wischnevsky, D. J. 2006, “Research on innovation in organizations:

Distinguishing innovation-generating from innovation-adopting organizations.” Journal of
Engineering and Technology Management, 23(4), pp.269-291.

Damanpour, F., Walker, R. M. and Avellaneda, C. N. 2009, “Combinative Effects of

Innovation Types and Organizational Performance: A Longitudinal Study of Service
Organizations. Journal of Management Studies.” 46(4), pp.650-675.

Daneva, M. et al., 2013. Agile requirements prioritization in large-scale outsourced system

projects: An empirical study. Journal of Systems and Software, 86(5), pp.1333–1353.

David, A., 2018. Understanding the invention phase of management innovation: a design
theory perspective. European Management Review.

23
David, A. et A. Hatchuel.,2007, « From actionable knowledge to universal theory in
management research », Handbook of Collaborative Research, SAGE.

Diegmann, P. et al., (2018). Journey Towards Agility: Three Decades of Research on Agile
Information Systems Development. In International Conference on Information Systems. pp.
1–17.

Dingsøyr, T. et al., 2012. A decade of agile methodologies: Towards explaining agile

software development. Journal of Systems and Software, 85(6), pp.1213–1221.

Dikert, K., Paasivaara, M. and Lassenius, C., 2016. Challenges and success factors for large-
scale agile transformations: A systematic literature review. Journal of Systems and Software,
119, pp.87–108.

Dybå, T. and Dingsøyr, T., 2008. Empirical studies of agile software development: A
systematic review. Information and Software Technology, 50(9), pp.833–859.

Eisenhardt, K. M. (1989), Building Theories from Case Study Research. The Academy of
Management Review, 14(4), pp.532-550.

Furuhjelm, J. et al., 2017. Owning the Sky with agile: Building a Jet Fighter Faster, Cheaper,
Better with Scrum. www.scruminc.com, pp.1–4

Gandomani, T. and Nafchi, M., 2015. An empirically-developed framework for Agile

transition and adoption: A Grounded Theory approach. Journal of Systems and Software, 107,
pp.204–219.

Giuliani, P., Robert, M. and Roy, F. Le, 2018. Reinvention of management innovation for
successful implementation. International Journal of Entrepreneurship and Small Business,
34(3), p.343. Available at: http://www.inderscience.com/link.php?id=92747.

Gopalakrishnan, S. and Damanpour, F., 1997, A review of innovation research in economics,

sociology and technology management. Omega, 25(1), pp.15-28.

Hlady Rispal, M., 2002, La méthode des cas. Application à la recherche en gestion. Bruxelles:
De Boeck. Belgium.

Hollen, R.M.A., van den Bosch, F.A.J. and Volberda, H.W., 2013, ‘The role of management
innovation in enabling technological process innovation: an inter-organizational perspective’,
European Management Review, Vol. 10, No. 1, pp.35–50.

Jiang, L. and Eberlein, A., 2009. An analysis of the history of classical software development
and agile development. Conference Proceedings - IEEE International Conference on
Systems, Man and Cybernetics, pp. 3733–3738.

Jovanović, M. et al., 2017. Transition of organizational roles in Agile transformation process:

A grounded theory approach. Journal of Systems and Software, 133, pp.174–194.

24
Keupp, M. M., Palmié, M. and Gassmann, O., 2011, The Strategic Management of
Innovation: A Systematic Review and Paths for Future Research. International Journal of
Management Reviews.

Kimberly J.R. 1981. “Managerial innovation”, Handbook of organizational design, Nystrom

P.C. et Starbuck W.H., vol. 1, Oxford University Press, New York, p. 84-104.

Korhonen, K., 2013. Evaluating the impact of an agile transformation: a longitudinal case
study in a distributed context. Software Quality Journal, 21(4), pp.599–624. Available at:
http://link.springer.com/10.1007/s11219-012-9189-4 [Accessed June 13, 2017].

Laanti, M., 2017. Agile transformation model for large software development organizations.
Proceedings of the XP2017 Scientific Workshops on - XP ’17, pp.1–5. Available at:
http://dl.acm.org/citation.cfm?doid=3120459.3120479.

Laanti, M., Salo, O. and Abrahamsson, P., 2011. Agile methods rapidly replacing traditional
methods at Nokia: A survey of opinions on agile transformation. Information and Software
Technology, 53(3), pp.276–290.

Larman C, Vodde B (2015) Less framework. http://less.works/

Leffingwell. D (2015) Scaled agile framework. http://scaledagileframework.com/

Majchrzark, A., Markus, M.L. and Wareham, J., 2016. Designing for Digital Transformation:
Lessons for Information Systems Research From the Study of ICT and Societal Challenges.
MIS Quarterly, 40(2), pp.267–278.

Mikalsen, M., Moe, N.B. and Nyrud, H., 2018. Agile Digital Transformation: A Case Study
of Interdependencies. In ICIS - International Conference on Information Systems. pp. 1–9.

Miles, M. B. and Huberman, M. A. 2003, Analyses des données qualitatives: De Boeck

Mol, M. J. and Birkinshaw, J. 2009, The sources of management innovation: When firms
introduce new management practices. Journal of Business Research, 62(12), pp.1269-1280.

Musca, G. 2006, « Une stratégie de recherche processuelle : l’étude longitudinale de cas

enchassés », M@n@gement, 9(3), pp. 145-168.

Nerur, S., Mahapatra, R. and Mangalaraj, G., 2005. Challenges of migrating to agile
methodologies. Communications of the ACM, 48(5), pp.72–78.

Paasivaara, M. et al., 2018. Large-scale agile transformation at Ericsson: a case study.

Empirical Software Engineering, pp.1–47.

Project Management Institute (PMI). 2017. A guide to the project management body of
knowledge (PMBOK® guide)—sixth edition. Newtown Square, PA: Author.

25
Qumer, A. and Henderson-Sellers, B., 2008. A framework to support the evaluation, adoption
and improvement of agile methods in practice. Journal of Systems and Software, 81(11),
pp.1899–1919.

Rico, D.F., Sayani, H.H. and Field, R.F., 2008. History of Computers, Electronic Commerce
and Agile Methods

Rogers, E. 1995, Diffusion of innovations: New York : Free Press

Senapathi, M. and Srinivasan, A., 2012. Understanding post-adoptive agile usage: An

exploratory cross-case analysis. Journal of Systems and Software, 85(6), pp.1255–1268.

Sidky, A., Arthur, J. and Bohner, S., 2007. A disciplined approach to adopting agile practices:
the agile adoption framework. Innovations in Systems and Software Engineering, 3(3),
pp.203–216.

Soundararajan, S. and Arthur, J.D., 2009. A soft-structured agile framework for larger scale
systems development. In Proceedings of the International Symposium and Workshop on
Engineering of Computer Based Systems. IEEE, pp. 187–195.

Sutherland, J., and Schwaber, K. (2013). The scrum guide. The definitive guide to scrum: The
rules of the game. Scrum. org, 268.

The Standish Group, 2011. CHAOS Manifesto 2011. Accessed June, 2011, The Standish
Group (Retrieved from http://standishgroup.com/newsroom/chaos\_ manifesto\_2011.php).

Thiétart, R. A. 2014. Méthodes de recherche en management-4ème édition. Dunod.

Vaccaro I.G., Jansen J.J.P., Van Den Bosch F.A. et Volberda H.W. (2012). “Management
innovation and leadership: The moderating role of organizational size”, Journal of Management
Studies, vol. 49, p. 28-51.
Van de Ven A.H. 1986. “Central problems in the management of innovation”, Management
Science, vol. 32, n° 5, p. 590-607.

VersionOne. 2017. 11th annual state of agile report. Retrieved from

https://www.versionone.com/about/press-releases/versionone-releases-11th-annual-state-of-
agile-report/

Walker, R.M., Chen, J. and Aravind, D., 2015. Management innovation and firm
performance: An integration of research findings. European Management Journal, 33(5),
pp.407–422. Available at: http://dx.doi.org/10.1016/j.emj.2015.07.001.

Yin, R. 2009, Case study research : design and methods (4th Revised edition ed.): SAGE
Publications Inc.

Zmud, R. W. (1982). Diffusion of Modern Software Practices: Influence of Centralization and

Formalization. Management Science, 28(12), pp 1421–1431.

26
Appendix A: Semi-structured interviews data base

27