Agile Change Management Framework

Agile Change Management
How agile concepts can be used to manage change processes
Kristoffer Ramberg Karud
Kristoffer Vestaberg Årvik
December 2016
PROJECT THESIS
Department of Industrial Economics and Technology Management
Norwegian University of Science and Technology
Supervisor 1: Hanne Olofsson Finnestrand
Supervisor 2: Nils Brede Moe

i
[This page intentionally left blank]

ii
Preface
This is a project thesis in strategic change management at NTNU as part of the study programme
Industrial Economics and Technology Management. The work in this thesis has been carried
out during the autumn semester of 2016. The idea for the subject of agile change management
came from conversations with a major Norwegian company, discussions with our supervisors,
and the personal interests of the authors. In this thesis we review current literature within the
fields of change management and Agile. Afterwards, we present and discuss our framework for
change management based on agile concepts. This thesis is primarily written for readers with
knowledge of change management, agile concepts, or both. However, it will also have value for
anyone with an interest in the subject of agile change management.
Trondheim, 2016-12-19
Kristoffer Ramberg Karud
Trondheim, 2016-12-19
Kristoffer Vestaberg Årvik

iii
Acknowledgment
We would like to thank everyone who has supported us or given feedback during our work with
this thesis. A special mention goes to our supervisors Hanne Olofsson Finnestrand and Nils
Brede Moe. We would like to thank Dr. Finnestrand for valuable feedback through all stages of
this thesis. With her knowledge of teams, lean, change management, academic writing and her
keen eye for structure, she has provided input and support for many aspects of this thesis. We
would also like to thank Dr. Moe, with his prominent knowledge of all aspects of Agile. He has
provided us with relevant literature, given relevant feedback on our work, and helped us reach a
deeper understanding of Agile.
K.R.K. and K.V.Å.

iv
Summary and Conclusions
In this thesis we present our framework for agile change management based on a literature re-
view of change management and agile concepts. Because the field of agile change management
is relatively unexplored, many of the agile concepts used are based on concepts from agile soft-
ware development, which is a more mature field than agile change management.. The main idea
in Agile is that complex and unpredictable environments require flexible organisations that can
respond quickly to change. How this can be achieved with agile change management is dis-
cussed throughout this thesis.
In chapter 2 and 3, we review the relevant literature on change management and agile con-
cepts. We find that while both change management and agile software development are well
researched subjects, the combination of the two, which is the subject of agile change manage-
ment, is relatively unexplored in academic literature. After identifying challenges in the change
management literature related to flexibility, we present our agile change management frame-
work in chapter 4, which incorporates agile concepts to help solve these challenges. This frame-
work is based on an autonomous change management team that implements change through
an iterative process. We argue that this approach gives a high degree of flexibility, as the process
can change direction based on feedback from each iteration. The self-managing autonomous
teams work towards goals set by the the top-management, but are responsible for implementing
any change they see fit on order to meet these goals.
In chapter 5, the literature from chapters 2 and 3 is used as a basis for analysing the potential
of the agile framework for change management presented in chapter 4. This is done by com-
paring our agile framework to two widely used change management practises: Kotter’s 8-step
process, and the aspects of Lean concerned with change. The comparison will discuss five dif-
ferent aspects of change management; process, content, drivers, outcome and context. We find
that Agile has potential advantages within all five aspects.
Our finding is that the agile change process is flexible because it allows feedback from each
iteration. This makes it easier to make changes during the process. Concerning content, we find
that Agile is a good option for managing change in unstable environments, as it can be used to
explore creation of new products, new markets or new customers by using the change iterations

v
to experiment. We argue that the most important change driver in agile change management
is experience, through what we define as middle-out management. This is also concerned with
implementing change based on experimental experience. In addition, by changing the goals
and team composition of the agile change management team, one can balance the top-down
and bottom-up influences. When it comes to outcome, agile change management is suited for
producing both evolutionary and revolutionary change. The main advantage that agile change
management has in this aspect is the ability to navigate between the two, depending on how
stable the current environment is. However, we argue that agile change management is better
suited for organisational contexts characterised by unstable environments, because both Kotter
and Lean are more specialised for change management under stable conditions. We do, how-
ever, find that agile change management is dependant on an organisational culture suited for
self-management and a national culture with a low power distance. This is important in order
for the autonomous teams to be effective.
Throughout this thesis the potential advantages of agile change management are argued
theoretically. The presented framework has yet to be empirically tested. This will be the logical
next step in order to further develop the framework.

Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Summary and Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
1 Introduction 2
1.1 Literature Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Change management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Agile concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.3 Current change management practises . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Research Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Structure of the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Change Management 8
2.1 Definition of change management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Different views on strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 The paradoxes of strategic management . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Deliberateness and emergence in strategy formation . . . . . . . . . . . . . . 11
2.3.2 Exploitational and explorational innovation . . . . . . . . . . . . . . . . . . . 12
2.3.3 Organisational control and chaos . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.4 Revolutionary and evolutionary change . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Current change management practises . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.1 Kotter’s 8-Step Process for Leading Change . . . . . . . . . . . . . . . . . . . . 14
2.4.2 Lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Autonomy in Organisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
vi

CONTENTS vii
3 Agile Concepts 19
3.1 Agile software development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 Agile and non-Agile software development frameworks . . . . . . . . . . . . 20
3.1.2 Agile outside of software engineering . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Large-Scale agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Agile adoption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1 Challenges when adopting agile . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.2 Culture and Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 An agile framework for change management . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.1 Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Defining Agile Change Management 29
4.1 The need for flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Agile principles in change management . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.1 Autonomy and iterations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5 Comparing Agile and Current Change Management Practises 33
5.1 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.1 Planned and emergent change . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.2 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.1 Exploitative and exploratory change . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.2 Length and success criteria of iterations . . . . . . . . . . . . . . . . . . . . . 38
5.3 Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.1 Empowerment and autonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.2 Top-down and bottom-up change management . . . . . . . . . . . . . . . . . 40
5.3.3 Middle-out management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.4 Strategy E and Strategy O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.4 Outcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4.1 Revolutionary and evolutionary change . . . . . . . . . . . . . . . . . . . . . . 43
5.5 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

CONTENTS 1
5.5.1 Inner and outer context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.6 Advantages of Agile Change Management . . . . . . . . . . . . . . . . . . . . . . . . 48
5.7 Organisations that can benefit from agile change management . . . . . . . . . . . . 49
6 Summary 51
6.1 Summary and Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2 Recommendations for Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Bibliography 55

Chapter 1
Introduction
Change management is according to De Wit and Meyer (2014, p.384) concerned with aligning
the organisation to the environment. One of the greatest challenges in change management
is the unpredictable nature of change, as stable periods in the environment are disrupted by
instability (De Wit and Meyer, 2014, p.401). As organisations become more complex, and the
environment changes more rapidly, it becomes increasingly more difficult to manage change
processes. This is, however, not a challenge that is unique for change management. Manage-
ment of software development has faced many of the same challenges, which caused the devel-
opment of Agile development processes in this field (The Agile Manifesto, 2001).
Agile is a concept focused on responding quickly to change. Agile processes in software are
processes designed to provide a readiness for rapid change, in order to deliver customer value
in changing environments (Dingsøyr et al., 2012). One aspect of agile that is central in achieving
this readiness is an iterative approach to the work. This involves breaking the work into sub-
processes, that are executed in short cycles. In each cycle, or iteration, a new delivery is made.
This enables rapid feedback at the end of each iteration, allowing for modifications in the next
iterations and adapting to changes that occur.
This thesis will discuss the possibility of applying concepts and practises from agile software
development to change management in order to deal with the complexity and uncertainty that
organisations are facing today. Agile has proven to be more successful than traditional plan-
driven development methods in software engineering (Ambler, 2014). Recently, agile as a con-
cept has gained traction in other fields as well (Dingsøyr et al., 2012). We argue that applying ag-
2

CHAPTER 1. INTRODUCTION 3
ile concept and practises to change management, can help organisations increase the flexibility
of their change processes. We argue that this would make them better suited to handle complex
and evolving environments, which may potentially increase the success rate of the change pro-
cesses. We start by conducting a review of current literature of change management and agile
as a concept, before we present and discuss our framework for agile change management.
The topic of agile change management is first and foremost interesting because of the prac-
tical implications. In this thesis we have developed an agile framework for change management,
which can help meet the demand for flexibility in the field of change management. This could
result in more successful change initiatives in organisations, as they are potentially enabled to
react to external changes quicker. Exploring how Agile processes are used in software develop-
ment, and how these practises can be applied to change management, may cause organisations
to reconsider how they manage change projects. If the agile approach proves to be suited for
managing change this thesis could have practical implication for companies in many different
sectors. Agile approaches could prove to be a revolution in change management, and an agile
framework for managing change would then have great implications for businesses world-wide.
This thesis can also have great theoretical value, because there are relatively little existing lit-
erature on the subject of agile change management. There is more literature on the topic of agile
software development, but the application of agile concepts to change management is relatively
unexplored in research. Studying this topic may give an indication of how agile approaches can
be used to manage change initiatives. Because this topic is relatively scarcely explored in aca-
demic literature, this thesis can be a valuable contribution.
The main research question this thesis will seek to answer is:
"How can Agile concepts be used to manage change processes?"
To answer this, we will answer the following two sub-questions:
1. "Which aspects of agile software development methodologies can be applied to change
management?"
2. "What are the advantages of utilising agile concepts in change management?"

These two sub-questions lay the the foundation for the agile framework for change man-
agement this thesis presents. This framework will answer our main research question, as it will
present how agile concepts can be used to manage change processes.
1.1 Literature Survey
This section introduces the most relevant literature that is used throughout this thesis. All
frameworks introduced here will be discussed in greater detail in chapter 2 and 3. The focus
in this section is to introduce key concepts, and describe why and how they are used in this
thesis.
1.1.1 Change management
In order to answer our research questions, we conceptualise change management by defining
change to consist of five different aspects. These five aspects are processes, content, drivers,
context, and outcome. This is a model based on a combination of Pettigrew (1985, as cited
in Kuipers et al., 2014), Pettigrew et al. (2001, as cited in Kuipers et al., 2014), and Jacobsen
(2012). Pettigrew (1985, as cited in Kuipers et al., 2014) and Pettigrew et al. (2001, as cited in
Kuipers et al., 2014) initially defined that context, content, process, and outcomes should be
considered when studying change, and Jacobsen (2012) suggests adding ’change drivers’ to the
model. The five aspects will be described in more detail in section 2.1. This model allows change
management to be broken down into five distinct parts, which can be discussed and analysed
separately.
To study the five aspects of change management we utilise four strategic paradoxes, intro-
duced by De Wit and Meyer (2014). The paradoxes that will be used in this thesis are the para-
doxes of deliberateness and emergence, exploitation and exploration, control and chaos, and
revolution and evolution. The different perspectives on these paradoxes will be presented in
section 2.3. De Wit and Meyer (2014) is chosen, because of the book’s attempt to give an objec-
tive overview of strategy, with its focus on paradoxes. The book acknowledges the complexity of
strategy, and that there is not one clear answer to how change should be implemented.

1.1.2 Agile concepts
In order to identify the aspects of Agile software development which can be applied to change
management, and answer our first research sub-question, we start by defining the concept of
Agile based on the The Agile Manifesto (2001). Dingsøyr et al. (2012) is then used to discuss how
Agile is used today, as it is a literature study that examines the 11 years of development that agile
methods have seen in software development. This includes the development of several agile
frameworks for software development.
Sommerville (2011) describes different agile frameworks, which we use to exemplify how ag-
ile concepts are used in practice. One of the most central of these frameworks is Scrum, which
will be discussed in section 3.1.1. Two central aspects of Scrum are the use of autonomous teams
and iterative processes (Sommerville, 2011). Concepts from the frameworks for agile software
development will be used to define our framework for agile change management. Another key
framework that our framework is based on, is Franklin (2014). This is a framework for agile
change management that is centred around using iterative processes to manage change. How-
ever, Franklin (2014) is not a comprehensive agile framework, as it lacks central agile aspects
like autonomy and experimentation that are included in our framework. Franklin (2014) will be
discussed in detail in section 3.4.
1.1.3 Current change management practises
To answer our second research sub-question concerned with identifying advantages of agile
change management, we compare our framework for agile change management to current change
management practises. The practises that will serve as a basis for comparison are Kotter 8-step
process and Lean.
Kotter (2007) will be used as an example of a traditional, plan-driven framework for change
management. This article is chosen because the eight-step process for leading change (Kotter,
2007) is one of the most used frameworks in the field, and is cited more than 5000 times accord-
ing to Google Scholar (2016). The framework is also a good example of a traditional plan-driven
model, as it is based on implementing change through a series of planned steps in a sequential
process. Kotter’s framework is described in section 2.4.1.

Our agile change management framework will also be compared to Lean, because Lean is a
widely used approach to change in different industries, and have influenced a large part of the
academic literature on the subject of change management. Lean is focused on process improve-
ment and flow-efficiency (Modig and Åhlstrøm, 2012). Lean is described in section 2.4.2
This concludes the survey of the most central literature used in this thesis in order to answer
our research question.
1.2 Research Method
This thesis is a qualitative literature review, where we create a theoretical framework from exist-
ing literature and theory. Due to the lack of existing quantitative data on the subject, this thesis
has a qualitative approach (Bryman, 2016, p.311).
Our literature review has been carried as a narrative review (Bryman, 2016, p.91). This means
we seek to reach an overview of the fields of study through a reasonably comprehensive assess-
ment and critical interpretation of the literature (Bryman, 2016, p.91). We then create a frame-
work based on the literature. The review provides a background for the framework, and serves
as a platform for our own contributions (Bryman, 2016, p.91).
When sampling literature for our literature review we used purposive sampling (Bryman,
2016, p.410). This was used in order to pick the most relevant books and articles on the subject
(Bryman, 2016, p.410). An example of this is that Pettigrew (1985, as cited in Kuipers et al.,
2014), Pettigrew et al. (2001, as cited in Kuipers et al., 2014), and Jacobsen (2012) were chosen to
define different aspects of change management as we believe the combination of them provide
a comprehensive view on change. Another example is that Kotter (2007) was chosen to represent
plan-driven change, as we argue it is one of the most used plan-driven frameworks for change
management.
The specific sampling method used was generic purposive sampling (Bryman, 2016, 412)
with elements of snowball sampling (Bryman, 2016, 415). Generic purposive sampling was used
as it would be difficult to reach the theoretical saturation required for theoretical sampling (Bry-
man, 2016, p.411). This would require covering all possible aspects of both change management
and agile processes. Elements from snowball sampling were also used when researching Agile,

since we used the literature we found from an Internet-based search to find more literature on
the subject. An example of this is that we after reading the articles Gandomani et al. (2013a) and
Gandomani and Nafchi (2016) found the need to research the relationship between Agile and
organisational culture further, leading us to Sahota (2012) and Spayd (2010).
Our main methods for collecting literature have been literature from the curriculum of the
study programme, contributions by supervisors and Internet-based searches. The Internet-
based searches have been for the most part conducted on Oria and Google Scholar, searching
for subjects related to agile change management.
1.3 Structure of the Report
The rest of the report is organised as follows: Chapter 2 reviews the existing literature within
change management with focus on the different aspects of change management and the differ-
ent approaches to manage change. Chapter 3 then gives an introduction to the concept of Agile,
with focus on different agile software development practises. Chapter 4 formulates a definition
of agile change management based on the different aspects of change management described
in chapter 2, and agile practises described in chapter 3. Chapter 5 then compares agile change
management to current practises for managing change. Finally, chapter 6 presents a summary,
conclusions, discussion and recommendations for further work.

Chapter 2
Change Management
In this chapter we present literature on change management. Special emphasis will be put on
challenges in managing change that could potentially be solved using Agile concepts in order to
answer our research question.
2.1 Definition of change management
To understand and conceptualise change management, one has to start with what is being
changed; the organisations. According to Harold Leavitt (1965, as cited in Jacobsen, 2012, p.65-
68) an organisation consists of tasks, people, technology and structure. The first three of these
constitutes the production core. With the tasks that the organisations is set to solve, the people
as the executing part and the technology that is utilised by the people to carry out the tasks (Ja-
cobsen, 2012). The structure is the framework that governs the production core. Change Man-
agement in this context is, therefore, concerned with changing one or more of these aspects of
the organisation.
Pettigrew (1985, as cited in Kuipers et al., 2014) and Pettigrew et al. (2001, as cited in Kuipers
et al., 2014) identify four elements of change which is used to understand change management.
These are change content, context, process and outcome. Jacobsen (2012) adds ’Change drivers’
to Pettigrew’s model, but Jacobsen’s model does not include the change outcome which Petti-
grew’s model does. We base our model and analysis on all five aspects:
• Change Content: A change of an organisation can have many different kinds of content.
8

CHAPTER 2. CHANGE MANAGEMENT 9
It can be a change of either strategy or one of the elements from of the organisation: tasks,
people, technology and structure (Jacobsen, 2012, p.65). In addition, a change can be big
or small, it can take a new direction, or involve something new in the same direction.
• Change Context: A change takes place in a given context. This means that there are fac-
tors concerning the organisation and the environment that organisations exists in that has
an effect on the capacity of an organisation to absorb and adapt to impulses from the en-
vironment (Jacobsen, 2012, p.91-92). Context is often split into inner- and outer-context,
where inner context is concerned with technology, strategy, structure, culture, power rela-
tions, size, age, slack and history. Outer-context is concerned with regulations, normative
relations, cognitive-relations and stability. All of these factors affect an organisation’s abil-
ity and willingness to change (Jacobsen, 2012, p. 116).
• Change Process: Change has to be studied as a set of processes where people act and co-
operate, based on many causes and with different purposes. Planned change implies that
somebody starts a set of activities to create change in behaviours, structures or cultures
(Jacobsen, 2012, p.117). This aspect covers the planning of change, and how it is carried
out
• Change Drivers: Change drivers are according to Van de Ven and Poole (1995, as cited in
Jacobsen, 2012) defined as fundamentally different sequences of events and causal mech-
anisms that explains how and why change exists. There are many different perspectives on
what drives a change process. In this thesis we will be most concerned with change driven
either top-down, where the company management will be the most important change
driver, or bottom-up, where the employees are the most active change drivers.
• Change Outcome: The change outcome is the product of the change process, and will
be shaped by the content, context, and drivers. The change outcome is manifested as
a difference in one or more parts of the organisation, as previously discussed; the tasks,
people, technology, or structure of the organisation.
Figure 2.1 shows how the change content, context, processes, and drivers all contribute to
the change outcome. The figure represents the aggregated model, with elements from Pettigrew

(1985, as cited in Kuipers et al., 2014), Pettigrew et al. (2001, as cited in Kuipers et al., 2014), and
Jacobsen (2012).
Figure 2.1: Aspects of change
This model constitutes the definition of change management that will be used throughout
this thesis. The discussion in chapter 5 will use this model in order to analyse the different
aspects of agile change management.
2.2 Different views on strategy
One thing that will affect all of the aspects of change discussed above is the organisation’s view
on strategy. According to Jacobsen (2012, p.152) there are two main views on strategy, called
Strategy E (Economical) and Strategy O (Organisational). Strategy E is a top-down approach to
strategy with focus on tangible economical results, like higher profit margins, while Strategy O is
a bottom-up approach characterised by employee participation, and is focused on continuous
learning and organisational development (Jacobsen, 2012). While Strategy E is concerned with
short-term economical results, Strategy O is concerned with developing the people and culture
of the organisation in order to achieve long-term goals. This terminology will be used when

analysing the approaches of different frameworks for managing change. The organisation’s view
on strategy will affect the strategic management of the organisation. This strategic management
can be analysed by looking at the organisation’s approach to a set of paradoxes, discussed in the
next section.
2.3 The paradoxes of strategic management
De Wit and Meyer (2014) present a series of seemingly contradictory approaches to strategic
management, which the authors call "strategy paradoxes" (De Wit and Meyer, 2014, p.14). These
paradoxes, and an organisation’s perspective on them, will shape the organisation’s approach to
change, as change and strategy go hand in hand. In this section we introduce the paradoxes we
find are most relevant for change management. These are the paradoxes of deliberateness and
emergence, exploitation and exploration, control and chaos, and revolution and evolution.
2.3.1 Deliberateness and emergence in strategy formation
According to De Wit and Meyer (2014) a paradox of strategy formation is the demand for both
deliberate strategising and strategy emergence. Deliberate strategising is the traditional ap-
proach to strategy and change management, where the management makes strategic plans and
implements them in a top-down manner (De Wit and Meyer, 2014, p.345). Strategy emergence
is where the strategy is continuously shaped by incremental initiatives, with a focus on organ-
isational learning (De Wit and Meyer, 2014, p.346). On the one hand organisations need plan-
ning to have a sense of direction and to coordinate strategic initiatives, while on the other hand
organisations also need to be flexible and to continuously learn and adapt to changing circum-
stances. This paradox can, according to De Wit and Meyer (2014, p.358), be solved by either
balancing the two needs through a trade-of between deliberate strategising and strategy emer-
gence, or by juxtaposing the two by continuously managing the two needs simultaneously.
Mintzberg and Waters (1985) illustrate the relationship between deliberate and emergent
strategy with the model shown in figure 2.2. According to them, the realised strategy is a com-
bination of deliberate strategy and emergent strategy. The deliberate strategy is the part of the
intended strategy that is actually realised. The way that this paradox is managed will determine

how much of the realised strategy is intended, and how much is emergent.
Figure 2.2: Types of strategies (Mintzberg and Waters, 1985)
2.3.2 Exploitational and explorational innovation
This paradox is concerned with the demand for both sustained and disruptive renewal (De Wit
and Meyer, 2014, p.446). On the one hand, the organisation needs to improve ongoing pro-
cesses through sustained renewal to be able to be competitive. This is called exploitative inno-
vation(De Wit and Meyer, 2014, p.442). On the other hand, the organisation also needs to exper-
iment with new processes and technologies in order to be flexible and to maintain their position
in changing environments and times of technological advancement. This is called exploratory
innovation(De Wit and Meyer, 2014, p.442). However, as the organisation has limited resources,
it must choose which aspect to focus on. This is called the innovator’s dilemma (De Wit and
Meyer, 2014, p.449).
According to Benner and Tushman (2003), incremental change is concerned with existing
customer segments and existing technology, while radical change seeks to find new customers
and new technologies. Process management is a view on organisations as a system of inter-
linked processes, and is concerned with mapping and improving organisational processes (Ben-
ner and Tushman, 2003). Process management is according to Benner and Tushman (2003)
well suited for incremental change (exploitative change), but not for radical change (explorative
change). Benner and Tushman (2003) argue that this is good in stable periods of time, while
radical change is better suited for unstable periods with rapidly changing environments. Lean
is an example of a process management methodology that will be discussed later in this chapter.
De Wit and Meyer (2014, p.450) suggest three possible ways to manage this paradox. The
organisation can use parallel processing, which involves separating the exploitative and ex-
ploratory innovation on a structural level, and give the responsibility for the two approaches

to different organisational units. This is also called ’spatial separation’ (De Wit and Meyer, 2014,
p.451), and is done by so called ’Ambidextrous Organisations’ (Benner and Tushman, 2003). Al-
ternatively, the paradox can be ’navigated’ by changing focus between the two approaches over
time. This is called ’temporal separation’ (De Wit and Meyer, 2014, p.452). Finally, the organisa-
tion can balance the paradox by doing both kinds of innovation at the same time.
2.3.3 Organisational control and chaos
The paradox of organisational control and chaos is a question of the amount of autonomy that
employees are given to manage their own work (De Wit and Meyer, 2014, p.554). Here ’con-
trol’ means top-down control from the organisation’s management, while ’chaos’ refers to de-
centralised management in a bottom-up fashion, where employees practice self-organisation.
There is a demand for top-down control in order to manage an organisation, and make sure
that the entire organisation is working towards the same goals while following the same strat-
egy (De Wit and Meyer, 2014, 550). But there is also a demand for flexibility and autonomy in
order for the employees to be able to innovate (De Wit and Meyer, 2014, 550). This paradox is
reflected in the change management perspectives of top-down change with a focus on Strategy
E, and bottom-up change focused on Strategy O.
De Wit and Meyer (2014, p.564) suggest three different ways of managing the paradox of
control and chaos. The paradox can be balanced, by blending top-down and bottom-up man-
agement. This blend will often be determined by the type of organisation, and the nature of the
industry it operates in (De Wit and Meyer, 2014, p.564). The paradox can also be juxtaposed, by
using different approaches in different projects and business units. Finally, the paradox can be
embraced. This consists of deliberately using the tension between control and chaos as a source
of creativity and opportunity. One way to do this is by having a diverse management team that
represents both approaches (De Wit and Meyer, 2014, p.565).
2.3.4 Revolutionary and evolutionary change
The paradox of revolution and evolution is concerned with how change should be implemented.
Revolutionary change is a radical and disruptive form of change. The approach is based on

the assumption that in order to overcome change inertia and resistance the change should be
implemented as a ’big bang’, where the organisation is changed suddenly and drastically (De Wit
and Meyer, 2014, p.392). Evolutionary change on the other hand, is a continuous processes of
small changes, that add up to significant change over time (De Wit and Meyer, 2014, p.392). This
allows the organisation to continuously adapt and learn.
De Wit and Meyer (2014) suggest only one way to manage this particular paradox. According
to De Wit and Meyer (2014, p.401), the paradox of revolution and evolution should be navi-
gated. By changing between revolutionary change and evolutionary change depending on the
situation, an organisation is able to adapt and benefit from both perspectives. De Wit and Meyer
(2014, p.401) suggest that in periods with relatively stable environments the organisation should
focus on evolutionary change, while in turbulent situations the organisation should change rev-
olutionary in order to respond fast enough to the changing environment.
2.4 Current change management practises
This chapter presents two of the most used frameworks for managing change. These will be used
to exemplify current business practises, in order to discuss how Agile can improve change man-
agement. How these practises manage the paradoxes described in section 2.3 will be discussed
in chapter 5. The two frameworks are Kotter’s 8-step process and Lean. These are not only widely
used in businesses in many different industries, but they are also very different from each other.
While Kotter’s 8-step process is a top-down plan-driven framework, Lean is more bottom-up,
and focused on continuous improvement. How these compare to each other and to Agile will
be discussed in chapter 5
2.4.1 Kotter’s 8-Step Process for Leading Change
Kotter’s framework consists of eight steps to lead successful change (Kotter, 2007). The first step
in the process is to create a sense of urgency and establish what Kotter calls a ’burning platform’.
It is important to create a common understanding of the necessity of the change in order to
reduce change resistance in the organisation. With this common understanding, the next step
is to establish a coalition that can help drive the change. This coalition helps with the next two

steps that consist of creating and communicating a vision for the change. This is important as
it creates a common goal the organisation can work towards, which solves the necessity from
the first step. The change is then realised in the fifth step that consists of enabling action and
removing barriers. It is important for a successful change process that the employees actually
are enabled to execute the change. The next step is then to create quick wins so that the entire
organisation can see that the change actually works. This will further reduce resistance to the
change. The last two steps consist of consolidating improvements and establishing a culture for
change. This involves making sure that the process does not stop once the first quick wins are
achieved, but instead working towards making the change stick. Kotter’s 8-step process will, for
simplicity, be referred to as ’Kotter’ in this thesis.
2.4.2 Lean
Lean is a methodology that covers many different areas of strategic management. In this thesis
we focus on the aspects of Lean that are concerned with change management. We will also focus
on the aspects of Lean which are different from Agile, to be able to compare the two more easily.
This means that frameworks like Kanban, that is considered a part of Lean but that includes
some agile concepts, will not be covered. When using the term ’Lean’ from now on, we refer to
these specific aspects of Lean.
Lean is based on four principles: Teamwork, communication, elimination of waste, and con-
tinuous improvement (Womac et al., 1990, as cited in Modig and Åhlstrøm, 2012, p.77). Accord-
ing to Modig and Åhlstrøm (2012), Lean is in practice concerned with eliminating superfluous
work through ’flow efficiency’. Modig and Åhlstrøm (2012) define flow efficiency as "the sum
of value-adding activities in relation to the throughput time" (Modig and Åhlstrøm, 2012, p.26).
This means that a process is flow efficient if all parts of the process add value to the customer,
and at the same time satisfies the customer’s needs quickly. This is done by adopting a customer
focus instead of a resource focus (Modig and Åhlstrøm, 2012, p.7), which means that the main
goal should be to satisfy customer needs as effectively as possible, and not necessarily to use
company resources as effectively as possible. Modig and Åhlstrøm (2012, p.15) denotes this as a
trade-off between flow efficiency and resource efficiency.
Two tools used in Lean to improve flow efficiency are standardised processes, and improve-

ment teams (Durand et al., 1999; Karlsson and Åhlstrøm, 1996, as cited in) Ingvaldsen et al.,
2012). Standardising processes can improve flow efficiency by reducing variety, as "the greater
the variation in the process is, the longer the throughput time" (Modig and Åhlstrøm, 2012,
p.43). Ingvaldsen et al. (2012) discuss improvement groups made up of employees from differ-
ent parts of the organisation, that meet regularly in order to find opportunities for improvement.
By using improvement groups, an organisation can continuously improve its processes in order
to make them more and more flow efficient (Modig and Åhlstrøm, 2012, p.152). This will be a
form of process management, as previously discussed.
2.5 Autonomy in Organisations
A growing need in strategic management is for units in organisations to practise self-organisation
and have teams that work autonomously (De Wit and Meyer, 2014, p.555). An author who has in-
fluenced the field of autonomy for decades is Hackman (1986), who discusses self-management
in organisations. Hackman argues that traditional control-oriented management methods can
have negative outcomes for both the organisation and the employees, and that future organisa-
tions will rely more heavily on self-management.
Hackman (1986) defines self-management with five behavioral signs:
• People take personal responsibility for their work
• People continuously monitor their own work
• People manage their own performance
• People actively seek guidance when needed
• People take initiatives to help others improve their performance
According to Hackman (1986), self-managing units often show either very good or very poor
efficiency, and there are few self-managed units that perform only moderately well. This ten-
dency for extremes indicates that self-management can be very effective if implemented right,
but fails if some conditions are not met. Hackman (1986) identifies five general conditions for
effective self-management:

• Direction - the direction of the work is clear and engaging
• Structure - the unit structure enables performance through the expectations, unit com-
position, and task design
• Context - the organisational context is supportive, through information, educations and
rewards
• Coaching - expert coaching and consultation are available
• Resources - material resources are adequate and available
When it comes to leadership of self-managing units, Hackman (1986) argues that critical
leadership functions are still required even though the units are supposed to lead themselves.
Hackman (1986) distinguishes between two types of critical leadership functions; monitoring
and taking action. In leadership of self-managing units, monitoring involves making sure the
five conditions for effective self-management as discussed above are present and that operation
is efficient. Action taking then involves fixing problems with the conditions to enable efficient
processes. In this way, the leader will continuously diagnose and remedy the conditions to en-
sure that the unit can operate effectively.
Autonomy is not suited for every organisation. Vallas (2003) argues that it is difficult to im-
plement autonomous teams in organisations that use process management, like in Lean. This is
because the strict focus on improving efficiency will limit the employee’s freedom to experiment
and make changes, as only changes that improves efficiency are allowed.
Another factor that could limit an organisation’s ability to implement self-management is
culture. The work by Hofstede (1983) on national cultures is one of the widely used models for
describing national culture. One aspect of Hofstede’s model which is particularly relevant for
the field of self-management is the concept of power distance. Power distance, when used in
the context of organisational structure, is an index that measures the degree of inequality that is
both accepted and expected between the management and the employees (Hofstede, 1983). It
will be difficult to implement self management in areas where the national culture is defined by
a high power distance, as the management is expected to make all the decisions.

As discussed in this chapter, there are several challenges involved with change management.
An organisation needs to be flexible to be able to manage the different strategic paradoxes dis-
cussed in section 2.3, and there is also a growing need for autonomy as discussed in this section.
In this thesis we argue that these can both be solved by agile processes. The next chapter will
give an introduction to Agile, and present a framework for how some of these processes can be
used to manage change.

Chapter 3
Agile Concepts
In this chapter, the concept of agile from software development will be discussed in order to find
elements of it that can be applied to change management. This will help answer the research
sub-question: "Which aspects of Agile software development methodologies can be applied to
change management?". At the end of this chapter there will be presented an example of an
agile framework for change management, that incorporates some of the concepts of agile. How
elements from Agile fit into change management, will then be discussed further in chapter 4.
3.1 Agile software development
Agile as a concept stems from The Agile Manifesto (2001), which contains twelve principles for
software development. The principles of the Manifesto are that software development should
focus on satisfying customers, harnessing change in the processes, deliver working software
frequently, have cooperation between business people and developers, build projects with mo-
tivated individuals, face-to-face communication, working software as a measure of progress,
keep a sustainable development, continuous attention to technical excellence, simplicity, have
the best architectures, requirements and designs from self-organising teams and reflect and ad-
just on the team-behaviour regularly (The Agile Manifesto, 2001).
Today, Agile consists of different methods and principles that leads to agility (Dingsøyr et al.,
2012). Agility in software development is defined as "A continued readiness to rapidly or in-
herently create change, proactively or reactively embrace change, and learn from change while
19

CHAPTER 3. AGILE CONCEPTS 20
contributing to perceived customer value (economy, quality, and simplicity), through its collec-
tive components and relationships with its environment" (Conboy, 2009, as cited in Dingsøyr
et al., 2012)
3.1.1 Agile and non-Agile software development frameworks
Agile methods for software engineering started to appear in the 1990s as a reaction to the tradi-
tional plan-driven methods for developing software Sommerville (2011, p.58). One of the most
used plan-driven models is the Waterfall model. The Waterfall model divides the development
process into sequential stages. These stages are requirement specification, system develop-
ment, system validation, and maintenance and evolution (Sommerville, 2011, p.29). Many have
criticised plan driven models like the Waterfall model for the amount of overhead involved as
well as a lack of flexibility and problems dealing with changing environments and requirements
(Sommerville, 2011, p.59). The agile models for software development tried to solve these prob-
lems. Two of the most used agile software development models are Extreme Programming (XP)
and Scrum. While Extreme Programming deals with software development on an operational
level, Scrum is a framework for managing software development projects.
Extreme Programming receives its name from pushing good, agile practises to "extreme
levels" (Sommerville, 2011, p.64). One such practise is iterative development, which involves
breaking tasks into sub-task which are executed in cycles, allowing feedback. In Extreme Pro-
gramming, the system requirements are expressed as user scenarios, or user stories, that ex-
plains certain use cases. Each iteration consists of choosing user stories, and breaking these
down into tasks that need to be done to provide the functionality needed for the use cases. This
functionality is then developed, and added to the product through a release at the end of the
iteration. In this way, the customer gets the product at a very early stage, and functionality is
then added through frequent releases. This involves the customer in the development process,
and allows the customer to provide early feedback. The iterative nature of the development also
makes changing the requirements along the way easier, as the changes can be implemented
through an iteration in the same way as other functionality (Sommerville, 2011, p.65).
Scrum is as mentioned a framework for agile project management. This means that it can
be combined with frameworks on the operational level, such as Extreme Programming (Som-

merville, 2011, p.72). Scrum is based on development through fixed-length iterations, or "sprint
cycles", where the development team chooses and develops functionality from a work backlog,
which consists of a set of tasks and objectives set by the project owner. During these sprints
the team has daily "stand-up meetings" where the developers inform each other of what they
are currently working on. In this way the team can achieve a large degree of communication
and visibility, so that everyone knows how the project is going at all times. Scrum also empha-
sises that the whole team should be able to make decisions. Because of this the team does not
have a project manager, but rather a so called "Scrum master". The role of the Scrum master
is not to manage the team in the traditional sense, but rather facilitate the team and handle all
communication between the team, the customers and the rest of the organisation. In this way,
the Scrum master can "protect the development team from external distractions" (Sommerville,
2011, p.65), and the team can work autonomously.
3.1.2 Agile outside of software engineering
Agile has gained traction in other areas than software engineering (Dingsøyr et al., 2012). Sim-
ilar changes to the approach to the field software engineering have been found in other fields
such as strategic management (Nerur and Balijepally, 2007, as cited in Dingsøyr et al., 2012).
There are many reasons for such a shift. Software is becoming the central differentiator for
many products (Bosch, 2016). For many industries, business models are fundamentally chang-
ing from products to services (Bosch, 2016). Today companies has to respond to the customers
much faster than before, which demands an enterprise-wide agility that is difficult in traditional
structures (Bosch, 2016). One of the implications of these trends is that companies must move
from planned releases to continuous experimentation with customers (Bosch, 2016). This co-
incides with the principles of Agile, thus making Agile interesting outside of software develop-
ment. Another author has a similar reason for moving to agile: "The concept of agile working
has been adopted by many organisations which have realised that their hierarchical structures
and lengthy decision-making processes are no longer fit for purpose in a world of complex and
continuous change" (Franklin, 2014, p.6).

3.2 Large-Scale agile
Even though Agile methods were designed for small and individual teams, agile methods have
become an attractive alternative for large companies (Boehm and Turner, 2005, as cited in Paa-
sivaara and Lassenius, 2016). Several authors have seen the need to scale the concept of agile
from a software engineering level to an enterprise level (Reifer et al., 2003; Kettunen and Laanti,
2008, as cited in Fitzgerald and Stol, 2015). A large number of companies have already taken or
are taking agile into use in a large-scale setting (Paasivaara and Lassenius, 2016). The benefits
of an agile software development have been found to be sub-optimal if it is not combined with
an agile approach in related organisational functions (Leffingwell, 2007; Overby et al., 2005, as
cited in Fitzgerald and Stol, 2015). On an enterprise level, one uses the term "Enterprise Agility"
which is defined as "the ability of firms to sense environmental change and respond appropri-
ately" (Overby et al., 2005, as cited in Fitzgerald and Stol, 2015). In a large-scale agile perspective
the terms DevOps and BizDev are terms representing two challenges. DevOps is a term repre-
senting the need to align the development of software and the deployment of that software into
production (Debois, 2011, as cited in Fitzgerald and Stol, 2015). BizDev is the process of contin-
uously assessing and improving the link between software development and business strategy
(Fitzgerald and Stol, 2015). Large-Scale Agile faces many challenges, one of the reasons being
that "adopting agile often requires change to the organisational culture" (Misra et al., 2010, as
cited in Paasivaara and Lassenius, 2016). The relationship between Agile and different forms of
culture will be discussed further in section 3.3.2. Paasivaara and Lassenius (2016) conducted a
pilot study on the challenges and success factors of large-scale agile. The motivation behind the
study was that "surveys on challenges and success factors for agile projects in general have been
conducted, but not specifically for large-scale agile projects". (Paasivaara and Lassenius, 2016)
find that there are many challenges in implementing large scale Agile, mainly in coordinating,
managing, and providing support for the agile teams. The results also coincides with earlier
research within the field (Paasivaara and Lassenius, 2016).

3.3 Agile adoption
As seen in section 3.2 and 3.1.2 agile concepts are being adapted in many different settings. This
section looks at findings by different authors on challenges that have been experienced when
adopting agile and give indications of where agile is suited.
3.3.1 Challenges when adopting agile
For an agile adoption, many aspects of organisations have to change. These changes may cause
many problems and challenges (Gandomani et al., 2013a). Before undertaking an agile change
management strategy the challenges, obstacles and barriers should be recognised (Gandomani
et al., 2013a). Many issues have been mentioned by several authors, such as changing atti-
tude from command and control, to leadership and collaboration, coaching and mentoring and
knowledge management (Gandomani et al., 2013a). In plan-driven methods there are require-
ments for heavy documentation, whereas in agile there is less of this. This leads to more implicit,
or tacit, knowledge which may be looked upon as a challenge from the perspective of senior
managers (Gandomani et al., 2013a). Because of Agile’s focus on people, the adoption of Agile
results in change for the people, or change of the people in the organisation (Gandomani and
Nafchi, 2016).
As seen in 3.2 several challenges when undergoing an agile adoption or doing large scale
Agile have been identified by several authors. One of the main characteristics of agile is giving
priority to people, their roles, and interactions. (Gandomani and Nafchi, 2016). Gandomani
and Nafchi (2016) argue that the challenges of an agile adoption process must be understood as
a comprehensive change process. Gandomani and Nafchi (2016) study the human related chal-
lenges in this process and the many aspects of people being changed in an agile adoption pro-
cess. The study finds that human related challenges play a significant negative role in moving to
Agile. This significance stems from the important role of people in Agile methods (Gandomani
and Nafchi, 2016). There are several challenges in implementing self-organising teams, which
is is essential in order to achieve agility (Hoda et al., 2011, as cited in Gandomani et al., 2013b).
Two important challenges found are cultural issues and lack of collaboration (Gandomani and
Nafchi, 2016). The culture challenge "sometimes arises from organisational culture rather than

people’s culture" (Gandomani and Nafchi, 2016). In this case, focusing on organisational be-
haviours and improving them would be the only solution" (Gandomani and Nafchi, 2016). The
authors conclude that "due to the people-centric nature of Agile methods and Agile transition
process, human-related challenges are the most critical ones during the transition"(Gandomani
and Nafchi, 2016).
3.3.2 Culture and Agile
As seen, employees form a central aspect of agile, as empowerment and autonomy is a major
factor. With people as such a major factor, one has to take culture into account. One very im-
portant aspect of national culture in regards to Agile, is power distance. As described in section
2.5, power distance is a measure for the degree of accepted and expected inequality. In order
for the employees to be able to engage in self-organisation, a relatively low power distance is
required. Autonomous teams will not be effective if the national culture is defined by a high
power distance, and the employees expect the management to make all decisions.
However, agile is not only concerned with national cultures, but also organisational culture.
Sahota (2012) and Spayd (2010) use Schneider’s model for organisational cultures to discuss the
organisational culture in relation to agile. It is therefore used to conceptualise culture in an agile
context. The model consists of four main cultures and two axis of orientation, described below.
• Control: A control culture seeks certainty and predictability. Managers tend to be direc-
tive and authoritative; the military is a typical example of such a culture(Spayd, 2010).
• Competence: A competence culture seeks freedom, distinction and uniqueness. The
people seek to be experts in their field. The culture is oriented towards learning, an exam-
ple is an University (Spayd, 2010).
• Collaboration: A collaboration culture seeks unity and connectedness. Often involves
partnering with customers, and the people are often generalists. Typical examples include
sports team or a family (Spayd, 2010).
• Cultivation: The last culture, cultivation, seeks a meaning, or making a contribution. A
relationship with customers focused on realizing potential. This culture is not very com-

mon among for-profit organisations, but more widespread among non-profits, religious
and spiritual organisations (Spayd, 2010).
The axis of Schneider’s model is often labelled People/Company from left to right, and Real-
ity/Possibility from top to bottom. This can be seen in figure 3.1, that shows how the four types
of cultures can be organised as a 2x2 matrix. According to Sahota (2012), agile culture is mapped
into Collaboration, Cultivation and Competence. Control is, therefore, the only main type of cul-
ture that does not fit for Agile. If the organisational culture does not suit the agile culture, the
culture has to be changed either before or during an agile adoption, thus making the process
very difficult (Sahota, 2012). Therefore, adopting agile is much more suited for organisations
with a culture that already has some aspects of agile in it.
Figure 3.1: Summary of Schneider’s Culture Model (Sahota, 2012)
3.4 An agile framework for change management
Agile change management is a relatively unexplored field, but Franklin (2014) proposes a frame-
work for managing change processes by using many of the agile practises discussed in this chap-
ter. According to Franklin (2014, p.7), the key to agile change is to let the change emerge through
continuous learning, and accept that it is impossible to plan change in detail from the start. To

achieve this, the change should be implemented through an iterative process (Franklin, 2014,
p.8). Franklin (2014) presents an agile change roadmap based on this iterative approach, which
describes activities and processes that are necessary to manage agile change initiatives.
3.4.1 Roadmap
According to Franklin (2014), the roadmap should be tailored to the scope of the project, the
level of central control in the organisation, and the specific methods and approaches used in
the organisation. However, some elements will be important regardless of the specific use case.
Franklin argues that the project should have a set time frame Franklin (2014, p.47). Within this
time frame, the change should be implemented through a series of iterations that each consists
of several processes. This is shown in figure 3.2, which shows how the timeframe is broken down
into iterations, that are made up of processes. The change is made gradually from the outcomes
of the iterations.
Figure 3.2: Elements of the roadmap (Franklin, 2014)
The more specific elements of the roadmap should be tailored to the project and the organ-
isation. Franklin does, however, suggest some elements that could be included (Franklin, 2014,
p.21):
• Processes - collection of specific activities for implementing the change.
• Best practice techniques - explanation of how the processes should be executed.
• Document templates - agreed set of documentation and the people responsible for it.
• Guidance notes - explanation of what each document should include
• Role definitions - distribution of roles and responsibilities.

• Role questionnaires - questions that help choose the right people for the right roles.
• Checklists - to ensure that the goals are being met.
• Acceptance criteria - criteria that must be met in order for an output to be deemed suc-
cessful and complete
According to Franklin, every iteration and every process in the roadmap must deliver change
(Franklin, 2014, p.42). This should be reflected in a progress report. The progress reporting
should focus on outputs and outcomes of each process, as well as an analysis of these results
meet their acceptance criteria.
The first iteration of the project is concerned with finding a common understanding of the
change project, and plan how the project should be managed. It is in this phase that the details
of the roadmap should be specified. All subsequent iterations after the first will then implement
the change. According to Franklin (2014, p.42), all these iterations should include the following
activities:
• Discover - find new areas to be changed. This process should be based on ideas from
everyone involved in the change, as well as feedback and reports from the previous iter-
ations. The outcome of this activity should be an agreement of the content and scope of
the iteration.
• Plan - create or update a prioritised list of requirements for the change, depending on
the iteration. Choose the most critical requirements to further specify the scope of the
iteration, and allocate resources to complete these requirements. Acceptance criteria for
the iteration’s outputs should also be defined at this stage, based on the selected require-
ments.
• Change - make alterations to processes, systems, or roles in the organisation according
to the prioritised requirement list from the previous step. Before full deployment, the
changes should be tested against the acceptance criteria, to make sure that they work as
intended.

• Review - realise the benefits of the change. In this stage, both the quality of the individual
elements of the change and the total effect of the integrated change should be evaluated.
The business case defines the expectations for the results of the change.
• Deploy/Dismantle - deploy the changes, and dismantle old processes and systems. It is
important to not only implement new ways of working, but also to remove the old ways.
This will reduce confusion caused by a mix of new and old, and generate motivation for
further changes
• Celebrate - congratulate the people involved in the change. The success of the change
should also be proven by measuring improvements. This will help reduce change resis-
tance, and make future changes easier.

Chapter 4
Defining Agile Change Management
Franklin’s framework for change management is an example of how the agile principles pre-
sented in chapter 3 can be used for change management. This thesis does, however, use a more
general definition of agile change management, as there are important elements to the sub-
ject that are not covered by Franklin. One such element is autonomy. Franklin (2014) use a
’best practice’ approach to change, which is not that different to the process control of Lean.
This does, as argued in Vallas (2003), restrict autonomy, and as argued by Benner and Tushman
(2003), restrict exploration. In addition, we argue that Franklin (2014) has elements of a plan-
driven perspective on change, which contradicts the notion of agility. This is indicated by the
fact that the change process should be planned in advance in the form of a roadmap according
to Franklin (2014). This section, therefore, describes what we define as ’agile change manage-
ment’ in the rest of the thesis. In doing so, we answer the research sub-question "Which aspects
of Agile software development methodologies can be applied to change management?".
4.1 The need for flexibility
Flexibility is a central concept of agile. As seen in chapter 3, increasing need for flexibility was a
key reason for the foundation of the agile methodology. As seen in chapter 2 flexibility is key for
managing the paradoxes of strategic management as well (De Wit and Meyer, 2014). Because of
this, flexibility is a central aspect of our definition of agile change management. We, therefore,
define an agile process that can be adapted to different situations and change processes in the
29

CHAPTER 4. DEFINING AGILE CHANGE MANAGEMENT 30
following sections. This flexibility can help manage the strategic paradoxes described in section
2.3. How agile can be used to manage the paradoxes will be discussed in chapter 5.
4.2 Agile principles in change management
Both elements from Franklin and agile software development can be identified and used to give
flexibility in agile change management. They are both based on the agile principles, which is
central in defining agile change management. We argue that some of the agile principles that
are discussed in chapter 3 that are most relevant for change management are: Close interaction
with both customers and management, self organising teams, frequent deliveries, willingness
to embrace change, and close relationships with the environment. Interaction with customers
and management, as well as self organising teams, are the basis for the autonomous teams from
agile software development (The Agile Manifesto, 2001; Dingsøyr et al., 2012). Examples of this
in practice are the Scrum teams that operates autonomously, but frequently involves both cus-
tomers and management, and the use of iterations in Extreme Programming that provides all
new functionality through the frequent deliveries from the development iterations. The prin-
ciples of frequent deliveries, willingness to embrace change, and relations to the environment
are all implemented in practice through the iterative process used in XP
, Scrum, and Franklin’s
framework. The use of iterations will give deliveries at the end of each iteration, as well as enable
feedback and allow for change during the process. Defining how iterations and autonomous
teams are used is, therefore, central in defining agile change management.
4.2.1 Autonomy and iterations
We argue that autonomy can be achieved in change management by using a change manage-
ment team that is autonomous from the top management. This may seem difficult, as change
management is such an important part of an organisation’s strategy, but we argue that it can
be done by using practises from agile software management. First of all, the top management
will still need to set the goals for the change management team. Inspired by the role defini-
tions of Scrum, the top management can define goals for the change management team, in
the same way that a project owner sets requirements for a scrum team in software develop-

ment (Sommerville, 2011). The management can also be involved in the same way as in scrum,
and provide feedback after each iteration, but the change management will be responsible for
designing and implementing the change. By setting the goals and success-criteria, top man-
agement still retains control over the overall business strategy. The change management team
will then have full control of the change, within the boundaries set by the management. When
autonomy is implemented in this way, all the conditions from Hackman (1986) for effective self-
management discussed in section 2.5 can be met. The boundaries, set by top-management will
provide both direction and structure for the process. The context condition will depend on dif-
ferent types of cultures, as presented in section 3.3.2. This aspect will be discussed further in
section 5.5. The two final conditions, coaching and resources, are also recognised as important
elements of adopting Agile as discussed in section 3.2. It is, therefore, important to be aware
of these conditions when implementing the autonomous teams, these two conditions will be
further discussed in 5.3.
We define iterations split into 3 parts consisting of goals, iterations and finish. Each iteration
will also include an evaluation at the end. This process is shown in figure 4.1. The length of the
process, as well as the number of iterations, are determined at the beginning of the process as
Franklin (2014) suggests. In this way, it is clear when the process enters the finish phase. The
goals are given by the top management as previously discussed, following the same principle as
the backlog from Scrum. These goals then serve as a basis for the iterations, which is carried out
by the autonomous team. The length and success criteria of the iterations should be specified
before starting the iteration phase. After each iteration has been carried out, the process enters
the evaluation phase. Here the iteration is evaluated, and the change management team can
get feedback from the top management, as well as the rest of the organisation and possibly
customers. This enables the team to make necessary adjustments, and adapt to changes in the
environment.

Figure 4.1: Agile change process
In this chapter, we have argued which aspects of agile software development can be applied
to change management. We find that the aspects of autonomous teams and iterations are the
two main aspects that can be applied to change management. The descriptions provided in this
chapter of agile change management teams and their iterative change management process, as
well as the agile principles and the goal of flexibility that they are based upon, is used as the
definition of Agile Change Management in the following discussion. In the following chapters,
the term "Agile" refers to this framework.

Chapter 5
Comparing Agile and Current Change
Management Practises
In this chapter we discuss how Agile compares to existing change management practises, ex-
emplified by Kotter’s 8-step process and Lean, in regard to the five different aspects of change
presented in chapter 2: Process, content, drivers, context and outcome. Special emphasis will
be put on how Agile differs from the two existing approaches, and how Agile can contribute to
the field of change management. This will help answer the research sub-question "In which
aspects of change management can it be advantageous to use Agile practises?". We will also
present areas where Kotter and Lean might be better suited than Agile, but the main focus will
be on the advantages of Agile in order to answer the research question.
5.1 Process
Agile is very different from both Kotter and Lean in terms of change process. While Kotter re-
gards the process as a series of sequential steps, and Lean consider it to be a continuous im-
provement process, Agile has a cyclic approach to the change process. The core of the Agile
process is, as discussed in chapter 4, the iterations that are used to implement the change.
One important aspect when comparing the different approaches in terms of planning and
executing the change process, is how they manage the paradox of deliberateness and emergence
discussed in section 2.3.1. The two sides of this paradox are, as discussed, planned and emergent
33

CHAPTER 5. COMPARING AGILE AND CURRENT CHANGE MANAGEMENT PRACTISES 34
change.
5.1.1 Planned and emergent change
We find Kotter’s 8-step process to be clearly focused on planned change. The steps in the process
are sequential, and do not allow for alterations during the process. It is also evident from the fact
that the first steps are concerned with planning and enabling the change, while the later steps
are concerned with executing the change, that the framework is plan-driven.
We also find that Lean represents a more emergent form of change. Continuous improve-
ment is a central aspect of Lean, meaning that the organisations should continuously strive to
improve flow-efficiency (Modig and Åhlstrøm, 2012, p.152). This implicates that change should
not be planned, but will emerge as new ways to improve the efficiency are discovered. This does
not mean that we find Kotter or Lean to be purely planned or purely emergent. Kotter have el-
ements of emergence, for example in the ’enable action’ step where it is implied that solutions
could emerge from the organisation. Lean also has elements of planning, in that the plan for the
Lean implementation should be to improve the flow efficiency of the organisation. However, it
is clear that Kotter and Lean are focused on planned and emergent change respectively.
We argue that the approach Agile takes to the paradox is depending on how Agile is imple-
mented, and what it is used for. In a traditional sense, Agile can be seen as plan driven. The goal
is planned out beforehand, and the plan is evident throughout the process in the form of the
task backlog. However, Agile also allows for these tasks to change between iteration, so change
can emerge as well. In addition, we find that the way the goals are met will also be emergent
in Agile. The change implemented is determined in each iteration as the backlog only specifies
a certain goal, and not how to reach it. We argue that Agile can be used for either plan driven
change or emergent change, depending on how loosely the goals are specified. If the goals are
very specific, the iterations are used to find a way to execute the given plan. If on the other hand
the goals are loosely specified, the iterations can be used to experiment and allow for emergent
change.
Because of the flexibility Agile provides, we argue that it can help balance the paradox of
planned and emergent change in a way that Kotter and Lean cannot. Both Kotter and Lean
are focused on one aspect of the paradox. Agile, on the other hand, can be adapted to focus

on one or the other, depending on the goals and how the iterations are used. Because of this,
the paradox can be balanced by regulating how specific the goals and tasks of the change pro-
cess should be, and let the rest of the change emerge. How much of the change that should be
planned and how much that should be emergent, will depend on the content, context, drivers
and desired outcome of the change. If, however, the organisation is in a position where purely
planned or purely emergent change is advantageous, then the organisation might benefit more
from choosing Kotter or Lean respectively. Agile is able to balance the two approaches, but Kot-
ter and Lean are more specialised. A plan-driven approach, like Kotter, will for example be well
suited for change where clear goals and a clear sense of direction are more important than flex-
ibility (De Wit and Meyer, 2014, p.346). Lean will in the same way be well suited where there is a
strong need to optimise processes. This will be discussed further in section 5.2
5.1.2 Feedback
Another key factor of the agile change process is the opportunity for feedback between iter-
ations. We find that this makes agile processes more flexible than plan-driven processes like
in Kotter, in that it is possible to change course during the change process. If it is discovered
that something does not work as intended, or if the circumstances change, it is possible to set
new goals in the next iteration. This also allows for trial and error using each iteration to try
something new, and see if it works. The possibility to take this approach is valuable in unstable
periods where it is uncertain which direction the change should be taking (De Wit and Meyer,
2014, p.401). This is closely related to the paradox of revolution and evolution, which will be
discussed in section 5.4.

Figure 5.1: Agile change process
Figure 5.1 shows the key advantages that Agile can provide for the process aspect of change
management, as discussed in this section. With a change process based on iterations, we argue
that agile change management can balance the paradox of planned and emergent change, and
enables flexible change processes through feedback from each iteration.
5.2 Content
As discussed in the previous section, the iterative approach is one of the aspects that differ-
entiates agile from Lean and Kotter. In this section we will argue that the increased flexibility
the iterations provide is also key to balancing the paradox from section 2.3.2 of exploitative and
exploratory change.
5.2.1 Exploitative and exploratory change
Kotter can be used to balance the paradox, as it can be used for any type of content. However,
Kotter requires clear goals, which may be hard to define. We find that Lean, as a form of process
control, is suited for exploitative change but not as suited for exploratory change. As previously

discussed, the strict focus on improving efficiency will severely limit the possibility of explo-
ration. Agile can, through the use of iterations, balance the paradox through a form of parallel
processing. Where the goals or objectives of each iteration determine if the process is a part
of a exploitative change or a exploratory change. Where exploitative change typically will have
economic success-criteria or goals, this is not necessarily suited for exploratory change. An
exploitative change process might have success-criteria such as "Reduce number of machine
hours by X for product Y" or "Increase production level by Z % while keeping staff and machines
the same". This is well suited for the continuous improvement of Lean. There is a possibility
that exploitative change can be done with an agile approach, by having such goals for the itera-
tions. When the iterations are evaluated based on an exploitative point of view, one can achieve
exploitation with an agile approach as well. However, Lean might be better suited for an ex-
ploitative change than Agile, as it is focused on continuous improvement (Modig and Åhlstrøm,
2012). On the other hand, the iterations of Agile allow for different success-criteria, such as
"Gain entry to market X with customer Y", which will be an exploratory change. This allows the
autonomous teams to work towards this goal, but they can leverage their knowledge and have
a faster process. This "bottom-up" variant of change will be discussed below. Because of this,
we argue that Agile might be more suited for finding new customers and new technologies. We
find that Lean is more concerned with working with existing customers and technologies, as it
is focused on improving the efficiency of existing processes (Modig and Åhlstrøm, 2012). There-
fore, according to Benner and Tushman (2003), Lean is less efficient in unstable environments
where an organisation needs new customers or has to adapt new technology. In this case, Agile
will be more suited. We do, however, find Lean to be more suited than Agile for some types of
change. The focus on process improvement through the use of improvement groups gives Lean,
as previously discussed, an advantage in optimising efficiency and performance. We argue that
in mature industries with a high degree of competition, it is very important to be efficient in or-
der to compete. This makes Lean more suited than Agile in such industries where exploitation
is more important than exploration.

5.2.2 Length and success criteria of iterations
An important discussion is the length of the iterations and the success criteria applied to the
iterations, in the example of exploitative change one can adopt an idea of "scale or fail", in that
different ideas can be tested in an iteration. If it passes the success-criteria set (typically by
management) it can be scaled up and applied to the rest of the organisation. The exact length
and criteria for an iteration is context specific and will depend on the organisation and the type
of change being "tested".
Figure 5.2: Content of agile change
The key takeaway from this section is that Agile appears to be well suited for exploratory
change, as shown in figure 5.2. We argue that Agile is a good option for managing change in
unstable environments.
5.3 Drivers
According to Kotter (2007), change should be driven by the management and a coalition chosen
by the management. In Lean, change should be driven by opportunities for process improve-

ment, through continuous improvement (Modig and Åhlstrøm, 2012). Within our agile frame-
work, the argument is that change should be driven by autonomous teams, and by experience
through iterations. Kotter, Lean and Agile, therefore, all have different views on how change
should be driven. We find that all three have different approaches to the paradox of control
and chaos, as they use different variations of top-down and bottom-up change management
as discussed in section 2.3.3. Before the paradox is discussed, it will be necessary to determine
the levels of empowerment and autonomy in the three different change practises, as these are
central to the paradox.
5.3.1 Empowerment and autonomy
We find that Kotter’s 8-step process provides very little autonomy to employees, as the entire
process is driven by the top management and their coalition. Employees are, however, em-
powered to carry out the change, but not to create changes themselves. We also find that Lean
restricts autonomy. Lean is a form of process management, where one of the goals is to reduce
waste and superfluous work to improve efficiency (Modig and Åhlstrøm, 2012). One implication
is that all activities that do not provide value for the customer should be removed. This severely
limits autonomy and exploration, as only activities that are deemed to be ’value adding’ is al-
lowed to be implemented. Vallas (2003) also argues that it is difficult to combine such process
improvement practises with autonomous teams in practice, because employees are deemed re-
sponsible for eventual changes that they make. If the change reduces efficiency, then it is easy
to blame the employee. In this way, the strict control caused by process improvement will make
empowerment difficult and limit autonomy.
Agile on the other hand is based on autonomy. In the case of agile change management,
a change management team will operate autonomously based on a set of goals or tasks given
by the top management. This is similar to the way an agile software development team inter-
acts with the product owner(Sommerville, 2011), in that the owner sets requirements and pro-
vides feedback, while the agile development team operates autonomously. In this way the top
management will be involved, but not directly in control. Even though the goals are set by top-
management, the employees will have a large degree of freedom during the iterations. Agile will,
therefore, give a higher degree of empowerment and autonomy than Lean. While Lean restricts

all changes in that they must be value adding, Agile only restricts the end product. This means
that the change management team is free to implement any change they believe is right in order
to meet the end goals.
It should, however, be noted that the autonomy required by Agile presents several chal-
lenges. As discussed in section 2.5, Hackman (1986) defines five general conditions for effective
self management: Direction, Structure, Context, Coaching and Resources. In chapter 4 we argue
that our framework satisfies the first two, while the latter three are dependant on the specific or-
ganisation. The context aspect will be discussed in detail in section 5.5. As seen in section 3.2
and section 3.3, several challenges have been identified when implementing agile in relation to
these two conditions. In particular, coaching, cooperation, coordinating and management sup-
port are recognised as great challenges when adopting Agile (Paasivaara and Lassenius, 2016;
Gandomani et al., 2013a,b; Gandomani and Nafchi, 2016). We find that in order for our frame-
work to be used successfully, these challenges have to be addressed by the organisation. If com-
munication and cooperation is lacking, the autonomous team will not be able to function effi-
ciently. Successful implementation of the framework is a subject that warrants further study.
5.3.2 Top-down and bottom-up change management
Kotter’s 8-step process regards change as a top-down process, where the management goes
through all 8 steps in order to implement the change and overcome change resistance through
control. This is evident from the lack of autonomy. The fact that the management creates the
burning platform as a way to convince the organisation of the need for change, as well as the cre-
ation of a hand picked coalition that supports the change. The process has elements of chaos
as well in that employees are empowered to execute the change, but the model does not give
the employees opportunities to participate in the decision process. Because of this, the model
is mainly focused on the control aspect of the paradox of control and chaos.
Lean is also primarily focused on top-down control. As discussed, Lean will restrict the level
of autonomy in the organisation, as the focus is on improving efficiency and not empowering
employees. This goal is set by the management in a top-down fashion, and does not allow for
bottom-up chaos. Modig and Åhlstrøm (2012, p.42) argue that variation reduces efficiency, giv-
ing no room for the experimentation and chaos needed for bottom-up management.

Agile, however, provides an opportunity for both top-down and bottom-up change manage-
ment, depending on both the goals and on the members of the agile change management team.
As previously discussed, how strictly the goals of the change management team are formulated
will determine the level of planned change in relation to emergent change that will be produced.
However, this will also help determine the levels of control and chaos. If the goals are strictly for-
mulated, the team will have limited freedom, resulting in more top-down control. If, however,
the goals are loosely formulated the team will have more freedom to experiment, which will re-
sult in more chaos-driven change. Because of this, the goals set by the top management will
provide a way to balance the paradox of control and chaos as well. We argue that the compo-
sition of the change management team will also affect the levels of top-down and bottom-up
management in the change process. If the team is made up of only managers, the change is still
only driven top-down. If, however, the team includes both managers and employees, the team
can benefit from both perspectives. This is an example of embracing the paradox (De Wit and
Meyer, 2014, p.565). Because of this we find Agile to be more flexible that Kotter and Lean in
terms of change drivers. We do, however, argue that there are certain situations where it could
be beneficial to manage change in a top-down manner as well. Kotter can for example be used
effectively if the organisation requires a sudden, disruptive change. Agile might lack the ability
to drive through changes as quickly in such situations, because it lacks the control-element of
Kotter. This will be further discussed in section 5.4.
5.3.3 Middle-out management
It can also be argued that the change drivers in Agile change management are neither top-down
nor bottom-up. If the iterations in the change process are used to test out new changes, and the
successful changes are kept while unsuccessful ones are discarded, the change will not be driven
by either the management or the employees. The change will, however, be driven by experimen-
tation and experience. We define this as ’middle-out management’, as the change originates
from experiments in one part of the organisation and are adopted by the rest of the organisation
once successful. If the goal is to achieve this form of experimental middle-out management,
it will be very important to define the success criteria of the iterations in an objective way to
ensure that the resulting change will not be biased towards any one type of change. One as-

pect that is important to consider when designing objective success criteria will be bias towards
either Strategy E or Strategy O, introduced in section 2.2.
5.3.4 Strategy E and Strategy O
Considering bias towards either Strategy E or strategy O will not only be important when choos-
ing success criteria for agile change iterations. A focus on one or the other can act as a change
driver by itself, as it shapes the change by defining the goals the change should achieve. If the
management is focused on Strategy E, then change will often have economical goals like im-
proving profit or efficiency. If these are the only success criteria for a change initiative, then
positive change that would help develop the organisation through for example better knowledge
management might be deemed unsuccessful as it does not contribute directly to the econom-
ical short-term goals. If, on the other hand, the organisation has a strong inclination towards
Strategy O, and all goals are focused on long-term organisational development, the organisa-
tion might discard changes that would improve profitability. Because of this, it is important to
balance the two when developing both the success criteria for the agile iterations, and the goals
for the entire change process.
Figure 5.3: Drivers of agile change

Figure 5.3 summarises the contribution Agile can make to the change driver aspect of change
management, which is discussed in this section. We argue that the most important factor is that
the change is driven from trials and experience, through middle-out management. The amount
of control and chaos involved can be balanced by changing the goals and team composition of
the agile change management team.
5.4 Outcome
We find that Kotter, Lean and Agile will all produce different outcomes. A key part of deciding
which framework to use will, therefore, be to decide what kind of change the organisation needs.
Kotter’s 8-step process is concerned with implementing one relatively large change, while the
change outcome in Lean will be a series of smaller improvements. The outcome of an agile
change process will be something in between, as each iteration produces a change measure,
but all iterations will be focused towards the same goal. A part of the difference between the
methodologies are the size and frequency of the change outcomes. This is closely related to the
the paradox of evolutionary and revolutionary change, discussed in section 2.3.4.
5.4.1 Revolutionary and evolutionary change
Kotter and Lean represents the two different sides of the paradox of revolution and evolution.
We find Kotter’s 8-step process to be a revolutionary process, designed to be disruptive through
the establishment of the burning platform. Emphasis is put on overcoming change resistance
and inertia (Kotter, 2007), which further indicates that the change is disruptive and not a natural
occurrence. We find Lean on the other hand to be based on an evolutionary form of change,
through the continuous improvement. Here the change happens in small, natural iterations, as
waste is identified and the processes evolve to be more efficient (Modig and Åhlstrøm, 2012).
Again, we argue that Agile can be used for both sides of the paradox depending on the situ-
ation. This is also dependant on both the goal and the time frame of the process. If the goal is
to implement a specific change, the change will be revolutionary. The goal of the change pro-
cess could also be to find new ways of doing something. If used experimentally in this way, the
change will evolve as new things are discovered in the change iterations. When used for evo-

lutionary change, it will be natural to have a longer timeframe and longer iterations than when
used for revolutionary change. In this way, the change will be allowed to evolve over time. A
disruptive, revolutionary change process on the other hand will be more intense, and require
shorter time frames. Because Agile can be used for both sides of the paradox, it will make nav-
igating the paradox easier. In stable periods of time, when evolutionary change is required, the
agile process will be used to experiment with relatively long timeframes and iterations. In un-
stable periods on the other hand, the agile change process will be more focused, and use shorter
iterations. However, it should be noted that if the organisation faces a small window of opportu-
nity and fast, revolutionary change is required, a top-down approach like Kotter might be more
suited (De Wit and Meyer, 2014, p.393). With a top-down approach the top-management has
the control needed to drive through change rapidly.
Figure 5.4: Outcome of agile change
As discussed in this section, Agile is suited for producing both evolutionary and revolution-
ary change. We argue that the main advantage Agile has in this aspect of change management
is the ability to navigate between the two, as shown in figure 5.4.

5.5 Context
Since context is highly dependent on the organisation where the change is taking place, and this
thesis is not concerned with a specific organisation, but the field of change management as a
whole, this section will focus on the parts of the context where an agile approach is different
from Kotter and Lean.
5.5.1 Inner and outer context
As seen in chapter 2, context is often split into inner and outer context. The parts of context
that we find most relevant are: strategy, structure, culture, power relations, normative relations,
cognitive relations and stability.
Strategy
As a part of the inner-context Jacobsen (2012, p.95) writes about strategy, and the dangers of
"locking" an organisation to an approach. This may take many forms, such as focusing on a
single product or service, or a specific kind of customer. This is one of the risks of exploitative
change/innovation as discussed in section 5.2, where Agile can help organisations balancing
the need for exploitative change and explorative change. Thus, they will mitigate the risk of
being "stuck" with a single strategy, and according to Jacobsen (2012, p.95) be more capable of
changing in the future through combining different strategies. Lean, on the other hand is more
concerned with exploitative change, and organisations adopting lean or other forms of process
management runs the risk of becoming "stuck", which leads to slower adaption if a change or
a disruptive innovation hits the market. One example of such a hit to a market is the fall in the
oil price during 2016, which has forced many businesses which had the oil sector as a major
customer to adapt and find new markets. We argue that Agile can offer a more pro-active man-
agement of such an occurrence, even though such a hit to a major market is still a significant
challenge. It is important to note that both Agile and Lean are very customer-focused, but Ag-
ile has a theoretically lower risk of being "stuck" with a single strategy or customer than Lean,
because of Agile’s focus on exploratory change.

Structure
As seen in section 3.1.2, the structure of the traditional hierarchical organisations may no longer
be fit, as it is too rigid and slow (Franklin, 2014). This is also supported by Jacobsen (2012, p.95).
Sharing of knowledge is an important part of agile, and this flow of knowledge is important for an
organisation’s ability to change, whereas the typical rules, routines and procedures that can be
found in Lean have a conserving effect on organisations (Jacobsen, 2012, p.96). The traditional
approach to change management does not offer such a focus on knowledge management, thus
making Agile an appealing approach.
Culture
The famous saying "Culture eats strategy for breakfast" implies that culture is very important
when dealing with change management. According to Jacobsen (2012, p.104-106) a strong or-
ganisational culture can be helpful when trying to change an organisation, but it can also be
detrimental to change depending on the content of the culture. As seen in section 3.3.2 Sahota
(2012) emphasises the need for a match between "agile culture" and the organisational culture,
with an organisational culture based on "collaboration" and "cultivation". If this match exists,
the agile culture has a focus on change and adopting which may have a positive impact on the
ability of the organisation to change.
Power relations and normative relations
While organisational culture is important for Agile, as described in the previous section, we find
that national culture and normative relations, meaning the relation between the organisation
and the national culture, will also be important aspects. As we have seen in section 5.3, Agile
offers a possibility of balancing the paradox of top-down and bottom-up.
This will, however, require a low power distance in order for the autonomous teams to func-
tion effectively, as discussed in section 2.5. According to Jacobsen (2012, p.112-114), a national
culture with a low power distance (Hofstede, 1983) will imply a low power distance in organisa-
tional culture between management and the organisation. This implies that Agile is more suited
for organisations operating in countries with a low power distance than in countries with high

Agile Change Management Framework

Agile Change Management Framework

Recommended

Recommended

More Related Content

Similar to Agile Change Management Framework

Similar to Agile Change Management Framework (20)

More from Andrew Parish

More from Andrew Parish (20)

Recently uploaded

Recently uploaded (20)

Agile Change Management Framework