Overcoming Organisational Challenges related to

Agile Project Management Adoption

Rami Hansenne and Allan Hibner

Supervisor: Dr. Urban Ljungquist

Master’s Thesis in Business Administration, MBA programme

Date of submission: 2011-06-07

 ABSTRACT
For the past few years, Agile methodologies have been hailed as the silver bullet which will
successfully address the high project failure rate. Many organisations have been using a traditional
project management methodology for years and are now either considering or in the progress of
introducing a more agile approach as a substitute for the more rigid, inflexible and control oriented
traditional methodologies. Potential benefits include, but are not limited to, faster return on
investment, better products/services, and higher customer satisfaction. Often however, this leads to a
painful introduction because employees are uncomfortable with the drastic changes Agile methods
impose or because there is internal resistance to change, and in many cases the expected increase in
project efficiency does not occur.

The purpose of this thesis was to determine the perceived challenges related to organisational
adaptation to agile project management and to develop a conceptual model of best practices to help
guide agile adaptation. Research and data collection was performed through a review of relevant
literature within both traditional and agile methods, principles and techniques, along with papers on
organisational transformation and case studies and in parallel, interviews with experts and
practitioners in the field. Data analysis was performed in two phases: the literature review helped us
find data in relevant project management fields and through a subset of the Burke-Litwin
organisational change model extract challenges and questions, and in the second phase the outcome of
interviews based on these questions was fed back through the change model, analysed and compared
with the original data.

Some of the main findings of this thesis are:

x Adaptation to an environment with less structure and control is often a hard challenge, but it
can be overcome with proper guidance and the support of a high-level internal sponsor who
champions the agile vision top down.

x The change in management style from the traditional ‘command and control’ to self-regulation
is a challenge for former project managers, who must evolve into project facilitators.

x For agile adaptation to be successful, it should be implemented company-wide, and not in for
instance a single department.

KEYWORDS: Organisational Transformation, Project management, Methodologies, Agile,

PRINCE2, SCRUM.

i
ACKNOWLEDGMENTS
We would like to express our sincere gratitude to all the people who have contributed to this master
thesis. All of them have assisted us in shaping this thesis to what it is today.

Specifically, we would like to thank our advisor, Dr. Urban Ljungquist, whose commitment,
continuous guidance, frequent feedback and constructive criticism have helped significantly in
upholding and raising the quality of this document. We would also like to express our thanks to our
fellow students who have performed a peer review of this document, thus providing a different
perspective and helping us identifying aspects for improvement.

We are also very grateful to all the participants of our interviews. Without their involvement, this
thesis would not have been possible. Thank you for your enthusiasm, as well as the time and effort
invested in this endeavour.

Thank you as well, to our partners and family for their unconditional support during these at times
very taxing months.

Finally, thank you to all readers of this thesis paper. We sincerely hope you will find this paper as
interesting and thought-provoking to read as it was to write.

Rami Hansenne and Allan Hibner

ii
CONTENTS

ABSTRACT ............................................................................................................................................ I
ACKNOWLEDGMENTS.................................................................................................................... II
CONTENTS ......................................................................................................................................... III
FIGURES AND DIAGRAMS ............................................................................................................. V
TABLES ................................................................................................................................................ V
1 INTRODUCTION ........................................................................................................................ 1
1.1 BACKGROUND ......................................................................................................................... 1
1.2 DISCUSSION OF THE PROBLEM ................................................................................................ 1
1.3 PROBLEM FORMULATION AND PURPOSE.................................................................................. 2
1.4 LIMITATIONS AND DELIMITATIONS ......................................................................................... 2
1.5 THESIS STRUCTURE.................................................................................................................. 3
2 THEORY ....................................................................................................................................... 5
2.1 ORGANISATIONAL CHANGE..................................................................................................... 6
2.1.1 Introduction ..................................................................................................................... 6
2.1.2 Organisational Development........................................................................................... 6
2.1.3 Organisational Transformation....................................................................................... 7
2.1.1 Organisational Change Models ...................................................................................... 7
2.2 DERIVATION OF AN AGILE ADOPTION CHANGE MODEL ....................................................... 10
2.3 COMPARISON OF TRADITIONAL AND AGILE PROJECT MANAGEMENT .................................. 14
2.4 TRADITIONAL PROJECT MANAGEMENT AND PRINCE2 ....................................................... 15
2.4.1 History ........................................................................................................................... 15
2.4.2 Principles....................................................................................................................... 16
2.4.3 Processes ....................................................................................................................... 16
2.4.4 Components ................................................................................................................... 16
2.4.5 Techniques ..................................................................................................................... 16
2.4.6 Roles .............................................................................................................................. 17
2.5 AGILE PROJECT MANAGEMENT AND SCRUM ...................................................................... 17
2.5.1 History ........................................................................................................................... 17
2.5.2 Principles....................................................................................................................... 17
2.5.3 Process .......................................................................................................................... 18
2.5.4 Components ................................................................................................................... 18
2.5.5 Roles .............................................................................................................................. 18
2.6 METHODOLOGY COMPARISON PER PROJECT MANAGEMENT AREA ..................................... 20
2.6.1 Integration Management ............................................................................................... 21
2.6.2 Scope Management ........................................................................................................ 24
2.6.3 Time Management ......................................................................................................... 25
2.6.4 Cost and Procurement Management ............................................................................. 27
2.6.5 Quality Management ..................................................................................................... 28
2.6.6 Human Resource Management...................................................................................... 29
2.6.7 Communications Management ...................................................................................... 30
2.6.8 Risk Management .......................................................................................................... 32
3 METHOD .................................................................................................................................... 34
3.1 PRESTUDY AND APPROACH.................................................................................................... 34
3.2 QUANTITATIVE METHODS...................................................................................................... 34
3.3 QUALITATIVE METHODS ........................................................................................................ 34
3.3.1 Case studies ................................................................................................................... 34

iii
 3.4 MIXED METHODS ................................................................................................................... 35
3.5 RESEARCH METHODOLOGY SELECTION ................................................................................. 36
3.6 INTERVIEW STRATEGY ........................................................................................................... 36
3.6.1 Target audience ............................................................................................................. 36
3.6.2 Strategy.......................................................................................................................... 36
3.6.3 Interview Composition................................................................................................... 37
3.6.1 Data analysis approach ................................................................................................. 39
3.7 RELIABILITY .......................................................................................................................... 39
3.7.1 Reliability ...................................................................................................................... 39
3.7.2 Forms of bias ................................................................................................................. 39
3.7.3 Validity and generalizability ......................................................................................... 40
3.8 VALIDITY ............................................................................................................................... 40
3.8.1 Construct validity .......................................................................................................... 40
3.8.1 Internal validity ............................................................................................................. 40
3.8.2 External validity ............................................................................................................ 40
4 DATA COLLECTION AND FINDINGS ................................................................................. 41
4.1 INTERVIEWS ........................................................................................................................... 41
4.1.1 Brief profile of participants ........................................................................................... 41
4.1.2 Information acquired during interviews ........................................................................ 42
4.2 CASE STUDIES ....................................................................................................................... 48
4.2.1 Brief description of cases selected ................................................................................ 48
4.2.2 Case Study 1: Going Agile - A Case Study .................................................................... 49
4.2.3 Case Study 2: Forming to Performing .......................................................................... 49
5 ANALYSIS .................................................................................................................................. 51
5.1 ORGANISATIONAL CULTURE ................................................................................................. 51
5.2 LEADERSHIP........................................................................................................................... 51
5.3 STRUCTURE ........................................................................................................................... 52
5.4 MANAGEMENT PRACTICES .................................................................................................... 52
5.5 WORK UNIT CLIMATE ........................................................................................................... 53
5.6 INDIVIDUAL AND ORGANISATIONAL PERFORMANCE ............................................................ 53
6 CONCLUSIONS AND RECOMMENDATIONS.................................................................... 55
6.1 SUMMARY .............................................................................................................................. 55
6.2 CONCLUSIONS........................................................................................................................ 55
6.3 IMPLICATIONS AND RECOMMENDATIONS .............................................................................. 56
6.3.1 Theoretical implications ................................................................................................ 56
6.3.2 Practical implications and recommendations ............................................................... 56
6.4 POSSIBLE FUTURE RESEARCH ................................................................................................ 59
7 REFERENCE LIST.................................................................................................................... 60
8 APPENDICES ............................................................................................................................. 63
8.1 INTERVIEW QUESTIONS .......................................................................................................... 63
8.2 LINKEDIN TARGET GROUPS .................................................................................................. 65

iv
FIGURES AND DIAGRAMS
FIGURE 1-1 : THESIS STRUCTURE ............................................................................................................................. 3
FIGURE 2-1 : LEWIN’S ORGANISATIONAL CHANGE MODEL[39] ................................................................................. 6
FIGURE 2-2 : KOTTER’S EIGHT-STEP MODEL[34] ........................................................................................................ 8
FIGURE 2-3 : LEAVITT’S DIAMOND MODEL[34] .......................................................................................................... 8
FIGURE 2-4 : WEISBORD’S SIX-BOX MODEL[72] ....................................................................................................... 8
FIGURE 2-5 : MCKINSEY’S 7S MODEL[48] ................................................................................................................. 9
FIGURE 2-6 : THE BURKE-LITWIN CHANGE MODEL[12] ........................................................................................... 10
FIGURE 2-7 : RESEARCH FOCUS PHASES IN KOTTER’S 8 STEP MODEL[34]................................................................. 10
FIGURE 2-8 : RESEARCH FOCUS AREAS IN THE BURKE-LITWIN MODEL[12] .............................................................. 11
FIGURE 2-9 : DERIVED AGILE ADOPTION RESEARCH MODEL .................................................................................. 13
FIGURE 2-10 : THE POPULARITY OF PROJECT MANAGEMENT CERTIFICATIONS PER REGION [31] ............................... 15
FIGURE 2-11 : THE CORE SCRUM PROCESS[43] ........................................................................................................ 18
FIGURE 2-12 : THE CORE PROJECT MANAGEMENT AREAS AS DEFINED BY THE PMBOK [50] .................................. 20
FIGURE 2-13 : THE HIGH LEVEL PRINCE2 PROCESS MODEL [25] ............................................................................ 21
FIGURE 2-14 : THE COMPLETE PRINCE2 PROCESS MODEL [25] .............................................................................. 22
FIGURE 2-15 : SCRUM PROCESS OVERVIEW [16] ...................................................................................................... 23
FIGURE 2-16 : THE TRADITIONAL PROJECT MANAGEMENT LIFECYCLE, WITH UPFRONT SCOPE PLANNING[50]........ 24
FIGURE 2-17 : THE AGILE PROJECT MANAGEMENT LIFECYCLE, WITH ITERATIVE SCOPE PLANNING...................... 25
FIGURE 2-18 : AN EXAMPLE PRODUCT BREAKDOWN STRUCTURE [25] .................................................................... 26
FIGURE 2-19 : AN EXAMPLE OF A PRODUCT BACKLOG .......................................................................................... 27
FIGURE 2-20 : THE PRINCE2 FOUR LAYER MANAGEMENT MODEL [25] ................................................................ 29
FIGURE 2-21 : POSSIBLE PROJECT STAKEHOLDERS [25] ............................................................................................ 31
FIGURE 2-22 : THE PRINCE2 RISK MANAGEMENT CYCLE [25] .............................................................................. 32
FIGURE 3-1 - RESEARCH CHOICES ACCORDING TO SAUNDERS[54] ........................................................................... 35
FIGURE 4-1 : TUCKMAN’S PHASES OF GROUP DEVELOPMENT [38] .......................................................................... 50

TABLES
TABLE 1: DERIVATION OF AGILE ADOPTION RESEARCH MODEL ............................................................................. 12
TABLE 2: COMPARISON OF TRADITIONAL AND AGILE PROJECT MANAGEMENT...................................................... 14
TABLE 3: INTERVIEW QUESTIONS ........................................................................................................................... 38
TABLE 4: INTERVIEWEE PROFILES .......................................................................................................................... 41
TABLE 5: CHALLENGES AND RECOMMENDATIONS RELATED TO ORGANISATIONAL CULTURE ............................... 56
TABLE 6: CHALLENGES AND RECOMMENDATIONS RELATED TO LEADERSHIP ........................................................ 57
TABLE 7: CHALLENGES AND RECOMMENDATIONS RELATED TO STRUCTURE ......................................................... 57
TABLE 8: CHALLENGES AND RECOMMENDATIONS RELATED TO MANAGEMENT PRACTICES .................................. 58
TABLE 9: CHALLENGES AND RECOMMENDATIONS RELATED TO WORK UNIT CLIMATE ......................................... 58
TABLE 10: CHALLENGES AND RECOMMENDATIONS RELATED TO INDIVIDUAL AND ORGANISATIONAL
PERFORMANCE ............................................................................................................................................. 58
TABLE 11: LINKEDIN GROUPS USED TO APPROACH INTERVIEW CANDIDATES ........................................................ 67

v
1 Introduction
Project management as a discipline underpins much economic activity. Projects drive businesses in
industries as diverse as ICT, pharmaceuticals, construction and aerospace. Most organisations use
projects as a way to turn strategies into actions and realize their objectives. Choosing the right project
management methodology is therefore an essential component of any business strategy. Different
project management methodologies put different demands on the organisational structure, market
strategy, processes, management expectation, as well as the team member roles and competencies.
More traditional methodologies emphasize rigid planning and tight command and control, whereas an
agile approach focuses more on flexibility, leadership and team collaboration. Traditional methods put
a lot of emphasis on analysis and planning in early phases of the project, making estimations and
assumptions of time and cost before all the factors are known. These assumptions often build on
models and templates, combined with previous experience. In contrast, agile methodologies focus on
adapting to the situation, making it harder to develop an initial estimate of time consumption and cost.
As a result, they are more capable of dealing with changing requirements, but they are also more prone
to scope creep, thus increasing the risk of budget overruns.

1.1 Background

Traditional project management is defined by the Project Management Body of Knowledge (PMBoK)
[50]
as "a set of techniques and tools that can be applied to an activity that seeks an end product,
outcomes, or a service". Traditional project management methodologies are usually divided into
phases or steps that must be finished in order to drive the project forward. Requirements are gathered,
analysed and documented in an ordered fashion. There is a strong emphasis on control, a strict
decision hierarchy, and a well-defined process surrounding the steps, as well as a number of formal
"deliverables" for each step. Examples of traditional methodologies include PRINCE2[25] (“PRojects
IN Controlled Environments”) the PMBoK [50] and many others.

Agile development [13] methodologies such as SCRUM [57], and Feature-Driven Development (FDD)
[45]
are based on a more lightweight, iterative project organisation, where requirements may evolve
during the project life cycle and where collaboration is achieved through extensive customer
involvement and more empowered, self-organizing and cross-functional teams. In contrast to
traditional “heavyweight” methodologies, Agile methods deal flexibly with scope changes, put much
less emphasis on documentation and formal procedures and encourage simplicity in design. As such,
these methodologies aim at a faster time-to-market and increased customer satisfaction.

1.2 Discussion of the Problem

According to a survey of the Standish Group, $80 -145 billion per year is spent on failed and cancelled
projects [27]. Forrester Research indicates a 66% project failure, costing U.S. businesses at least $30
billion every year [27]. According to the Meta Group, 60% - 80% of project failures can be attributed
directly to poor requirements gathering, analysis, and management [27]. Improving these performance
records is essential for any organisation. However, if traditional project management is ineffective, it
is necessary to research other methods of managing and delivering projects. This is where Agile
methods come into play.

For the past few years, Agile methodologies have been hailed as the silver bullet which will
successfully address the high project failure rate. Many organisations have been using a prescriptive
traditional project management methodology for years and are now either considering or in the
progress of introducing a more agile approach to take advantage of the numerous benefits that they
offer to an organisation. Those benefits include, but are not limited to, quicker return on investment,
better quality products and services, and higher customer satisfaction. To date, however, there is no

1
structured process (at least that is published in the public domain) that guides organisations in
adopting Agile practices [62]. Also, while Agile methodologies promise numerous advantages over
traditional methodologies, they are not without limitations and pitfalls and in many cases the expected
increase in project efficiency does not occur. This might be because the agile approach is not
implemented correctly or is unsuitable for the types of projects the organisation undertakes.

In spite of a growing need for agile project management, little is known about how an organisation
should approach the implementation of such a radically different methodology, while mitigating the
challenges in terms of human resource structure, processes, client interaction, etc. Research shows that
organisations find it difficult to adopt and implement agile approaches psychologically or technically
[51]
. While research has been done on specific aspects of Agile adoption (such as the introduction of
self-organising teams, agile risk management, etc.), what is lacking is a holistic model of best
practices to guide overall Agile adoption at an organisational level.

1.3 Problem formulation and purpose

The purpose of this thesis is to determine the perceived challenges related to organisational adaptation
to agile project management and to develop a conceptual model of best practices to help guide agile
adaptation.

In short, our problem formulation is the following:

How can Agile project management methodologies be introduced in a traditional organisation, in such
a way as to avoid the pitfalls and manage the related challenges?

Concretely, our research objectives are:

x To examine organisational change theory and select or derive a conceptual change model to
apply to the context of agile adoption
x To understand the main characteristics of/differences between traditional and agile project
management
x To analyse the impact of agile project management adoption on organizational factors
x To define a set of recommended best practices to help overcome the related challenges when
transitioning from a traditional to an agile methodology

1.4 Limitations and delimitations

The focus of this thesis is on the challenges/best-practices related to the actual project management
aspects and not on supporting tooling or implementation specifics as sometimes proposed by
methodologies. It is also not within scope to define an entirely new methodology or in-depth change
process, but rather to formulate a set of best practices for application within the context of introducing
an Agile approach in a Traditional organisation.

In order to develop a conceptual framework, we start out with an analysis of two of the most widely
used methodologies in Europe: the traditional PRINCE2 and the agile SCRUM. These will act as
concrete prototypes for their respective methodology types. We have opted to research specific
methodologies instead of basing ourselves on a purely high level methodology stream comparison, in
order to identify very concrete problems and challenges.

We have opted for PRINCE2 as the prototype traditional project management methodology, as it is by
far the most popular and widely adopted methodology in Western Europe[25]. In addition, many of the
custom in-house methodologies used by companies in Europe are variations of PRINCE2. This choice
therefore allowed us to more easily find experienced subjects to participate in interviews in order to
gather qualitative data on this methodology. In the US, the PMI is the most widely adopted

2
methodology and therefore, we will also reference the PMBoK in areas where this methodology
deviates from or elaborates on PRINCE2. In general however, both PRINCE2 and the PMBoK share a
similar enough approach that they can be easily adapted to complement each other, as described on the
official PRINCE2 website [63].

Our choice for SCRUM to represent agile project management was also driven by the fact that
according to latest surveys [52], SCRUM is the most popular agile project management methodology in
IT development. As of late, Scrum is used almost interchangeably with agile (while Scrum is in fact
just one project management method beneath the umbrella of Agile methods). It is clear that Scrum
has become the most popular exponent of agile over the past few years [60].

While the results of this thesis are founded by a literature review, analysis as well as concrete
experience captured through interviews, the actual benefits of the suggested best practices cannot be
quantified as this would require several extensive case studies of organisations integrating our
suggestions into their approach. This could be an area of further research.

1.5 Thesis structure

The research in this thesis is performed according to the structure outlined in Figure 1-1.

Figure 1-1 : Thesis structure

Chapter 1 provides an introduction and delineates the problem this thesis researches. It also defines a
set of research questions which served as input and guidelines for two parallel research tracks.

Chapter 2 elaborates on the theories and references which were used to conduct our research. It
provides an overview of the theory on organisational transformation and an overview of both
traditional and agile project management frameworks.

Chapter 3 describes the methods we have applied in the course of our research. On the one hand a
review of relevant literature was performed, in which we gain further insight into the main differences
between both traditional and agile methodologies, the related organisational challenges in migrating
from one methodology to another and the possible ways in which these challenges may be overcome.
Literature streams consist of both the reference literature provided by the respective founding
organisations, papers on organisational transformation and methodology adoption, as well as concrete

3
case studies relating to the effects of introducing a new methodology into an organisation. This
provided use with the context to formulate specific research questions on the basis of which interviews
with experts and practitioners in the field were performed, which then served as qualitative data. In
parallel, we have analysed documented case studies which were relevant to our research questions.

Chapter 4 documents the data collection results following the interview process and case study
review. This served as the raw data which was analysed as described in the subsequent chapter.

Chapter 5 details the actual analysis and evaluation performed on the data gathered. The objective of
this chapter is to derive a conceptual model of best practices for Agile project management adoption,
supported by both the researched theory as well as the insights of the interviewed field experts.

Chapter 6 summarizes our conclusions and documents the implications. Our goal was to list a set of
recommended best practices in the context of an organisational change model in order to help guide an
Agile transformation.

4
2 Theory

In this chapter we summarize the theoretical foundations for our research, as gathered through a
literature review which provides the basis of our subsequent analysis. As will become clear, the
introduction of an Agile methodology impacts many organisational factors, therefore the chapter starts
out with an overview of Organisational Change theory, along with some well-known change models.
From these models, we have derived our own model, which has served to analyse and categorize data
gathered through interviews in chapter 5.

Next, the theory continues with a high-level comparison of the traditional versus the agile approach in
each project management field, in order to clarify the differences between them (and consequently the
challenges in transitioning from one method to another). The model used to compare methodologies is
based on the 9 Project Management Fields of Practice as described in the Project Management Body
of Knowledge [50].

This is followed by a theoretical overview of PRINCE2 and SCRUM, respectively the leading
traditional and agile project management methodologies in use in Europe. Note that these are
subordinate to the theoretical foundations of the thesis and are intended to understand the processes,
concepts and techniques discussed by practitioners during the interviews, as well as to gain an
understanding of the main practical differences between these two concrete methodologies. The theory
on these methodologies is broken down into the same project management fields described above, in
order to allow a structured comparison.

As this topic is closely related to actual practice, there are some practitioner journals, conference
papers and articles included in the reviewed literature. The major development of this literature
review, however, is built on academic sources. The practitioners’ literatures and publications serve as
a means to inspire ideas and to enable us to gain insight into the concrete implementation of Agile
methods in practice.

5
2.1 Organisational Change
2.1.1 Introduction

The adoption of Agile methodologies is usually a gradual process with a significant impact on many
organisational factors, such as its processes, human resource structure, client interactions and
involvement, revenue model, etc. As such, it requires a transformation at organisational level.
Therefore, we provide the reader with an overview of the concepts of Organisational Development and
Organisational Transformation in this chapter, as these will be the theoretical basis for our Agile
Adoption model.

2.1.2 Organisational Development

Organisational Transformation theory finds its roots in the concept of Organisational Development
(OD). Organisational Development is a long range conceptual effort at organisational level to improve
the effectiveness and viability of the organisation and more specifically its problem solving and
renewal processes, particularly through more effective and collaborative management of
organisational culture, often with the assistance of a change agent or catalyst and the use of the theory
and technology of applied behavioural science [11]. Warren Bennis calls it a response to a changing
environment and can be seen as a complex educational change strategy to alter the beliefs, attitudes,
values and structure of an organisation to such an extent that it is better able to adapt to new
technologies, markets or challenges [6]. While behavioural science has provided the basic foundation
for the study and practice of organisational development, new and emerging fields of study have such
as systems thinking, leadership studies, organisational leadership, and organisational learning have
emerged as Organisational Development catalysts. Organisational Development emphasis is on
process, its models are linear, and focuses on incremental and continuous change.

Kurt Lewin (1898–1947) is considered to be the founding father of Organisational Development,

although the concept only became more popular in the 1950’s. Lewin launched the ideas of group
dynamics and action research which underpin the Organisational Development process. Lewin
described a three step change model, known as the Unfreeze-Change-Refreeze model [39] (Figure 2-1).

[39]
Figure 2-1 : Lewin’s Organisational Change Model

Douglas McGregor and Richard Beckhard actually introduced the term organisational development to
describe an innovative bottoms-up change effort that fit no traditional consulting categories [73].

6
Lippitt, Watson and Westley’s model of planned change [11] expands Lewin's three-step model to five
phases:
x Need
x Establish a change relation (client-agent)
x Clarification and diagnosis of problem
x Evaluate Alternatives
x Transformation of intentions into actual change efforts
x Generalization and stabilization of change (refreezing)
x Terminate relation

2.1.3 Organisational Transformation

Organisational Transformation can be seen as a further evolution of Organisational Development. It is

a process that radically alters the organisations strategic direction, including fundamental changes in
structures, processes and behaviours. Munro [42] states that transformational change is frequently
identified as the need for companies to change as the environment changes. Agility and rapid response
are important to meet customer’s demands, but not all organisations are able to make successful
transformations. Blumenthal and Haspeslagh [7] indicate that in order to qualify as transformational
change, the majority of individuals within an organisation must change their behaviour. This is usually
achieved through a long running process which promotes paradigmatic change and helps the
organisation to better fit or create desirable future environments. For organisational transformation to
operate, change is required in strategy and structure. Tushman and O'Reilly state, [71] "long-term
success is marked by increasing alignment among strategy, structure, people and culture."

Successful organisations are those that regularly refresh their strategies, structures and skills with the
environment. Tushman and O'Reilly [71] state that older, larger, successful organisations develop
"structural inertia" and/or "cultural inertia". Structural inertia is resistance to change, which has roots
in the organisation's structures, systems, procedures and processes that are tied to organisational size,
complexity and interdependency. Cultural inertia is develops as lessons from success of the past
become embedded in the shared expectations, stories, values and norms of the way things are to be
done in the organisation. Haveman [28] states that the more institutionalized the culture, the more
complacent an organisation becomes. Managing company culture is an important aspect of managing
change, because bureaucratic companies are subject to excessive rigidity in the application of rules and
regulations and severely constrain their ability to transform in answer to environmental shifts.

2.1.1 Organisational Change Models

Organisational change models as described in organisational change theory serve as a basis for
understanding the interrelationships of different variables and how they may respond to change. They
are therefore ideally suited for structuring and contextualizing the agile adoption challenges and best
practices resulting from our analysis. In this section we will briefly describe some prominent models
and the Method chapter will describe how we leverage such a model for our analysis.

There are multiple well founded organisational change models in existence which assist in formulating
specifically tailored change processes in different contexts. Generally, these can be categorized in two
main streams. A first stream, consists of procedural models which describe the different phases or
steps in which change can be effectively introduced into an organisation. The most influential
contributor in change theories of this type was Kurt Lewin and his previously mentioned, Unfreeze-
Change-Refreeze model [39]. Other models in this category include Kotter’s eight-step model [34] for
managers to follow to ensure success of a change initiative.

7
 [34]
Figure 2-2 : Kotter’s eight-step model

A second category of organisational change models focuses more on the key organisational factors
which affect (or are affected by) the introduction of change in an organisation, as well as the
relationships between these factors. One of the earliest models in this category is Leavitt’s Diamond
model [37] which highlights the interdependencies between an organisation’s structure, technology,
people and tasks.

[34]
Figure 2-3 : Leavitt’s Diamond model

Many other classical models such as Weisbord’s Six-Box Model [72], McKinsey’s 7S model and
Burke-Litwin’s 12-factor change model [12] have extended Leavitt’s basic model. The Six-box model is
a framework inspired by techniques and assumptions in the field of organisational development and
was originally developed by the American analyst Marvin Weisbord to assess the functioning of
organisations and the impact of change. It pays attention to factors such as planning, incentives and
rewards, the role of support functions, internal competition among organisational units, remuneration,
partnerships, hierarchies and the delegation of authority, organisational control, accountability and
performance assessment.

[72]
Figure 2-4 : Weisbord’s Six-Box Model

8
Another well-known model for evaluating and guiding organisational change is McKinsey’s 7s model,
developed by Pascale and Athos [48]. It details 7 organisational focus areas and their interrelationships.
Of these factors strategy, structure and systems are considered ‘hard’ and skills, staff, style and shared
values are considered soft factors. Strategy refers to the vision as set by top management. Structure
encompasses the organisational hierarchy as well as command and control structure. Systems include
the collection of supporting processes, both formal and informal. Skills include the competencies
required to execute tasks. Staff includes all HR processes such as recruitment, training and career
guidance. Style reflects the leadership and management styles in an organisation. Shared values reflect
the organisational culture and set of beliefs. The model also describes the effect each of these variables
can have on other variables when change is introduced in an organisation.

[48]
Figure 2-5 : McKinsey’s 7S model

The Burke-Litwin Causal Change Model [12] has been developed to assist with the analysis and
adoption of organisational change and performance. This model strives to introduce change in the
performance of a team or an organisation by establishing links between performance and the internal
and external factors which affect performance. This model is based on assessing the organisational as
well as environmental factors which can be tweaked so as to ensure a successful change. The Burke-
Litwin change model begins with outlining a framework of the affecting factors which can be
manipulated to guarantee a smoother transition from one phase of the change process to another. Of
these factors, the external environment is considered to be the most powerful driver. This in turn leads
to significant changes in an organisation’s mission and strategy, its organisational culture and its
leadership. In a next phase, these lead to changes to structure, systems and management practices.
These are more operational factors and changes in them may or may not have an organisation-wide
impact. Subsequently, these changes affect motivation, which in turn impacts on individual and
organisational performance. Each of the variables interacts with the others and a change in any one of
them can eventually impact the others. This is useful in explaining not only how organisations
perform, but also how they can be changed.

9
 [12]
Figure 2-6 : The Burke-Litwin Change model

2.2 Derivation of an Agile Adoption Change Model

As previously mentioned, the adoption of Agile methodologies requires a transformation at

organisational level, as it affects many organisational factors, including its processes, human resource
structure, client interactions, revenue model, etc. In order to perform a structured analysis of the main
organisational challenges and agile adoption best practices, we therefore decided to structure our
research according to a well-founded organisational change model.

In chapter 2.1.1 we described the difference between process and factor based change models. Since
this study intends to identify the main challenges and best practices to overcome these challenges in
each of the affected organisational areas rather than develop an actual change process, we will focus
specifically on the second set of models which help identify the change factors and their relationships.
We can however use a process model to illustrate the specific phases our research will concentrate on.
Specifically, we target the actual adoption phase and presume top management’s decision to
implement an Agile method has already been taken and this vision has been communicated throughout
the company. In other words, we will mainly focus on the implementation challenges during steps 5, 6
and 7 of Kotter’s 8 step model [34] (see Figure 2-7)

[34]
Figure 2-7 : Research focus phases in Kotter’s 8 step model

Of the described factor based change models, the Burke-Litwin model [12] is the most elaborate and
includes the variables identified in the other models as well. As such, we have decided to use this
model as the basic framework for framing and categorizing the challenges and best practices identified
during our research. Since we are addressing the actual implementation phase and wish to limit the

10
scope of our research to the specific problem areas of Agile adoption (according to our literature
review), we have selected a subset of the factors in the model, as illustrated in Figure 2-8.

[12]
Figure 2-8 : Research focus areas in the Burke-Litwin model

In the table below, we provide a description of each of the factors in the model, along with our
reasoning for selecting or deselecting a particular dimension for our actual analysis.

Dimension of Model Description Reason to in/out scope

External Concerns the key external drivers The reasons for adopting Agile
environment (e.g. markets, legislation, competition methods may have been driven by
and the economy) and their impact on external factors, however for our
the organisation [12] analysis, we assume the decision has
already been made (during the first 2
steps of Kotter’s 8 step model [34])
and we focus on the actual
introduction of Agile methods
within the organisation. Therefore
we will not analyse challenges for
this dimension.
Mission and Strategy Describes the overall vision and Similarly, we assume that a buy-in
mission statement as laid out by top for the implementation of agile
management, along with the methods from top management has
employee’s perception of these [12]. already been attained (during steps 3
and 4 of Kotter’s 8 step model [34])
and incorporated in the corporate
strategy.
Leadership This considers the attitudes and Successful Agile project
leadership style of senior personnel management requires a significant
and how these behaviours are shift in leadership style [21], so this is
perceived by/affect the organisation an important dimension to include in

11
 as a whole [12] our analysis.
Organisational Encompasses overt and covert rules, Research has identified
Culture values, customs and principles that organizational culture as a factor
guide organisational behaviour [12]. that potentially
affects the deployment of agile
methods [29]. Therefore, we include
this dimension.
Structure Describes the arrangement of Agile teams are composed
functions and people in specific areas, differently than traditional ones and
their level of responsibility and the responsibilities also differ radically
[5]
key decision-making, communication , so this dimension is in scope.
and control relationships [12].
Systems Deals with an organisation’s policies Our analysis will not take into
and procedures, including systems for account the specific infrastructure or
reward and performance appraisal, supporting HR processes to assist
management information, HR and with Agile adoption (see limitations
resource planning [12]. in chapter 1.4), so this dimension is
not included in the analysis.
Management Concerns the way management uses Since this thesis specifically focuses
Practices human and material resources, their on project management aspects, the
relationship with subordinates and shift in management practices is an
general management style [12]. indispensable dimension of our
analysis.
Work Unit Climate Concerns the overall feelings, Communication, relationships and
impressions and expectations of expectations between team members
employees, as well as the differ radically in Agile
relationships between teams and environments [5] , so this dimension
individuals [12]. cannot be ignored.
Tasks and Individual Encompasses the individual skills, Agile methods do not require
Skills abilities and knowledge required to drastically new skill sets as chapter
effectively execute tasks [12]. 2.5 will show, so we leave this
dimension out of scope.
Individual Needs and Describes the psychological factors While we do focus on challenges in
Values which could increase job satisfaction team dynamics (work unit climate)
and enrichment [12]. we will not bring individual
psychological factors into scope for
this analysis as these are difficult to
assess through our selected research
methodology (see chapter 3).
Motivation Considers the significance of One of the major objectives of Agile
individual and organisational goals methods is improving employee
and the extent to which these are in motivation and participation (it is
line [12]. even one of the 12 statements of the
Agile Manifesto [15]), so this is not
an area in which we expect major
challenges. As such, we leave this
area out of scope for our analysis.
Individual and Handles factors such as productivity, As will be described in chapter 2.3
Organisational efficiency, quality and customer and onwards, Agile methods deal
Performance satisfaction [12]. very differently with quality
management, planning and
performance in general, therefore
this dimension will also be included
in our analysis.
Table 1: Derivation of agile adoption research model

12
Applying the scope defined above, we can derive our research model as illustrated in Figure 2-9,
which is a subset of the overall Burke-Litwin model. This will be our reference framework for the
categorization and contextualization of the main agile adoption challenges and associated best
practices we derive during our analysis.

Figure 2-9 : Derived agile adoption research model

13
2.3 Comparison of Traditional and Agile Project Management

The theory so far has provided us with a model to analyse the impact of a change in project
management methodology on the different organisational factors. In order to apply this model to our
concrete case of Agile adoption, the next chapters provide more insight into the main characteristics
and the main differences between Traditional and Agile project management methodologies.

Table 2 summarizes the key high-level differences between Traditional and Agile project
management.

Traditional Project Management Agile Project Management

Principles and Context x Project scope is known in advance and x Complete project scope is
will not change significantly[20] not known at start and will
x Events affecting the project are evolve during the project[49]
predictable x Unpredictable events may
x Processes must be well defined, affect the project
repeatable and their execution rigidly x Processes must be
controlled lightweight and easily
adaptable to the project
context
Origin and Theory x Scientific Management[20] x Adaptive management and
x Process based approach chaos management[20]
x Iterative approach
Focus x Quality [50] x People and teamwork [59]
x Cost/Earned value [50] x Customer value [59]
x Planning/timing [50] x Execution [59]
Key characteristics x Full in-depth upfront planning x Incremental refinement and
x Continuous command and control re-planning
x Management by Exception x Self-organizing expert
x Formal hierarchy teams
x Disciplined adherence to processes x Flat hierarchy
x Active client participation
Key strengths x Controls scope creep through rigid x Thrives in dynamic
control over requirements [20] environments with strong
x Strongly emphasizes and controls the client participation [20]
quality of deliverables x Very reactive to changes
[49]
x Deviations in terms of cost or planning
are detected in an early stage x Strong team involvement
x Easily teachable and repeatable and collaboration
x Efficient monitoring and resource x Improved customer
control through incremental project satisfaction and team
lifecycle motivation[55]
x Quick and easy to learn
x Low start-up time
Key weaknesses x Poorly suited to dynamic and uncertain x Susceptible to scope creep
project environments [20] as clients have the luxury of
x Any changes in the later project stages changing requirements on
may have a significant impact on the an on-going basis [55]
overall project x Overall cost and planning
x Initial plan often falls quickly out of cannot be determined
touch with reality and requires constant upfront
revision x Less efficient for large
x Inappropriate for small projects due to teams due to daily stand-ups
overhead of formal deliverables x Not usable for fixed price
x Less frequent interaction with projects
stakeholders
Table 2: Comparison of Traditional and Agile project management

14
The individual characteristics described above will be clarified in the next chapters by comparing 2
concrete methodologies, PRINCE2 and SCRUM. These will act as concrete prototypes for their
respective methodology types. We have opted to research specific methodologies instead of basing
ourselves on a purely high level methodology stream comparison, in order to identify very concrete
problems and challenges. They also provide context for the processes, tools and techniques described
by practitioners during the interviews in chapter 4.1.

2.4 Traditional Project Management and PRINCE2

The objective of this chapter is to provide a high level summary of PRINCE2 as a prototype of
traditional project management methodologies. It is not our objective to offer an in-depth,
comprehensive overview of this methodology, as this is amply performed in other literature. It is
merely intended to provide the reader with enough context for the analysis which follows in later
chapters. While this chapter gives a general overview, chapter 2.6 and onwards will focus closer on the
PRINCE2 vision, tools and techniques in the context of each of the main project management areas.

2.4.1 History

PRINCE stands for ‘PRojects IN Controlled Environments’ and is a structured method for effective
project management, first established in 1989 by the British Office of Government Commerce [25]. It is
a further evolution of PROMPTII, a project management method created in 1975 by Simpact Systems
Ltd. In 1996, an updated version, PRINCE2, was launched, which provided improved guidance on
projects of all types. Currently, PRINCE2 is the de facto standard used extensively by the UK
government and is widely recognized and used in the private sector worldwide.

[31]
Figure 2-10 : The popularity of project management certifications per region

As determined by a recent study and illustrated in Figure 2-10, PRINCE2 is by far the most popular
traditional project management methodology in Europe and Australia. In the USA, the PMBoK
remains the dominant traditional project management methodology, however steps have been taken by
both the founding organisations and the private sector to align and integrate both methodologies. This

15
is possible as both methodologies share a similar process model and the PMBoK offers a high level,
largely prescriptive, guiding framework, whereas PRINCE offers a lower level descriptive and directly
applicable model. With some alignment of concepts and processes, they can therefore be made to
reinforce each other [26].

2.4.2 Principles

The PRINCE2 methodology is founded upon seven basic core principles. First and foremost, a project
must have a Continued Business Justification. Not only must there be a justifiable reason to start a
project (as detailed in a Business Case), but this reason must remain valid throughout the life of a
project and must be formally documented and periodically re-evaluated and approved – especially
when project tolerances are exceeded at any point during the project lifecycle. PRINCE2 project teams
are also expected to learn from experience. Experiences are documented during the project lifecycle in
a Lessons Log and every project ends with a review in order to describe the lessons learned for
incorporation into any subsequent project. Projects have well defined and agreed-upon roles and
responsibilities that engage all aspects of the involved internal or external organisations: business, user
and supplier. All stakeholder interests must be represented in the project management team.
PRINCE2 projects are Managed by Stages. Multiple control points are set throughout the project,
which allows projects to be planned, monitored and controlled on a stage-by-stage basis. Per stage,
tolerances are set, which allows Management by Exception. When tolerances are exceeded, these
issues are escalated to the next level of management in order to decide how to proceed. PRINCE2 is
Product Focused method and all work is planned around agreed-upon output products which should
meet well defined quality criteria. Finally, PRINCE2 was modelled to allow tailoring to suit the
project environment. All essential processes must be present, but their concrete implementation can be
adapted, according to a project’s size, complexity, importance, environment and risks.

2.4.3 Processes

PRINCE2 is a process-driven method, which contrasts with adaptive methods such as SCRUM. It
defines eight main processes (illustrated in Figure 2-13), which are further subdivided in over 40
activities, each of which is characterized by key inputs, role assignments and deliverables. The
processes are described in chapter 2.6.1.

2.4.4 Components

PRINCE2 describes eight components which are required in order to successfully run a project. A
Business Case provides the justification of a project. Organisation outlines the roles and
responsibilities of all project members. Plans describe the products to be described, how work should
be executed and by whom. Controls define how the project manager and project board will exercise
control over the project. Risk Management describes how the project should mitigate any risks which
may occur during the project lifecycle. Quality Management defines how the project will assure that
all deliverables will meet the quality requirements. Configuration Management dictates how
deliverables are identified and tracked. Finally, Change Control specifies how to manage changes in
scope or specifications.

2.4.5 Techniques

PRINCE2 provides three techniques in order to support the above mentioned processes. Product
Based Planning defines the project in terms of outputs (rather than activities). Change Control defines
how to report, assess the impact and escalate changes and issues. Quality Reviews provide a structured
technique for assessing whether a product meets the business requirements.

16
 2.4.6 Roles

PRINCE2 uses a Four Layer Management Model (as illustrated in Figure 2-20) which can scale
according to different project environments and sizes. To achieve this, each layer is defined as a set of
roles, each of which can be allocated to one person, shared by several people or combined according to
the specific needs of a project. The different roles and their interrelations are described further in
chapter 2.4.6.

2.5 Agile Project Management and SCRUM

The objective of this chapter is to provide the reader with a high level overview of Scrum as a
representative of modern agile project management and development methodologies.

2.5.1 History
Scrum is original a Rugby-term, describing the position in which a game is restarted after an
infringement [74]. It was first used (in modern context) in the now famous analogy by Hirotaka
Takeuchi and Ikujiro Nonaka. Their article “The New New Product Development Game” compared
management of product development to the game of Rugby [67] and highlighted some traits which are
now very much at the centre of modern agile methodologies.

The Scrum process was then formalized and introduced into software development by Sutherland and
Schwaber [59], culminating in the Scrum Methodology.

2.5.2 Principles

Scrum is built on the same principles that make up the Agile Manifesto [15], namely:

Individuals and interactions over processes and tools

Scrum does not say that processes and tools are not important, but rather that individuals and
interactions are more so. Processes and tools are there to support them, but it’s the right people, talking
to each other, working as a team that makes things happen.

Working software over comprehensive documentation

“Software” here can stand for any product (outcome) from the project. Documentation in a project is
important for several reasons. In a large project or projects that span over a long time, people working
on the project come and go. In order for knowledge to survive and be retrievable later, documentation
is clearly needed. However, the primary objective of the project is to have an acceptable product as
outcome, and this should be prioritized. The best is to find a good balance between getting it done and
writing it down.

Customer collaboration over contract negotiation

A contract is an agreement between you and the customer/client over what (and sometimes how)
something will be done, how much it will cost etc. The contract is typically signed in the beginning,
before all details are clear. Scrum recognizes the problems this causes, and focuses on solving
problems and making the customer happy, rather than fighting over what was initially agreed.

Responding to change over following a plan

Planning is essential to knowing what to do next, but to follow the initial plan blindly when
requirements and needs change makes no sense. In Scrum planning is done in iterations, as more and
more information is known.

17
 2.5.3 Process

Traditional project management methodologies like PRINCE2 are mostly process driven, and
approach process control in a “defined” way, e.g. they try to define the exact input and output for each
process from the start, and hold on to this. The process outcome can be evaluated at times, and if
needed, the process will be re-defined, setting new inputs and outputs.

Scrum instead utilizes empirical process control [66]. Here the process itself is monitored constantly,
and if found lacking is adjusted as soon as possible. The iterative, short time frame approach of Scrum
(e.g. deliver working prototype every x weeks) makes it possible to adjust the process while the
project is on-going, and base these process adjustments on what has actually been done.

Below is a figure depicting the Scrum process (the iteration time is just a suggestion; it can be longer
but preferably shorter than 30 days). Each iteration is called a Sprint.

[43]
Figure 2-11 : The Core Scrum Process

2.5.4 Components

Figure 2-11 above shows the main components of Scrum. The Product Backlog is a list of items
(business requirements, functionality and features) that lives during the project. The priority of the
items is decided by the Product Owner. The Sprint Backlog is the list of items to be implemented in
the current iteration (Sprint). The items are divided up into tasks, and in theory anyone can choose any
of the tasks, providing their skill level is adequate. The Daily Scrum meeting is re-occurring during the
whole Sprint, and is a good process control point. There is also a Sprint Burndown Chart, which can
be a simple diagram and shows how much work remains to be done.

Except for the Daily Scrum, the following Scrum meetings are also an integral part of the Scrum
process: Sprint Planning Meeting, Sprint Review Meeting and Sprint Retrospective.

2.5.5 Roles

In Scrum there are 3 main roles. The Product Owner defines and prioritizes the items for the Product
Backlog and has the power to accept or reject the outcome. Through this, he is responsible for the
business result of the project. The Scrum Master has a team lead role, and is responsible for helping

18
and supporting the team, rather than controlling what they do. Finally, the Team are the people who
make things happen. The team is small, cross functional and self-organizing. There are also other roles
which might have some involvement in the project, but which are not formally part of the Scrum
process. A deeper description of the roles can be found in chapter 2.6.6

19
2.6 Methodology Comparison per Project Management Area

This chapter provides a more in-depth comparison of Traditional and Agile methodologies, in order to
identify the potential pitfalls when migrating from one to another and to provide a basis for
understanding the processes and techniques discussed by practitioners during the interviews in chapter
4.1.

A Guide to the Project Management Body of Knowledge (PMBoK Guide) [50] is a book which
presents a set of standard terminology and guidelines for project management across all types of
projects. While the PMBoK details its own project management processes, it also defines nine main
knowledge areas which are typical of all projects, irrespective of the project management methodology
used. As such, we will use these knowledge areas as a guide for comparing how the PRINCE2 and
SCRUM methodologies approach each of these areas and what the organisational impact of agile
adoption is in the context of these areas.

[50]
Figure 2-12 : The core Project Management Areas as defined by the PMBoK

The 9 Project Management Fields of Practice which comprise project management, as described in the
PMBoK [50] are:
x Integration management
x Scope Management
x Time Management (planning, forecasting and estimation)
x Cost Management (budgeting)
x Quality Management
x Human Resource Management (leadership and people management)
x Communications Management
x Risk Management
x Procurement Management

20
2.6.1 Integration Management

Definition

Integration management is an element of project management that coordinates all aspects of a project.
Project integration, when properly performed, ensures that all processes in a project run smoothly. In
the following sections, we will contrast the PRINCE2 and SCRUM project integration models.

PRINCE2

PRINCE2 is a process-driven method, which contrasts with reactive/adaptive methods such as

SCRUM. It defines eight main processes (illustrated in Figure 2-13), which are further subdivided in
over 40 activities, each of which is characterized by key inputs, role assignments and deliverables.

[25]
Figure 2-13 : The high level PRINCE2 Process Model

Starting up a project
During this initial process, the project team resources are appointed and the Project Brief is prepared,
which outlines the project goals and business justification. The overall approach is determined and the
next phase is planned.

Initiating a project
The Project Brief is elaborated upon to form a complete Business Case. Project controls and quality
requirements are set, potential risks are identified and a project plan is composed, all of which are
included in the Project Initiation Document.

Directing a project
The process represents the controlling aspects executed by the Project Board. Every stage is authorized
by the board and in addition, the board provides ad-hoc direction and will ultimately confirm the
project closure.

Controlling a stage
Projects may be executed iteratively in multiple stages. Each of these stages formally defines the work
package scope and deliverables, the reporting requirements and timelines, as well as the method by
which issues should be escalated.

21
Managing stage boundaries
This process defines what should be performed towards the end of each stage. This includes planning
the next stage upfront and amending the project plan, risk log and business case as required. The
process also determines how to deal with stages that exceed their tolerance levels in terms of timing,
budget or quality.

Managing product delivery

This process controls the links between the Project Manager and the Team Managers and focuses on
formal requirements definition and acceptance, tolerance setting and follow-up, as well as reporting.

Closing a project
At the end of a project, a formal decommissioning is performed, resources are de-allocated, follow-up
actions are defined and the project is formally evaluated in order to detail best practices to incorporate
in future projects.

While each of the individual processes relatively simple, the overall process model including all
activities, inputs, deliverables and interdependencies becomes quite complex, as illustrated in Figure
2-14.

[25]
Figure 2-14 : The complete PRINCE2 Process Model

SCRUM

PmBOK [50] defines the following sections as making up the area of Project Integration Management:

Develop Project Charter

This activity is not really a part of Scrum, rather it is something that must be done in order for the
Scrum project to start. Signing a contract, allocating resources etc. could be seen as prerequisites. The
Scrum roles (Product Owner, Scrum Master and Team) will be defined.

Develop Preliminary Project Scope Statement

22
In Scrum, the Product Backlog represents the preliminary project scope. It will contain all the known
requirements at project start.

Develop Project Management Plan

During the first Sprint Planning Meeting, the items in the Product Backlog will be roughly sorted and
assigned to a target Sprint iteration, and a rough time estimate will be done. Hence, the Product
Backlog can be seen as the overall project plan.

Direct and Manage Project Execution

As the Product Backlog items are prioritized by the customer, it will be the main project steering
document. The Planning meeting at the beginning of each Sprint will serve to refine the task
descriptions for the coming iteration. Each Sprint can be seen as a sub-project, and is the container
within the actual work is performed. The Daily Stand-up meeting serves as a point of control.

Monitor and Control Project Work

Each Sprint has its own Sprint Backlog, which together with the Sprint Burndown Chart (that shows
remaining work to be done within the Sprint) and then Daily Stand-up makes sure that we have
continuous monitoring of how the project is progressing, and problems can be discovered early on.
The Sprint Review and Retrospective meetings serves a feed-back loop for controlling quality of the
project implementation.

Integrated Change Control

Change Control is built into the Scrum process. New requirements/items can at any time be added into
the Product Backlog, and can be dealt with in following Sprints. If a major change needs to an on-
going item within a Sprint are discovered, that item can be lifted out if the current Sprint and put in the
Product Backlog.

Close Project
The last Sprint Review in the Project will be the final point at which the Product Owner can
accept/reject the output of the whole project, and will serve as the formal acceptance. The Sprint
Retrospective will deal with lessons learned and preserve the knowledge from the project so that it can
reused at a later time.

The image below show the overview of the full Scrum process:

[16]
Figure 2-15 : Scrum Process Overview

23
 2.6.2 Scope Management

Definition

The PMBoK [50] defines Project Scope Management as the processes required to ensure that the project
includes all the work required, and only the work required, to complete the project successfully. These
processes include scope planning, scope definition, scope verification, and scope control. Without
proper scope control, “scope creep” may occur, as requirements continue to change in response to
customer business needs, changes in the industry and changes in technology. Traditional and Agile
methodologies have a very different philosophy with regards to managing scope. Plan-driven
approaches work hard to prevent changes in scope, whereas agile approaches expect and embrace
scope change.

PRINCE2

Within traditional project management, the scope is defined upfront and any changes to the initial
scope are considered exceptions, which are dealt with through a formal change management process.
PRINCE2 performs scope definition as part of the Product-based Planning technique, which is
described further in Chapter 2.6.3. This includes creating a Product Breakdown structure, which
decomposes work packages into smaller, more manageable products. This results in a hierarchy of all
the planned products to be produced, wherein each product is sufficiently documented using a written
narrative and all interrelations and dependencies between products are modelled using a Product Flow
Diagram. The time needed to accomplish tasks is estimated and scheduled and any potential risk is
assessed and documented as well.

[50]
Figure 2-16 : The Traditional Project Management Lifecycle, with upfront scope planning

PRINCE2 offers change control process and technique to capture and analyse change requests and a
series of processes to obtain decisions on changes and manage their implementation. These include the
creation of an Exception Report (as defined in an Exception Plan) and letting the Project Board decide
on whether or not to proceed with a change.

SCRUM

In contrast to traditional project management, Agile methods embrace scope changes as they consider
them unavoidable. In contrast to traditional projects, resources and time are typically fixed in agile
approaches, and it’s the scope that is allowed to change. One of the key success criteria in traditional

24
projects is the extent to which the initially defined scope is followed (i.e. the least amount of scope
creep is introduced). In Agile however, it is more important to be able to efficiently and effectively
respond to change. The success criterion in Agile thus rather reflects the amount of business value
provided to the customer.

In SCRUM, the iterative and incremental process itself is what manages scope. Except for auditing
purposes, no additional document outlining procedures for scope management is needed. Scope is
managed by use of the Backlog, but it can be redefined constantly, as part of the release planning and
iteration planning meetings and by the management of the product backlog.

Figure 2-17 : The Agile Project Management Lifecycle, with iterative scope planning

SCRUM fully incorporates the concept of Rolling Wave Planning and Progressive Elaboration, which
utilize a process of planning for a project in waves as the project becomes clearer and unfolds. The
products for the initial sprint(s) are documented in more detail, whereas the longer term deliverables
are only described on a higher level and planned through key milestones for the project. Because the
short timeframe of an iteration, this reduces the amount of detail and the complexity of estimating.

2.6.3 Time Management

Definition

Time management deals with the ability to plan, execute and finish the project in a timely manner. It
incorporates project management processes which deal with defining tasks, tasks durations, scheduling
tasks and ensuring adherence to the schedule. Time management is a crucial part of any successful
project.

PRINCE2

Product based planning is a fundamental part of the PRINCE2 approach to project management. It is a
method for identifying all of the tasks that make up or contribute to delivering the objectives of the
project, and the associated work required to deliver them [25].

Initially, a product breakdown structure is created upfront, usually for the entire project. The objective
of the breakdown is to ensure all necessary products are identified and captured. The breakdown is
iteratively refined until all of the requisite products are present and of sufficient granularity to be

25
described in detail. This results in a hierarchy of products and sub-products that comprise the final
end-product. These products include more than the actual end user deliverables, but also comprise all
intermediary documents required to come to the end result. These include for example the functional
analysis, test scenarios, etc.

[25]
Figure 2-18 : An example Product Breakdown Structure

Once all deliverables are identified, they are prioritized. This is achieved by creating a product flow
diagram which determines the order of precedence of products. Typically, it includes multiple and
complex parallel paths. It is comparable to PERT (Project Estimation and Review Technique) charts
used for critical path analysis in other traditional project management methodologies.

Once the sequence of tasks is determined, all task effort is estimated and resources are assigned.
Usually a top-down effort estimation is used initially, in which management and a few key individuals
provide high level estimates for top level tasks. These are later reconciled with bottom-up estimates as
provided for the detailed tasks by the team members. After resource levelling and setting control
points (usually at stage boundaries), this results in the final planning. This plan serves as a baseline
and for each of the stages within the project timeline, project time tolerances are set. When task
durations exceed these tolerances, the project board will decide on how to progress. This may for
instance result in additional resources being assigned or scope to be cut. In any event, the planning is
revised to accommodate any changes resulting from decisions made through Exception Management.

SCRUM

In Scrum, as opposed to PRINCE2, it is not necessary to have a full list of all requirements at the
beginning of a project. The Product Backlog is the container for requirements and may contain rough
time estimate of the tasks. However, since the Product Backlog remains dynamically updateable
during the course of the project, time management within Scrum does not attempt to estimate the
project as a whole through individual tasks, but rather have strict control of the tasks, as they come up.

26
 Figure 2-19 : An example of a Product Backlog

During the Sprint Planning meeting at the beginning of each Sprint the top prioritized items are
selected, and moved to the Sprint Backlog. In this process they are refined, clarified and given a more
fine-grained time estimate. A tool to see the remaining work that needs to be done during a Sprint is
the Sprint Burndown Chart, which can be a simple graph, showing how many work hours are left in
total for the current sprint.

The approach to time management differs in another important aspect as well: a Sprint will always end
on time, and any meetings and activities are very strictly time-boxed. The purpose of this is to have a
continuous flow in the process and to get the work done, so that the team is not stalled by
overanalysing requirements, details and issues Items that for different reasons could not be completed
will be return to the Product Backlog to be revisited in the next Sprint.

2.6.4 Cost and Procurement Management

Definition

Project Cost Management includes the processes involved in estimating, budgeting, and controlling
costs so that the project can be completed within the approved budget. Procurement management is
closely related and represents the process organisations use to purchase economic resources and
business input from suppliers or vendors. This process helps organisations negotiate prices and get the
best quality resources.

PRINCE2

PRINCE2 provides few details on actual cost management and virtually none on procurement
management. The project budget is mostly interpreted as a man-days budget which can be spent on
task effort and thus follows the planning, scheduling and change control processes described earlier.
PRINCE2 does mandate the setting of tolerance levels of cost aspects of a project, in order to handle
any deviations through exception management. In contrast to the PMBoK, PRINCE2 does not
elaborate further on the management of a financial budget, procurement techniques or specific cost
management techniques such as Earned Value Management (EVM), Programme Analysis and Review
Technique (PERT) and Reserve Analysis and Cost of Quality (COQ) analysis. While PRINCE2 does
not mandate any of these tools or techniques, it can easily work together with them and this is often
the case when implementing PRINCE2 in practice.

SCRUM

Scrum does not claim to be a full-fledged project management methodology. Cost and Procurement
Management is one of the areas which are not covered by the formal Scrum methodology.

27
 2.6.5 Quality Management

Definition

Project quality management is the discipline that is applied to help ensure that both the outputs of the
project and the processes by which the outputs are delivered meet the requirements of all stakeholders.
It generally consists of three main components: quality control, quality assurance and quality
improvement.

PRINCE2

Quality Management is about checking the quality of work done on the project, either by testing it or
reviewing the work in some way. PRINCE2 defines a processes and techniques technique for
controlling the way changes impact the project in order to prevent the project going off in the wrong
direction. At the project initiation phase, a Project Quality Plan is constructed, which defines how the
supplier intends to deliver products that meet the customer's quality expectations and the supplier's
quality standards. The plan describes the customer quality expectations, the organisational or
programme quality management system and standards as well as the quality-control and audit
processes. Furthermore, when creating the product breakdown structure, every product is annotated
with specific quality requirements and acceptance criteria which are checked on product delivery
before final acceptance. PRINCE2 also defines the quality review technique. This technique ensures a
project's products are of the required standard and meet the defined quality criteria. On delivery of a
product, the product quality is discussed in a quality review meeting, which identifies any errors in the
product. The meeting joins people who have an interest in the project's outputs and people on the
project team able to address issues identified. The quality review meeting will not attempt to solve the
problems it identifies, but rather determine the impact on the project planning and the next steps to
take. The dates these quality management activities take place are planned in upfront in a Quality
Register.

In terms of roles, corporate management will provide the details on the organisational quality
management system and the project board will approve the quality management strategy and product
descriptions. The Senior User role acts as a liaison towards the customer in order to formulate
customer quality expectations and acceptance criteria as well as approving product descriptions. The
Senior Supplier role reviews the same items but from the supplier perspective. The project manager
formalizes all of the above and ensures that team managers implement the quality control measures
agreed. Team manager ensure that the products are created in line with their descriptions, and keep the
project manager regularly informed on product quality status. Project Assurance assists and advises
the project manager on the implementation of all quality matters. Finally, Project Support will provide
administrative support for the quality controls and quality records.

SCRUM

Quality management is not formally part of Scrum, but is very easy to incorporate, depending on the
standard quality approach in the project organisation. In Scrum, quality planning will typically be
performed both at the start of the project and in each Sprint.

Quality Control from a project management perspective is the process by which the output of the
project is evaluated and measured to verify that it meets the quality expectations, but focus is also on
finding issues in the implementation that need to be fixed.
Quality Assurance can be said to be part of the agile approach. The Product Owner’s presence and
participation in the project fulfils the need of the customer having confidence in the quality of the
process. As the Team is cross functional, testing and Quality Assurance (QA) skills will be present
during the full process cycle. Also, at the end of each Sprint the Product Owner has the power to

28
accept or reject the output, which raises the stakeholders’ confidence in the quality throughout the
whole project.

The iterative nature of Scrum, where knowledge and improvements are continuously fed back into the
development loop aids in the aspect of Quality Improvement. Faulty test cases and testing methods, as
well as development can be fixed on the fly, and the daily Scrum meetings provide a good forum for
introducing improvements in the on-going work.

2.6.6 Human Resource Management

Definition

Human Resource Management includes the processes that organize, manage, and lead the project
team. It helps ensure that the proper people are working on a project, that everyone is working
efficiently and the right people have been scheduled for the tasks they are best adapted for.

PRINCE2

PRINCE2 defines a Four Layer Management Model (as illustrated in Figure 2-20) which can scale
according to different project environments and sizes. To achieve this, each layer is defined as a set of
roles, each of which can be allocated to one person, shared by several people or combined according to
the specific needs of a project.

[25]
Figure 2-20 : The PRINCE2 Four Layer Management Model

Project Board
The Project Board is appointed by Corporate or Programme Management to provide overall direction
and management of the project and is ultimately accountable for the success or failure of the project.

Project Board
The Project Board consists of the Project Executive, the Senior User and the Senior Supplier roles,
representing respectively the interests of the Business, the end Users and the Suppliers/Developers.
The Executive is responsible for the project as a whole and must ensure the return-on-investment
provided by the project, while balancing the demands of the Business, Users and Suppliers. The Senior
User manages the specification of the final product to be delivered by the project. This role acts as a
proxy representative for the end users and will monitor the project to ensure the end product meets the
objectives set in the Business Case, in terms of quality. This Senior Supplier protects the interests of
the parties implementing the project products and has the authority to acquire and commit resources as
required.

Project Manager

29
The Project Manager runs the project on a day-to-day basis, on behalf of the Project Board. The
Project Manager is responsible for ensuring that the project deliverables meet the required and
predetermined standards of quality within the given cost and time constraints.

Team managers
This role is only applicable in larger scale projects, where team members are divided in sub-teams of
specialists, each of which is headed by a Team manager. The team manager in turn takes direction
from the Project Manager.

Project Assurance
Assurance provides independent monitoring of all the project aspects and covers the interests of all
above mentioned parties. It is the responsibility of Project Assurance to identify, report and escalate
any potential issues as soon as (or preferable before they) arise.

SCRUM

At a first glance, the Scrum human resource management seems very simple. As mentioned in chapter
2.2.5, there are only 3 core roles, Product Owner, Scrum Master and the Team members.

Product Owner
The Product owner is the person that is finally responsible for the outcome of the project, and it is his
task to ensure that the ROI is positive. As a representative of the customer, the Product Owner will
(help) generate/define requirements for the project, prioritize between the requirements as well as add,
remove and change the scope of requirements as demanded by market, the time plan and the budget
for the whole project. The Product Owner is also involved in quality control, as he has the power to
accept or reject the outcome of tasks. It is not recommended that the Product Owner and the Scrum
master is the same person.

Scrum Master
The Scrum Master is basically a team lead for the Team. Rather than being a manager, the Scrum
Master helps and supports the Team by helping them resolve issues, both internally and externally.
This involves making sure the team have the resources they need to perform their work and that the
communication within the team is working. The Scrum Master is also responsible for the making sure
the Scrum process is followed, e.g. setting up the Sprint meetings (daily scrums, reviews, planning
meetings).

The Team
The Team is the group of people who actually implement the project. The team should be cross-
functional (including people with different skill sets and expertise) to be able to cover all aspects of
the project. The team should not be too large (this may cause issues such as long meetings, need of
coordination and management) or too small (the team need to be able to perform all the tasks, and
have enough time to do it). As the team is to be self-organizing and empowered to take decisions
within the project boundaries, the requirements on team members are high.

Except for these core roles, there are also other people who will come into contact with the Scrum
project and team. Stakeholders such as end customers and vendors, different kind of managers in line
organisations, project managers, support people etc. can at times give some input or contribute to a
smaller degree and must be taken into account, but they are not formally part of the Scrum process.

2.6.7 Communications Management

Definition

30
Communications management consists of processes to identify communications requirements,
technologies, constraints and assumptions. Communication planning involves identifying and meeting
the information needs of the project stakeholders. Specifically, identifying which people need what
information, when the information is needed, how to structure information flows and how the
information is collected and communicated.

PRINCE2

At the initiation of a PRINCE2 project, a Communication Plan is documented as part of the Project
Initiation Document. This documents how information will be disseminated to, and received from, all
stakeholders in the project (see examples in Figure 2-21). It identifies the means and frequency of
communication between the stakeholders and is used to establish and manage on-going
communications throughout a project. Specifically, it includes [25]:

x Identification of stakeholders their information requirements

x Time frame or period the stakeholder needs the information
x Description of when and how information is collected and who collects it
x Document distribution methods and frequency of distribution
x Handling procedures for temporary storage and final disposition of project documents
x Regular status reports, scheduled project team meetings, updates with the steering
committee,...

[25]
Figure 2-21 : Possible project stakeholders

SCRUM

In Scrum, there is no formal communication planning. Stakeholders can (passively) attend the Scrum
meetings, and the Burndown Chart and Backlog documents are open for all to view and show the
status of the project. The Product Owner is the assigned point of contact towards external
stakeholders, and internal communication is facilitated by small teams working in the same geographic
locations as well as on the Daily Stand-up meetings.

31
 2.6.8 Risk Management
Definition

A risk is something that may happen during a project lifecycle and if it does, will have a positive or
negative impact on the project. Each project is expected to take on some level of risk if it is to achieve
its objectives. Risk management then, is the identification, evaluation and prioritization of these risks,
followed by a coordinated application of resources to minimize, monitor, and control the probability
and impact of negative risks or to maximize the realization of positive risks (’opportunities’).

PRINCE2

PRINCE2 describes certain mechanisms of risk management in order to effectively manage a project’s
exposure to risk; by taking action to keep exposure within an acceptable level and in a cost-effective
way. At project initiation, the project board and project manager define the level of risk that they are
willing to take on for various component of the project. The tolerance levels may be different for
different parts of the project. They also agree on the associated time and cost contingencies associated
with any mitigating actions to take in case of risk realization. The project board is responsible for
ensuring that all risks are managed whereas the project manager has the responsibility to identify, log
and regularly review the risk. Risks are recorded and updated in the Risk Log. Risk management
policies are properly documented and their importance clearly communicated to the staff.

[25]
Figure 2-22 : The PRINCE2 Risk Management Cycle

The PRINCE2 risk management cycle is illustrated in Figure 2-22 and is further elaborated in the
PRINCE2 Guide[25].

SCRUM

Risk management is another area which is not formally covered by the Scrum methodology. Projects
are free to handle risks according to best practices of whatever industry the project belongs to.
According to Ken Schwaber, one of the founders of Scrum:

“Scrum purposefully has many gaps, holes, and bare spots where you are required to use best practices
– such as risk management. Scrum then shows you how well that approach works through
transparency, so you can continually optimize the approach.”[2]

32
There are many ways risk management can be incorporated in Scrum. The Product Owner being
present throughout the project cycles and the iterative approach of evaluating requirements and
priority effectively deals with the risks of unclear requirements and lack of customer communication.
Secondly, other standard risk management approaches can easily be integrated with Scrum. Risk
identification and evaluation can be part of the regular meetings (both at beginning of project and for
each Sprint), risk monitoring can be dealt with at the daily scrums and followed up at the Review
meeting. Handling the risks will be done by the Team within the normal Sprints.

33
3 Method
The purpose of this chapter is to describe the research methodology considered for and used in writing
this thesis. It starts out by describing the initial research that was performed, then goes on to describe
relevant research methods, which of the methods were selected and why. There is a sub-section
describing how we arrived at relevant research questions through the use of an organisational change
model, a sub-section on how the interviews were planned, composed and performed, and finally a
discussion on the reliability and validity of the results.

3.1 Prestudy and approach

The first source of information was reviewing relevant literature which let the authors of this thesis
gain further insight into the strengths and weaknesses of both traditional and agile methodologies, the
contexts in which they are most successfully applied, as well as to get an overview of and
understanding for the problems and issues usually encountered when trying to introduce agile
methodologies into an organisation employing traditional methodologies.

Literature streams that were used consisted of both the reference literature provided by the respective
founding organisations, papers on the alignment/hybridization of multiple methodologies, as well as
concrete case studies relating to the effects of introducing agile methodologies into traditional
organisations. All this information can be said to constitute the secondary data sources for our thesis,
and helped us pinpoint relevant problem areas related to the organisational transformation that takes
place when introducing agile project management methodologies.

The information gathered was then used to formulate questions for a number of interviews, which
have served to collect more qualitative data from experts (project managers) that have been part of an
organisational transformation where agile methods were introduced. In parallel, an analysis of
documented cases has been carried out. These data were the primary data sources for the thesis. Once
all the data were collected, analysed and compared against the problems and pitfalls, an attempt was
made to formulate best practices for introducing agile methods into traditional organisations. The end
result constitutes the main output of this thesis: the conclusions and suggestions for further research.

3.2 Quantitative methods

Quantitative research methods deal with data that can be quantified (analysed through numerical
and/or statistical processes) [56]. Data can for instance be collected through questionnaires,
measurements, gathering data through secondary data sources and archival data etc. In general, it is
easier to measure and judge the validity of the end result when quantitative methods are used, although
this is largely dependent on populations and sample sizes.

3.3 Qualitative methods

Qualitative research methods focuses of getting an in-depth understanding of the object/phenomena
being studied, the “how” and “why”.

3.3.1 Case studies

Just as the name implies, a Case Study focuses on studying a certain “case”, which might be a project,
a certain situation or even a person. According to Garson [22], a case study “may be particularly helpful
in generating hypotheses and theories in developing fields of inquiry”. Yin, in his book Case Study

34
Research, elaborates on the lack of a good definition of the case study as a research methodology, and
proceeds to formulate a technical definition of the term[76]:
“1. A case study is an empirical inquiry that
x investigates a contemporary phenomenon within its real-life context, especially when
x the boundaries between phenomenon and context are not clearly evident.
2. The case study inquiry
x copes with the technically distinctive situation in which there will be many more variables of
interest than data points, and as one result
x relies on multiple sources of evidence, with data needing to converge in a triangulation
fashion, and as another result
x benefits from the prior development of theoretical propositions to guide data collection and
analysis.“

Tellis [68] lists 6 sources of information in case studies:

x Documents
x Archival records
x Interviews
x Direct observation
x Participant-observation
x Physical artefacts

Yin explains that it is possible to study a single case (for instance when we want to study a critical
case in depth) or several cases, and to use a holistic approach or an embedded approach where several
units of analysis are studied. [76].

As with most qualitative methods, the main drawback of the case study is the difficulty of using the
findings in a broader scope, e.g. generalizing from them, as validity of the findings is restricted to
similar cases. Other criticisms are difficulties of performing the case study in a rigidly scientific way,
and that they produce unstructured data.

3.4 Mixed methods

It is possible to use multiple research methods and combine the results. For instance, to use several
quantitative methods to improve the validity of the result, or to combine a quantitative method with a
qualitative one (to gain more in-depth insight into some area).

Saunders [56] describes the paths we can take while designing our methods as following:

Research choices

Mono method Multiple methods

Multi-method Mixed-methods

Multi-method Multi-method Mixed-method Mixed-model

quantitive qualitative research research
studies studies

[56]
Figure 3-1 - Research choices according to Saunders

35
3.5 Research methodology selection

Saunders [56] mentions two main approaches to research, the deductive approach and the inductive
approach. The deductive approach focuses on testing theory, e.g. we have or arrive at a theory, that
needs to be formulated in such a way so that it can be tested (measured, evaluated, verified). The
inductive approach instead focuses on building theory to explain (understand, define) a problem,
analysing the data and formulating a theory.

From the nature of the problem statement in this thesis (focus on “how”), as well as the questions of
interest to the authors, it was decided early that we would use the inductive approach and focus on
qualitative research methods.

As the questions of where and when to apply the different project management approaches are open,
and it is difficult to find large amounts of projects where only a few variables differ, a quantitative
method approach would not be very successful.

Since during our pre-study, we already performed an extensive literature review and in addition we
already had some practical experience with traditional and agile project management methods,
Grounded Theory (one of the qualitative methods that were considered from the beginning) was
deemed unsuitable for our cause, as Grounded Theory assumes a completely unbiased approach
without any pre-research literature review or conversations about the theory.

A combination of case study and a qualitative Survey Study was initially chosen as the research
method. After reviewing the drawback of surveys (low response rates, reaching target groups,
answering biases, etc.) it was decided to perform a number of interviews instead, as we are targeting a
small group of people with a specific set of knowledge/experience. According to Saunders, our target
group (managers) are also more likely to agree to be interviewed rather than to answer a questionnaire
[56]
. The strategy chosen to prepare and execute these interviews is described in chapter 3.6. The
interviews were performed through on-line chat and on-line open-ended questionnaires.

3.6 Interview strategy

3.6.1 Target audience

The target sample group (audience) for our interviews were primarily managers within organisations
that have introduced or are in the process of introducing agile project management methods. They are
best suited to be able to answer the questions within the 6 areas identified in the Burke-Litwin model
as being the most relevant to us. Team-members of agile teams were also a good secondary input-
stream, as they had further insights, specifically in the fields of Work unit climate and Individual
performance, but also gave different viewpoints on the other areas.

3.6.2 Strategy

The strategy to reach these target groups was the following:

We used LinkedIn as the base to reach both our personal networks and identify potential candidates,
and we used the LinkedIn Groups to reach further individuals who matched our target profiles. A
benefit of using LinkedIn for this kind of research is that it’s less “anonymous” on the researchers’
part, e.g. the person being interviewed can also get some insight in who the researchers are and might
feel more inclined in participating. Additionally, it gave us an easy means of verifying the past
experience of the interviewees. The complete list of LinkedIn groups we targeted for contacting

36
interview candidates is listed in Appendix 8.2. A concern with this approach was that it would not
generate enough answers, e.g. that we would not be able to find enough people to interview.
Depending on how extensive the answers would be we set the aim at conduction 5-10 interviews of
good quality.

As a backup to the interview approach, we also created a web-questionnaire with the same set of
questions that were the base of the interview. The reasoning behind this was to give individuals who
were not inclined to being subject to an interview another venue into participating in our research.
Reasons for not wanting to be interviewed might be time-constraints, feeling uncomfortable or other
reasons, and thus the possibility of answering the questions in a questionnaire format (which can be
done at any time, and probably takes less time) gives a good chance of increasing our answering rate.

As mentioned in chapter 3.5, the drawback with surveys is often low response rates, incomplete
surveys, and where questions are open ended data tends to be of low quality. Since the survey was
considered a backup these drawbacks were considered acceptable.

3.6.3 Interview Composition

In order to facilitate the analysis of the gathered data, we have categorized the questions according to
the model derived in chapter 2.2. For each dimension in this model, we basically wanted to solicit
information on the main challenges interviewees experienced in that organisational dimension, as well
as on (un)successful approaches taken to overcome these challenges. Therefore, our questions
consisted of the following parts:
x an introduction in which we explain the motivation for the interview, provide
instructions/guidelines and detail additional considerations.
x a context section, containing some general pre-screening questions to establish some basic
context on the nature of the participant’s organisation, experience and role.
x the main questions section, containing an average of two questions per organisational
dimension. For each dimension, we provide some short (single line) context, based on the
differences between traditional and agile project management, as researched in chapter 2.

Each of the individual questions is open-ended and formulated in such a way as to encourage the
interviewee to provide detailed information about either specific challenge encountered and/or related
practices applied in the different organisational dimensions. The main questions are listed below and
the complete set of questions as represented to the interviewees is listed in Appendix 8.1.

Dimension of Context Research questions Interview questions

Model and observations in
literature
Organisational Agile methods proclaim x What is the relationship • Was agile adoption initiated
Culture different core values and between organisational from a strategic vision
principles than traditional culture and the post- perspective (top management or
methods (e.g. emphasis on adoption deployment of business) or was it introduced
innovation, team-work, agile methods? [29] bottom up?
customer satisfaction,…). x What does the Agile • What are your organisation’s
professional culture main drivers for introducing
entail? [61] agile practices?
• What were the main
difficulties at (e.g. resistance to
agile ideas or changes required
in cross-departmental
processes, customer

37
 interaction,…) and what was
undertaken to overcome these
difficulties?
Leadership Agile project management x Does the style of • How did management and
is often accompanied by a leadership influence the team members deal with
shift in leadership style successful and changes and what was
from command and sustainable undertaken to guide this change
control to increased team implementation of in leadership style?
autonomy and Agile/Lean methods? • Which new competencies did
[21]
accountability. management have to adopt to
x Does the role of accommodate these changes?
leadership change
during the initiation and
implementation phase?
[21]

Structure Agile teams are often x How do you merge • What kind of restructuring
composed differently from agile, Lightweight was performed in your
traditional project teams processes with standard organisation and how were
and have an increased industrial processes these changes received?
focus on self-organisation, without killing agility? • What kind of training was
[9]
autonomy, communication . required to overcome the
and collaboration. x Agile team members learning curve?
often cross the
boundaries between
standard position
descriptions and might
require significantly
more skills and
experience to
adequately perform [9].
Management Agile project management x How do agile • What were the main changes
Practices involves closer management approaches in management practices
collaboration with differ from traditional introduced at your organisation
stakeholders and deals ones? [20] and what were the observed
differently with project results (both positive and
management aspects such negative)?
as scope, risk and quality
management.
Work Unit Agile methods emphasize x How do agile methods • How did the introduction of
Climate teamwork, drive and affect flexibility, agile teams affect the
motivation. employee satisfaction motivation/job satisfaction,
and commitment, user expectations, and
satisfaction and user interrelationships of team
involvement? [61] members?
• How was team work
facilitated or hindered?
Individual and Agile methods proclaim to x Agile methods and their • Has agile adoption at your
Organisational increase both efficiency attention to prioritizing organisation resulted in any
Performance and quality. requirements and measurable increase or decrease
responding to changes in performance and/or quality at
in stakeholder value either an organisational or
propositions are pushing individual level?
us in more high-payoff • What kind of notable changes
directions [10]. have been observed in customer
satisfaction and/or interactions?
Table 3: Interview questions

38
 3.6.1 Data analysis approach

All of the gathered data – irrespective of the channel through which it was gathered - was transcribed
and structured in the same format. As each of the questions was already implicitly mapped to one of
the organisational dimensions of our analysis model, this allowed us to directly evaluate every
individual response in the right context and determine whether relevant information on challenges or
best practices could be derived for that dimension. The data was compared to the information learned
through our literature review, as well as conclusions drawn from evaluated case studies. Where data
from multiple sources re-enforced each other, it was included in our final model. Contradictory results
were explored further in an attempt to explain their cause.

3.7 Reliability

Except for the drawbacks mentioned for quantitative methods in general in chapter 3.3, there are a few
other points regarding reliability of the thesis results that is important to discuss. Saunders [56]
mentions three issues that can be identified for the type of interview we perform:
x Reliability
x Forms of bias
x Validity and generalizability

3.7.1 Reliability

The results (answers) to qualitative questions asked during an interview are not necessarily repeatable
(e.g. even the same question asked to the same individual at a different point in time might render a
different answer, due to experience, changed circumstances, etc.) They represent the
opinions/knowledge of the interviewee at the time they were asked. Hence it is important that the
questions themselves are well constructed, and that it is clear exactly for what purpose each question is
being asked.

The clarity of interview questions was verified by testing them on a few people before the main run.
This was to get feedback on the formulation and that nothing was unclear. During an actually
interview such issues can be resolved on the fly, but for the answers generated through the online
survey, it is very important that there are no doubts as to what the questions mean.

Another reliability concern is the quality of answers gathered through the LinkedIn / online interview
approach. As mentioned in chapter 3.6.2, the LinkedIn approach gives us the possibility to verify the
backgrounds and experiences of the interviewed individuals. Compared to the web-survey approach
this gives us a much better assurance of the quality of answers. However, as with all situations where
you can not physically verify the identity of a person, we cannot be sure that the answers are not
provided by a “made up” identity.

3.7.2 Forms of bias

Saunders [56] discusses several factors that can affect the bias of the interviewee. These include the
level of knowledge of the researcher, what information is provided to the interviewee, the location
where the interview takes place, the nature of the questions, cultural differences etc.

As the interviews were performed on-line, some of the influences are either not applicable or not under
the researchers control. These include interviewee’s perception of the researchers (appearance, body
language etc.), location (where the interview took place).

39
In order to avoid slanting the answers in any specific direction, an effort has been made to make the
questions neutral, e.g. not indicating that the transition to agile project management should lead in any
specific direction. This is done through consistently asking open questions.

3.7.3 Validity and generalizability

This is discussed in the Validity section, where we talk about further limitations as to the applicability
of the result.

3.8 Validity
[76]
Validity concerns the adaption and translation of theory into the reality. Yin developed three types
of validity: construct validity, internal validity and external validity.

3.8.1 Construct validity

To meet construct validity, Yin [76] indicates the importance of selecting the specific types of changes
that are to be studied and relating them back to the original objectives of the study. For this thesis this
has been done by associating questions to each of the dimensions of our research model (chapter
3.6.3). Additionally, Yin [76] states, possible case study tactics are to use multiple sources of evidence,
establish a chain of evidence and have key informants review draft case study reports. For our thesis,
we use open-ended interviews and case studies documented in academic papers as sources of
evidence.

3.8.1 Internal validity

Internal validity concerns the matching and congruence of the findings to reality. Merriam [41]
describes several approaches for ensuring internal validity. One such approach is triangulation, in
which multiple sources of data or used. For this thesis we have checked for parallels and
inconsistencies between data gathered from interviews of people with different roles/perspectives on
the subject matter (external consultants, internal project managers, team members), observations and
case study documents. Another common strategy for internal validity are member checks. We have
made our draft analysis data available to interviewees in order to gather feedback. In addition peer
examination was applied, in which other master thesis students have provided their feedback on this
thesis in two draft stages. A table of the participating interviewees’ profiles can be found in chapter
4.1.1.

3.8.2 External validity

External validity concerns the extent to which the findings of a particular case study can be
generalized or replicated to apply to other situations. The higher the external validity, the higher the
level of generalisation (Yin [76]). Merriam [41] describes two strategies for increasing external validity.
These include providing sufficient detail in order to allow the readers to decide whether the situation is
applicable to their case. We have attempted to provide a detailed description of the context of each of
the different case studies (chapter 4.2.2 and 4.2.3) and interviewee profiles (chapter 4.1.2) in order to
provide our readers with sufficient background.

40
4 Data Collection and Findings
In this chapter we provide an overview of the data gathered through interviews and case studies. The
findings will be analysed further in the next chapter.

4.1 Interviews

This section examines the data gathered through the semi-structured interviews, as described in
chapter 3.6.

4.1.1 Brief profile of participants

A total of 15 people were interviewed online, over means such as Skype and mail. However due to the
on-line nature, not all participants completed the full interview. Therefore, we disregarded any
participators which did not answer the core questions. After applying this filter, 9 relevant interviews
remain. The table below provides a summary profile of the interviewee, his or her position, company
and type of project.

Interviewee Role Company Size Sector Country

Interviewee A Software Inworx 101-1000 Information Technology Argentina
Factory
Manager
Interviewee B Software Hayes Management 1-100 Healthcare consulting USA
Development Consulting
Interviewee C Quality Aricent 1000+ Communication India
Assurance Services
Interviewee D Executive Falling Blossoms 1-100 Agile Adoption UK
Consultancy
Interviewee E Consultant PLO Consulting 1-100 IT Consulting France
Interviewee F Project manager The Tertiary 101-1000 Government New Zealand
Education
Commission
Interviewee G Project manager Nokia 1000+ Telecom India
Interviewee H Project manager Christelijke 1000+ Healthcare Belgium
Mutualiteit
Interviewee I Team leader/ SEB 1000+ Banking Sweden
Scrum Master
Table 4: Interviewee profiles

The roles of the interviewees display a significant diversity. A number of interviewees are experienced
project managers, but some also have roles at different levels (e.g. a software development team
member, an executive). There is also a good mix of people facing agile adoption in their own
organisation and people who provide external consultancy in other organisations which are in the
process of adopting agile practices. These factors lead us to believe that the different perceptions and
experiences of the interviewees may provide different viewpoints on the subject matter, while all are
very relevant and valid for our research.

In terms of organisations, there is quite some variety in company sizes and sectors. In addition, people
have participated from all over the world, which helps boost the general character and therefore the
external validity of the gathered data.

41
 4.1.2 Information acquired during interviews

This section provides a summary overview of the data gathered in the interviews. Since all questions
were optional, some interviewees have provided more input than others, but all have shed light on at
least a number of the dimensions of our research model. Below, we have summarized the data per
interviewee. In the analysis section, we have aggregated and restructured the relevant data per research
domain in order to draw our conclusions.

Interviewee A

Interviewee A works as a Software Factory Manager at an IT Solutions company in Argentina which

mainly targets the insurance sector. They have been using a traditional waterfall based methodology
up to approximately three years ago, after which an Agile SCRUM methodology was introduced.
Typical projects range from two to three months and 2 to 3 team members up to projects of one to two
years with a 12 to 15 people sized team.

The agile adoption was initiated by the middle management. The main drivers of the organisation for
introducing agile practices according to Interviewee A were “to raise customer satisfaction, avoid the
risk of non-delivery of what the customer expects (i.e. hidden requirements or expectations) and better
information on what is going on in a project”.

The main difficulties while introducing agile practices were “changing the mental model, resistance to
collaborate across functional silos, a lack of involvement, difficulty to find a good Product Owner
(either a customer or internally), customers are used to expecting fixed price projects, etc.”.

Interviewee A also indicates that management facilitated the necessity of changes in leadership style
and autonomy through coaching the team when difficulties arose. In terms of competencies which
management had to master to accommodate the necessary changes, Interviewee A states that
“changing the ‘command and control’ mental model is, even now, the hardest challenge”.

Regarding the change in team member responsibilities, Interviewee A stated: “the team has to take
responsibility for the project outcome instead of the project manager as in the traditional approach”.

When questioned about the training required to overcome the learning curve, Interviewee A answered:
“We follow mainly SCRUM and the rules, artefacts, and ceremonies are quite easy to understand. The
main problem is to buy-in to the spirit. No training is possible for that issue; it's a matter of detecting
deviations and coaching the team; an endless duty of Scrum Master role”.

Interviewee B

Interviewee B works as a Development Project Manager at a US based consultancy firm, consisting of

approximately 100 people and focused on the healthcare sector. The development division consists of
approximately 15 people and develops, markets, installs and supports healthcare applications. Agile
methods were introduced two years ago by Interviewee B herself. She illustrates the situation before
Agile was adopted: ”we are a very small development group, therefore the prior development
processes were relatively ad hoc and informal. Written requirements and design docs were of varying
degrees of specificity. Engineers participated at a high level in making many design decisions due to
lack of a focused analyst. One product was developed by a solo engineer (very high level, very good at
business analysis as well as engineering).”. The main reasons for going ahead with agile adoption
were ”Shorten time to market, more visible progress and accountability to published dates.” Some
basic team restructuring was required to construct an agile team: ”We had a small team (4-5 people)
who were mostly segregated onto this team to build a new product. In reality several people had other
responsibilities that we were mostly able to offload over about a 9 month timeframe.”.

42
In response to how management dealt with the changes, Interviewee B responded: ”Management
loved it, they got monthly presentations of progress to date, demo’s, release burn-downs so they can
visualize progress, impediments and achievements, etc.” The engineers however were less
enthusiastic however and had many frustrations concerning the lack of upfront detailed specifications.
Interviewee B elaborates: ”I (Scrum Master) had to work with disgruntled engineers, keep them
focused on our goals, get them out of 'is it written down' to 'let's solve the problem for the customer'
and 'focus on high priority development items'”

Interviewee B summarized the main difficulties which arose as follows: ”The engineers were resistant,
they were uncomfortable when everything was not written down specifically upfront. I think this was
specific to the engineers on this project who were very used to waterfall processes at their last job” As
a second difficulty, she added: ”development of infrastructure can be sub-optimized because it gets
chunked into monthly increments, rather than taking enough time to architect the whole large vision”.

With regards to motivation and job satisfaction, the agile adoption process knew a difficult start,
however some improvements have been noticed over the past two years. Interviewee B elaborates:
”One engineer resigned. Team relations were very difficult for quite a long time (in 25 years in the
software industry I have never worked in a more difficult team environment). Note that my prior
experience had been with Agile teams which worked very well together. Over 2+ years, I've seen some
real growth in the cross-functional skill sets of the team, and the project estimation and initiation
process has become much more seamless.” When asked which measures were taken to facilitate team
work in the new organisation, Interviewee B states ”Not much. We need to do more with this.” In
terms of general training, she adds: ”Very little, we are a small company and did not want to spend
significantly on training. I attend a 'scrum master' training session, I think it was about 4 days long. I
have done Agile at a prior job, and received some extensive training there many years ago (it was a
large software development firm).”

Interviewee B speaks positively of the changes in management practices: ”Scope management was
greatly improved in my opinion. It was important to management to get a product out in about a year,
we managed scope each month to achieve that result. We were able to hire our first dedicated QA
resource as a result of our monthly demos to management where we hammered this every month as a
'risk' factor”.

When asked whether any actually measurable increase or decrease in performance and/or quality had
resulted from agile adoption, Interviewee B answers: ”Hard to compare because you don't know what
would have happened if you had not used Agile. My opinion is that we delivered a new product in a
year as promised, with active on-going involvement of several customers, and now have a live product
with a happy and referenceable client base. That would not be the general outcome of most new
product development efforts, so I see it as an improvement”. She indicates however that there was a
notable change observed in customer satisfaction: ”The customers are happy and referenceable. We
had 3 customers who worked with us weekly for a year during development, and they enjoyed the
process and worked with us to prioritize competing requirements and priorities.”.

Interviewee B also provided some closing thoughts: ” I attended a session at MIT a year or so ago
which highlighted Agile adoption in a couple of different industries. The consultant 'expert' leading
the session made a comment to the effect that 'most agile projects fail because of' lack of training for
the team members (or similar). I took issue with this, if you have a development methodology that is
not able to be successful in the majority of instances when implemented by professionals in the
industry, there is something wrong with it. The presenter summarized a question I asked by saying
"How can you get better at doing Agile practices', and I corrected him. My question was 'How can
you deliver better products, on time, with customer satisfaction'. Too much time is spent with Agile
practitioners talking about the 'proper' way to do Agile. The goal is not to do 'Agile' by the book. The
goal is to deliver products successfully. If agile has a >50% failure rate, then some rethinking is
required.”.

43
Interviewee C

Interviewee C works as a Quality Director of the quality assurance department of a large India based
Communications Services company. Agile methods were introduced in 2009. Interviewee C adds “We
have used waterfall and its variations to great success. We are a CMMi Level 5 organisation as well as
TL 9000 certified”. The projects at the company vary from small projects for 3 to 6 team members, up
to programs which involve more than 100 people.

Agile adoption was initially inspired from a Business perspective and Interviewee C states that the
main driver for adoption was to “Raise customer satisfaction by increasing flexibility”. When asked
which kind of restructuring was performed in order to facilitate agile adoption, Interviewee C
answered “The re-structuring is not done at an organisation-wide level. It is local and so far the impact
has not been analysed”.

Interviewee C summarizes the main difficulties which occurred during the introduction of agile
practices: “Lack of appreciation of key requirements and principles is still a challenge. We use
different means of communicating and bringing in changes through external coaches and internal
sponsors who understand. Implementation of Engineering practices is the key challenge that is the
current focus now”. The company did provide training to overcome the learning curve: “Training and
Overview of Agile and Scrum is offered across the board on a regular basis.”

The company also faced difficulties dealing with changes in leadership style, resulting from agile
adoption. Interviewee C states: “They are still getting used to it. They resist, ridicule, question and try
to hold on to their command and control style and are generally happy being naysayers!”. Interviewee
C adds that in spite of the internal resistance, the agile adoption process is still going on, as it is driven
as a business requirement.

Interviewee D

Interviewee D is an Executive at an Agile Adoption Consulting firm located in the United Kingdom.
He is a Transformational Leadership Specialist with over twenty years of experience in leading and
advising on transformation efforts within software and technology product development businesses.
As such, he works together with progressive senior managers and C-level executives of UK
technology businesses for which effective software and technology product development is a business
imperative. The projects he is involved in are usually executed in teams of 6 to 9 people and last on
average from 3 to 6 months. Agile practices were first introduced as early as 1994 and the company
transitioned from RUP to Scrum and Kanban.

He has advised organisations where agile adoption was initiated both bottom-up and top-down,
however according to Interviewee D, the main drivers for agile adoption are “Fashion and fad”. The
main difficulties with the introduction of agile adoption according to Interviewee D are “alienation
from the rest of the (non-agile) business”. Interviewee D also points out that usually management does
not deal with the necessary changes in leadership style and team autonomy to make agile a success.

Interviewee D indicates that coaching is the mean measure used to facilitate team-work in the new
organisation. According to Interviewee D, the main restructuring required is the forming of self-
organizing teams. Interviewee D notes however that while this is received well by the team members,
this structure is in his experience received poorly by everyone else. Interviewee D also observed an
improvement of individual motivation and team performance in the short term, however in the longer
term these are followed by a decreased motivation and decreased performance. Also, in spite of
increased customer interaction, the adoption of agile methods has led to increased customer frustration
and alienation.

Interviewee concluded the interview with the comment “Agile project management should be the
responsibility of the (whole) project team. ‘Agile project manager’ is an oxymoron”.

44
Interviewee E

Interviewee E works as an independent IT consultant in France, focusing on information systems. He

has previously held various management positions, mostly working within the IT field in the
automotive industry. He has been working as a coach/teacher for incremental development and Agile
methodologies, as well as a team leader for Agile teams, as well as with traditional methodologies
such as SDM.

His first contact with agile approaches was in 1995, with RAD (Rapid Application Development).
Incremental development was performed, with time boxes of around one month. However, the agile
introduction was never made permanent, as the initiative was not supported by the middle
management. The team was dissolved during a reorganisation and that marked the end of the try.

Interviewee F

Interviewee F works as Project Manager in a governmental department New Zealand, consisting of

around 270 staff members. She has many years of experience from consulting and management within
the IT area. Teams are around 5 to 10 people, and typical project duration vary between 3 months and
2 years with budgets up to several millions NZ$.

The company normally uses a traditional waterfall-like project model, but has run a successful agile
project some years back, and a second one was done recently. They used a Scrum-like approach, with
“sprints, stories, show & tell, retrospectives, planning sessions, velocity etc.”

The current Agile project was initiated bottom-up by an IT-manager, and forced on the team. The
main drivers were to get the team to actually deliver (there had been unsuccessful attempts to get the
project to deliver during several years), and the approach was to have a short timeframe in which
something had to be delivered.

Difficulties while introducing agile practices included:

x “Poor understanding by senior management of what Agile meant in terms of fixed
deliverables”
x “The team was the biggest issue. The change in thinking was very difficult (to not have
everything detailed up front)”

The approach itself also lacked an overall plan, there was no release planning, and although there was
focus on customer interaction the architecture that was the outcome of the project ended up more
complicated than required.

When it came to management practices, very little changed from the traditional PM method used
before. Interviewee F states that “The metrics in the regular reporting changed to points per iteration.
Quality was never really measured at the management level. Risk was managed through the block
board (impediments) and weekly reports”.

According to interviewee F, the changes in management style went smoothly, and management did not
really have to master any new competencies. Except for having an experienced Scrum master, no
special guidance was needed for the team to adjust to self-management; “They took to it after an
iteration or so”.

When asked how the introduction of agile teams affected motivation, job satisfaction, expectations and
interrelationship of team members, the answer was that it was very challenging, and some team
members even left. The struggle to have team members accept the agile approach put stress on the PM
and the BA/Scrum master, but in the end, it seems to have paid off: “However, they changed their

45
attitudes a lot, without ever realising. Enforcement of collective code ownership, cross-skilling, and
constant integration became second nature.”

Part of the problems might have stemmed from the lack of training of team members and staff.
According to interviewee F, “Some team members had 'done agile' and therefore had a concept of how
it worked - which was only SOME of the practices. If we did it again I would insist on training for all
so that they are all on the same playing field.”

Some of the measures taken to facilitate the new teamwork were to encourage the team members to
pick up any task, e.g. not stick to traditional roles, and great care was taken to make sure the
“retrospective” results we taken into consideration and integrated in the process.

In the end, Agile was not adopted by the organisation.

Interviewee G

Interviewee G works with project handling at a large (1000+ employees) Telecom company in India.
The projects are mostly long-term, with constantly changing requirements (such as changes to
functionality and adding new features).

Before introducing Agile around 2 years back, they used a traditional waterfall-type project model.
The decision to introduce agile methodologies was a top-management decision, and the main drivers
were to shorten time to market and increase flexibility.

The company took the agile approach seriously, and provided ample training for both team members
and management on how Agile works, what the benefits are etc.

Interviewee G listen the main challenges of introducing agile practices to be:

x “Making people feel comfortable”
x ”Explaining the roles”
x ”Explaining to team members how it is not micromanagement”

The lack of clear roles proved to be difficult at first for team members, who were used to getting clear
directions, and the team leaders (previous managers) had a hard time not to try to micro manage the
teams.

Other problems that occurred was that some teams stared practicing their own versions of agile, and
management felt that authority was slipping through their fingers..

On the other hand, overall quality improved. Project duration became shorter, and development cycles
became faster. Risk identification improved, and flexibility of scope became better. According to
interviewee G, employees had mixed feelings on how the new way of working influenced them. Some
felt it was very effective and adjusted easily, while others felt it was just another way management
tried to micro manage their work.

In the end, “after lots of misunderstanding and difficulties, management and teams were able to accept
and practice agile”.

When asked if agile adaptation had resulted in measurable changes in performance, quality and
customer satisfaction, interviewee G means that these areas worked very well even before, and it’s
hard to say if it improved or not.

Interviewee H

46
Interviewee H works as a Project Manager at a large (1000+ employees) Belgian company in the
healthcare business. Development teams consists of 5 to 10 people, and the IT-projects vary in scope
from a few man day to thousands man days, the larger ones being divided into multiple phases. Up
until two years ago an in-house methodology based on PRINCE2 was in use. Since then, Scrum has
been introduced and is being used for certain projects, the target being to have migrated completely to
Agile project management by 2013. The main drivers for introducing agile practices were to increase
flexibility and be better equipped to deal with a varying scope, and the idea came initially from a
senior team-member who managed to sell the idea to top management.

There was no specific training performed before going agile, except for some team members that were
sent on a Scrum Master course, but rather “It was mostly trial and error, but it didn't take long before
everyone got into the agile spirit.” The new way of working has influenced motivation and team spirit,
“In the agile projects, team members were more closely involved with all aspects of the project and it
seems to have had a positive effect on motivation and team work.” Interviewee H also stated that
“This way they were much more involved with the project objectives, had direct contact with the
customer and could immediately discuss any issues in group.”

The shift to Agile has affected the group dynamics and the balance between project manager and
group members within the project team. “In general, we had to learn to relinquish some control, since
during the sprints the teams work mostly in a self-directing mode and the project manager only
follows progress from a distance and interacts only when significant issues or risks occur. Instead, we
had to learn to take up more a role of 'champion' of the project. In other words, we had to promote the
vision, act as a mentor, encourage the team and facilitate wherever possible.” There were also changes
on organisational level. “We moved away from fixed project teams and created scrum teams based on
specific expertise. That way, these expert teams work on tasks for multiple projects within a sprint.”

Regarding what the main changes in management practices were, interviewee H said that “While our
practices for risk and quality management did not change significantly, the concept of a variable scope
(and consequently budget and planning) was a major change. A mind shift was necessary at the level
of our customers, management and business. Our (internal and external) customers no longer needed
to provide detailed requirements for the entire project upfront.” This also meant some limitations, for
instance fixed price projects and projects that needed to have a specific deadline could not be
undertaken. “Instead, just as the scope, the planning and budget needed to be estimated roughly for the
entire project and were refined in detail for each next iteration (usually 1-3 months).”

The main difficulty perceived by interviewee H was adjusting to a different way of interacting with the
customer during the projects. “Initially, some internal customers had trouble with the amount of time
they needed to invest to be so closely involved throughout the project, but eventually they mostly
came to appreciate the closer involvement.” This has also influenced the customer satisfaction. ”There
is definitely a closer interaction with customers.”

Finally, in answer to if the agile adaptation has affected performance and quality interviewee H stated
that although it seems employees like working Agile and has a greater personal commitment, “It is
still a little too early to assess whether project performance has significantly increased for agile
projects. We hope to gather some factual data on this within the next few years as agile is rolled out to
all projects.”

Interviewee I

Interviewee I is a team leader and Scrum master at a large Swedish company in the banking sector. As
of January 2011, Scrum was introduced, whereas previously ITIL was used for service management
and for dealing with daily operations, SEB-RUP when working with improvements and sometimes ad-
hoc processes for other implementations. The team consists of 15 people, active in operations, IT
Management, infrastructure and maintenance

47
Agile was introduced bottom-up and the main drivers were ”improving daily operations and being able
to have a working environment in which people don't get burned-out. The business focus is to be able
to adhere quickly to legal requirements and to keep quality.”

No significant restructuring was necessary. Interviewee I states: ”I just took the role to control the
board and implemented daily scrum. I changed the meetings from one person (the old team leader)
talking to allowing each member to say something for 1-2 minutes. Then I introduced the KanBan
approach and the Scrum methodology”. ”Daily scrums of 10 minutes are held, plus 5 minutes walking
through the board. All improvements are planned into Sprints 2-3 weeks. The KanBan board is used
for the daily operations activities. Retrospectives are held at the end of each Sprint and demo day”.
Also, no training was introduced: ” None, just communicate the importance of information sharing and
teamwork”.

The main difficulties which occurred during the introduction were: ”To make the senior members
share their knowledge and to understand the concept of a product/sprint backlog. Enforcing the junior
members to take the difficult tasks and emphasizing that the seniors had to help. And as a team leader
to constantly communicate with the members”. Interviewee I adds: ”The problem was that there were
a lot of conflicts between team members , task were dependent in the individual, there was no real
knowledge sharing. There were problems with estimating time, meeting goals and to prioritize
correctly.

In spite of these difficulties, some improvements became clear quite soon. ”The most important
change was the communication atmosphere that has been improved, by the fact that we constantly
communicate.” ”The main benefit from adopting was to improve the team cooperation, knowledge
spreading and to finally being able to prioritize and to have a better communication with the business.
The problem is that slackers can have a hard time to accept this way of working as everything is on the
table every day, which can lead to other types of conflicts.”

When asked about observed changes in individual and team motivation, Interviewee I states: ” They
seem to be more relaxed, the cooperation between members has increased. To see progress every two
weeks increases confidence”. Interviewee I also notes that different personalities deal differently with
the introduction of Scrum: ”Shy individuals grow as they get used to talk about their subjects,
technical personnel can focus on technique and solutions. Conservative and lazy people have problems
with this because they get caught”.

Not only the technical team, but also the business gained from the agile adoption: ” The business are
very satisfied with our progress and thinks it is easy to follow our progress and to weight their
priorities. They now know what an additional change might cost and this makes it easy to decide what
to do and when it can be done.”

Agile adoption also had a positive effect on productivity: ”We have noted that we can increase the
number of development actives in a Spring considerably. We have also gotten a good measurement of
the support costs and can easily capture and register problems during hardware failures etc.”

4.2 Case Studies

This section examines the data gathered through reviewing existing case studies. This alternate source
of data allows us to analyse whether the data reinforces, complements or contradicts the data gathered
through the interviews.

4.2.1 Brief description of cases selected

Two case studies were selected to complement the data gathered during the interviews. They are listed
below:

48
 x Going Agile – A Case Study [53]

x Forming to Performing - Transitioning Large-Scale Project Into Agile [38]

Rather than duplicating the case study details described in these external sources, we have provided
short summaries of the relevant findings below.

4.2.2 Case Study 1: Going Agile - A Case Study

The objective of the case study was to study how agile techniques were adopted by Snowden
Technologies.

Snowden Technologies is an Australian company that provides IT solutions for the mining industry,
focusing on information systems, integration of software and business intelligence. In order to be able
to meet the demands of increased speed of change they decided to incorporate agile methodologies in
their development process. They also hope for outcomes such as better time estimation, increase
quality and better knowledge transfer.

Some of the challenges that were met are listed below:

- Difference between business expectations and what was actually delivered. This was caused
by lack of project ownership as well as unclear scope/requirements.
- Tools for information sharing/distribution were not as effective as hoped.
- Communication between different geographic locations proved hard.
- Iterative development did not match well with Project Management planning, and the agile
principles had to be circumvented to a certain extent.
- Alignment with in-house project management tools caused loss of flexibility.

In general, the inclusion of agile methodologies was considered successful, and also provided the
company with a broad array of “lessons learned”. The most important one was considered to be to
include as many people of the staff as possible in the changes, to facilitate feedback routines and
information distribution. Some physical contact (visits) between staff in different geographical offices
improved communication and let to closer cooperation.

Another important lesson was to slowly phase in techniques and approaches, rather than to change
everything at once. That way, the process can be adjusted during continuous feedback.

Specific goals should be set, so that it’s clearly visible what improvements the agile methods bring.
This will ensure that involved stakeholders feel they are getting value for their effort, and reduces the
resistance to change.

4.2.3 Case Study 2: Forming to Performing

This case study concerns the adoption of agile techniques in a very large (300+ people) in the
healthcare sector. The transformation lasted two years and was performed under guidance of an
external consultancy firm (ThoughtWorks). The case study describes how the team progressed through
Tuckman’s Phases of Group Development [69] (The Forming – Storming – Norming – Performing
model; see figure below).

49
 [38]
Figure 4-1 : Tuckman’s Phases of Group Development

The main challenges faced during the forming and storming stages of the transformation were:

- Minimal cross sub-team communication and collaboration were happening after the teams
were restructured into agile teams
- Processes were initially unclear to team members due to lack of proper leadership and
direction
- The team felt micro-managed when existing project manager took on role of agile Scrum
master
- The team had difficulty estimating tasks due to the lack of well-defined acceptance criteria
- Good practices were defined during retrospectives, but these were never subsequently
implemented
- People had tendencies to work on low hanging fruit tasks first instead of starting with the high
risk (and high business value) tasks

Many steps were taken to overcome these challenges. Outside coaches (agile experts) were hired, agile
books were distributed among the team members and brainstorm sessions were organized to come up
with solutions. Also, team activities were organized to encourage teamwork. After several months, the
teams evolved to the norming and performing phases, leading to the following positive results:

- Inter-team competition became apparent after management introduced metrics to measure the
agility of each team.
- Leaders emerged in the teams and the teams self-organized and took ownership of their tasks
- Conflicts were resolved faster and decision-making became second nature
- Team members adjusted their behaviour to each other as they developed Agile habits that
made teamwork more natural and fluid
- Building a personal rapport with the client helped understand customers better and improved
trust and collaboration were established with the customers
- Rotating responsibilities within the team made each team member feel special and valued

Some best practices suggested include introducing a dedicated quality assurance role to ensure proper
acceptance criteria are defined, hosting weekly inter-team meetings to ensure a cross-team
dissemination of knowledge and ideas and encouraging closer cooperation of management with teams
in a facilitating role.

50
5 Analysis
Data analysis was performed in two phases. The literature review concentrated on finding data
relevant to the project management fields mentioned in chapter 2 (Theory). The information under
these fields was then categorized and ordered according to our analysis model (chapter 2.2), so that
ideas and questions could be extracted.

Once questions for the interview had been constructed, the interviews together with a review of two
additional case studies were carried out. The new gathered data was analysed and compared to the
initial data summarized from the literature review. In this chapter, the analysis process is clarified and
differences/disparities are analysed for each of the dimensions of our analysis model.

5.1 Organisational Culture

The literature review illustrated how Agile adoption has a major impact on organisational culture as it
proclaims different values than traditional methodologies. These include the emphasis on innovation,
self-organisation, team-work and customer satisfaction, instead of structure and control.

Analysis of the interview data tells us that agile adoption is initiated both bottom-up (team members)
and top town (senior or middle management) for a variety of reasons, including the raising of
customer satisfaction (Interviewee A, C and I), shortening the time to market (Interviewee B and G)
and increasing flexibility (Interviewee G, H and I). In spite of the different motives and means of
introducing agile practices, all participants have indicated major challenges related to changes of in
organisational culture. Interviewees A, B and F all describe internal resistance of team members to
changes in processes, such as the necessity for collaboration over functional silos, lack of an overall
planning and the short phased monthly work increments. Such unclarity of the new processes was also
an issue in Case study 2. Interviewees B and C also identify the problems getting used to the flexible
requirements and lack of detailed upfront specifications. This finding is also supported by Case study
2. Getting the customer to invest enough time to work more closely with the team in an agile fashion
also proved to be difficult, as explained by Interviewees A and H. Interviewees D and F mentioned the
alienation which occurs when parts of the business or senior management are not involved or aware of
the implications of introducing agile practices. This may lead to a lack of leadership and direction, as
occurred in Case study 2. Finally, Interviewee I indicates that an agile mentality may clash with more
traditional or reserved personalities, as well as slackers who oppose the transparency and daily follow-
up of work performed.

Most of these challenges seem to stem from all stakeholders (team members, customers, management,
business) needing to mentally adapt to the reduction in structure and organisation and the increased
interaction required between all types of stakeholders. Interviewee C indicates his company has dealt
with these challenges by hiring external coaches and gaining internal sponsorship of key stakeholders.
Interviewees G and I also emphasize the need to make people feel comfortable upfront by clearly
explaining everyone’s roles and the implications of changes in management. Case study 1 also
indicates that it is advisable to slowly introduce these types of changes, so everyone can adjust in time.
In addition, clear goals should be set to inform every one of the value agile methods bring.

5.2 Leadership

Agile project management is often accompanied by a shift in leadership style from command and
control to increased team autonomy and accountability. In this section we examine the interview and
case study data to determine which challenges manifest themselves in this domain.

51
Most interviewees agree that changing the “command and control” mental model is the hardest
challenge. Interviewees A, C, F, G and H all indicate that it takes time for management to adapt to
these changes and in an initial phase management may resist and question the approach, while trying
to hold on to the command and control style. Case Study 2 paints a similar picture, where the project
manager took on the role of Scrum master and continued micro-managing. Only Interviewees B and I
describe a different experience wherein management loved the changes agile adoption introduced –
especially the visual daily reporting and monthly progress demos.

The companies of interviewees and A and H provided coaching and courses to team members and
especially to the Scrum master, as this role takes on some of the responsibilities (such as day-to-day
follow-up and task breakdowns), which were previously in hands of the project manager. Interviewees
F, G and I describe a situation wherein no specific guidance was required as after some time of
turbulence and misunderstandings, self-management started to emerge and the management and teams
were able to accept and practice agile.

Relinquishing control to the Agile Iteration Manager and Team appears to be the main problem. The
Project Manager should take on the role of facilitator instead of controller. Facilitation in this context,
means removing obstacles which impede team performance, while remaining responsible for overall
project monitoring, budget control, financial performance tracking, mentoring and leading,
scope/change/issue/risk management, status reporting communication to executive management,
resource acquisition and governance. Yet, in terms of team control and daily follow-up, the project
manager needs to place trust in the team and scrum master. As Case Study 2 illustrates, this can be
achieved by encouraging the team to take ownership of sprint objectives and fostering communication.

5.3 Structure

Agile teams are often composed differently than traditional project teams and have an increased focus
on self-organisation, autonomy, communication and collaboration. In this section we analyse the
interview and case study data to pinpoint the main challenges and best practices in this area.

Interviewees A and D accentuate the fact that the new teams were self-organizing and that the team
had to learn to take on the responsibility for the project outcome, where this previously was the
responsibility of the project manager. Interviewee H also underlines the move away from fixed project
teams to cross-functional teams with a shared expertise. Interviewee C indicates that the restructuring
at his company was limited to a local part of the organisation. Interviewee B notes that initially some
of the new team members still had to fulfil responsibilities related to their original role, which
impeded performance. However, during the subsequent months they were able to offload most of these
additional responsibilities. In terms of training some Interviewees (B, C, G) report trainings to cope
with the new others, while other organisations (A, F, H, I) did not provide such training.

Case Study 2 documents the fact that initially minimal cross sub-team communication and
collaboration were happening after the teams were restructured into agile teams. These issues were
resolved by organizing team activities and brainstorm sessions to encourage teamwork and
communication. The introduction of team based performance metrics also encouraged health inter-
team competition and rotating responsibilities within the team made each team member feel special
and valued.

5.4 Management practices

Agile project management involves closer collaboration with stakeholders and deals differently with
project management aspects such as scope, risk and quality management. This section analyses the
interview and case study data to identify the main challenges and best practices in the area of
management practices.

52
It is difficult to find a common thread among the interviewees regarding what changes in management
practices and how this affected results. Interviewees B and H both agree that changes in scope
management are necessary, and that this also has a positive effect on output, since the improved
flexibility in scope-management makes it easier to deliver continuously. In organisation H, this is also
one of the largest challenges, as it influences both management thinking as well the business directly
(for instance, it is not possible to take on fixed price projects or have fixed delivery dates for the
project as a whole). Interviewees B, F and G also indicates that risk management was improved as a
consequence of introducing agile.

Case Study 1 also takes up Scope definition and management as a challenge. The lack of “big picture”
initially caused misunderstandings between the business and the project teams. The business had a
view of what was to be delivered, and the team following an agile approach delivered something else.
Also, within the team there was confusion on what the scope should be, caused by lack of
communication between team-members. This was resolved by experience, feedback and the
realization that it is actually the team that together with the business decides the scope.

5.5 Work Unit Climate

Agile methods emphasize teamwork, drive and motivation. In this section we explore the main
challenges discovered during the data analysis of the interview and case study, in order to list best
practices in this area.

Interviewees B and F both indicated that the introduction of agile teams initially caused stress to the
organisations, and had examples of engineers/team members quitting their positions. The
empowerment that comes with self-regulation team gives a certain degree of freedom, but also
extended responsibilities and some people are not comfortable with that. Initially this causes some loss
of drive and motivation. Interviewees F and G also indicated that the breakup of the traditional
manager/subordinate structure caused stress on the previous managers, who had difficulties accepting
their role as just a person in the team, thus affecting the whole team, and this was also noted in Case
Study 2.

Interviewees H and I saw positive effects on both motivation and team work, once the team members
got hang of the process and felt personal involvement with the objectives of the project, while
Interviewee D saw short term improvements which deteriorated over time.

In order to facilitate the team-work in the new teams, Interviewees D and G provided coaching to team
members, while Interviewee B confess this was lacking on their part but should be done. In
organisation H, the project managers took the role of ‘champions’ of the projects, mentoring the team
members rather than managing them, and had to learn to let go of some of the control in order to
empower the team members.

Case Study 1 hinted on the difficulties in communicating between different geographical locations,
which could in part be bridged by physical visits. Generally this is not an issue in Agile
methodologies, as teams tends to be small and work close together, but large projects with sub-teams
might experience these problems. In Case Study 2 the self-organisation worked well once the micro-
managing issues had been solved, conflict solving worked better and conflicts were resolved faster.
Rotating responsibilities also seem to have had a good influence on team spirit and individual work
satisfaction.

5.6 Individual and Organisational Performance

Agile methods proclaim to increase both efficiency and quality. In this section we analyse the
interview and case study data to find the main challenges and best practices in this area.

53
Most interviewees find it hard to tell if efficiency and quality has changed in a positive or negative
direction. Interviewees B and I claims to see an improvement – in B’s example, a product was
delivered successfully in a year, an outcome she would not have expected from most product
development efforts. Interviewee H also sees an improvement in quality, but claims it is too early to
assess general project performance. What can be said in general is that none of the organisations that
introduced agile seems to have taken a baseline of quality and performance before introducing the
agile methods. Without this kind of metrics, it is difficult to objectively measure how efficiency and
performance changes.

Most interviewees agree that customer interaction has increased. For interviewees B, G and H this
seems to have resulted in a higher customer satisfaction, and Case Study 2 also confirms that working
closer to the customer leads to higher customer satisfaction. The exception is organisation D, where
the increased customer interaction instead leads to increased customer frustration.

54
6 Conclusions and recommendations
This chapter provides a summary of the analysis detailed in the previous chapter and discusses our
conclusions and their implications. We then identify some areas for possible future research.

6.1 Summary
In this master’s thesis, we have investigated the organisational impact of introducing an agile project
management methodology in a traditional company. We have identified the major challenges for
different organisational factors and based on interviews with practitioners, we have formulated
associated best practices for overcoming these challenges.

Based on the Burke-Litwin organisational change model [12], we have selected the organisational areas
we deemed to be most relevant in this context of our research and the most susceptible to agile
adoption challenges (see chapter 2.2). For each these areas we have formulated research questions
derived from a literature review of the differences between traditional and agile project management.
Based on these research questions, we have performed targeted interviews with experienced
practitioners. In addition, two relevant case studies were evaluated. Through analysis of the gathered
data, we have identified the most common agile organisational adoption challenges and related best
practices for each of the areas of our research model.

6.2 Conclusions

Some of the most common challenges encountered during agile adoption involve the adaptation to an
environment of reduced structure and control (section 5.3) as well as the changes in team dynamics
(section 5.5). Without proper guidance, this can lead to a reduction in performance and a lack of
motivation (section 5.6). Additionally, project managers often seem to have a hard time letting go of
the traditional ‘command and control’ mentality (sections 5.2, 5.4), thereby hindering or negating the
benefits of agile methodologies. Finally, the situations where agile adoption is limited to a single
department are often unsuccessful, since this leads to miscommunications and misunderstandings
across departments, as well as distancing and isolation of teams from each other (section 5.1).

The identified challenges clearly indicate that the adoption of agile project management is not just
about introducing a new set of rules or techniques. Instead, it involves a major organisational change,
which affects many stakeholders, from executives to clients and individual team members. This is
consistent with the findings of Iivari and Iivari[29] who investigated the relationship between
organizational culture and the deployment of agile methods, as well as Siaskas and Siaskas [61], who
conclude that the agile culture imposes a highly competitive environment with cultural and social
implications. In order for an agile approach to successfully take roots, a mental mind shift is required.
Based on our analysis, we conclude that executives must champion, disseminate and reinforce the
agile vision across the entire organisation. Managers must evolve from project drivers to project
facilitators, thereby learning to relinquish command and control in return for increased vision setting
and guidance. Team members must take increased ownership and responsibility for their tasks and
learn to collaborate more closely as a self-organising and self-controlling team. Finally, clients must
actively participate during the entire lifecycle of the project.

Burke and Litwin[12] highlight the interdependencies of the different organisational factors in their
model and emphasize the need to tackle issues on all these levels in order to gain overall efficiency.
From the interviews and case studies we can indeed conclude that an issue in any one of the analysed
organisational areas can severely impact project success, if not properly addressed. Many of these
challenges can be gradually overcome however, by the support of a high-level internal sponsor who
champions the agile vision top down, by initial coaching through an internal or external agile expert,

55
by introducing more team events and team metrics to support collaboration, by empowering teams
through collaborative decision making and reduced micro-management and by gradual closer and
continued involvement of customers in all phases of a project.

An agile transformation is obviously not an overnight event. In all examined cases, it was a process
which took several months to take complete effect. In the situations where the challenges were
successfully overcome however, it generally increased the potential for higher customer satisfaction,
improved flexibility and augmented team motivation.

6.3 Implications and recommendations

6.3.1 Theoretical implications

While the main focus of this thesis was on deriving practical-oriented recommendations (best
practices), our analysis was founded on academic theory. A lot has been written about agile adoption,
but relatively few academic literature is available on the subject. Most of the existing papers focus on
the practical tools and techniques applied by Agile methods at a project level, but little research has
been done on the organisation-wide implications.

In order to perform a theoretically supported analysis, we have linked the issue of agile adoption to
theory on Organisational Development and Organisational Transformation. The main theoretical
contribution of this thesis is the derivation of an Agile adoption model (a subset of the Burke-Litwin
model [12]), elaborated in chapter 2.2, which is the theoretical model for our analysis and the
framework used to classify and organise the resulting organisational challenges and best practices.

6.3.2 Practical implications and recommendations

Through the data collection and then the analysis performed in chapter 5, we have identified the main
challenges encountered during agile adoption within an organization. The sections below presents our
concrete recommendations for overcoming these challenges for each the different organisational
change areas of our derived change model (chapter 2.2).

Main challenges and best practices related to Organisational Culture

For the area of Organisational Culture, we see a clear need for education and coaching, as well as the
need for the transformation to be supported from management level. There is a trade-off here,
education and coaching is a cost to the organisation and takes time, but we believe that the effort pays
of in a short time span, and helps increase motivation and efficiency at project level.

Main Challenges Recommendations

Employee resistance to changing processes and Have an internal or external agile coach clearly
reduction of structure explain the new processes and introduce these
changes gradually
Dealing with changing requirements and Have the agile team take ownership of the
specifications requirements and ensure specifications at a
iteration level are clearly defined
Getting the client to be closely involved during Also coach the client in the agile processes and
the entire process explain the motivation and benefits of the
approach
Lack of an agile vision and direction of senior Find a high level internal sponsor who fully
management and the business supports agile adoption and helps disseminate
this vision across the entire organisation
Table 5: Challenges and recommendations related to Organisational Culture

56
Main challenges and best practices related to Leadership

The demands on the organisation within the area of Leadership are more complex. The leader role in
an agile project is not as clearly defined as in traditional project management methodologies, and
requires more motivational and coaching skills, as well as the courage to “let go” of some control and
trust the team members. According to DuBrin, a participative leadership style will work well when the
leader is one of the team, and shared leadership is often the mark of a high-performing team[19]. Often,
the best team-leaders in the new teams might not be the same persons that used to be project
managers, and this is something that needs to be carefully considered.

Main Challenges Recommendations

Relinquishing control and micro-management Coach a (non-project manager) Scrum master in
which project management can trust to perform
day-to-day follow-up. Involve the team in
important decisions.
Evolving from project driver to project facilitator Let the team take ownership of well-defined
sprint objectives. Remove obstacles and provide
an environment in which the team can operate
autonomously with minimal distractions.
Leading the team through a period of initial Champion and reinforce the overall vision.
chaos during agile adoption Motivate the team and play a role as mentor.
Foster inter- and intra-team communication.
Table 6: Challenges and recommendations related to Leadership

Main challenges and best practices related to Structure

Agile teams are composed differently from traditional project teams and have an increased focus on
self-organisation, autonomy, communication and collaboration. The increased responsibilities of team
members and reduced direction by the team lead requires a higher level of confidence from the
individual team members as well as increased teamwork. It remains crucial that the project manager
and/or Scrum master provide sufficient guidance and motivation in this respect, especially in the early
phases of agile adoption. According to DuBrin[19], the keys for the transition to effective team member
empowerment are: sharing information, providing sufficient training and support, gradually replacing
traditional organizational structure, allowing individuals and teams to determine how to achieve
objectives and above all, trusting in employees to do the right thing

Main Challenges Recommendations

Team may feel without direction due to reduced Introduce public team based performance
control of project manager metrics, to stimulate team self-organisation and
emergence of natural team leaders
Alienation of agile teams from each other and Organize inter/intra-group activities and team
rest of organisation brainstorm sessions to encourage teamwork and
communication
Team members may not be fully dedicated due to Offload team member responsibilities which
other pre-agile responsibilities distract from the agile project work (should be
handled by the facilitating role of the project
manager and scrum master)
Table 7: Challenges and recommendations related to Structure

Main challenges and best practices related to Management Practices

Agile adaptation has practical implications within the Management Practices area. The difference in
scope management gives rise to a very different approach, especially during the initiation of a project,
and fixed price projects are difficult to attempt since they often requires the scope to be defined in
detail before the project starts.

57
Main Challenges Recommendations
Dynamic scope management limiting what type Making business and customers understand the
of projects can be undertaken change in approach, e.g. explaining the concept
of rough draft and iterative refinement.
Unclear scope management Initial scope draft to be defined by team together
with owner. Iterative refinement of scope and
good feedback routines.
Table 8: Challenges and recommendations related to Management Practices

Main challenges and best practices related to Work Unit Climate

Within the area of Work Unit Climate, we see several implications which are also closely related to
the area of Leadership. In a self-managing team the team-spirit is very important, and attempts at
micro-management can have very negative consequences on spirit and performance. DuBrin mentions
minimization of micromanagement as a core ingredient of employee (team) empowerment [19]. The
team composition is also very important; role definitions and responsibilities of team members tend to
be more dynamic within an agile team, and old team members that move into the new teams need be
able to accept this.

Main Challenges Recommendations

Relinquishing control and micro-management For the team to feel ownership of the project,
thus raising motivation and promote teamwork
between the team members, micro-management
should be eliminated as far as possible.
Stress to both team members and managers, Coaching of team members to understand their
caused by the change in team dynamics. responsibilities and what is expected of them, but
also to understand what the new possibilities are.
Expanded responsibilities Rotating responsibilities and encouraging team
members to pick up new kinds of tasks works
well as a tool to let both individuals and the team
as a whole to grow.
Incompatible personalities Some people might never feel entirely
comfortable in an Agile organisation, and they
should be identified quickly so that they do not
poison the team spirit.
Table 9: Challenges and recommendations related to Work Unit Climate

Main challenges and best practices related to Individual and Organisational performance

When it comes to Individual and Organizational performance, it is important to be able to measure

how the organizational change has affected performance. Today this is often forgotten, and hence the
organisation is later unsure if agile adaptation has been successful from a performance perspective.
Metrics should be defined beforehand and a baseline taken before agile adaptation is started.

Main Challenges Recommendations

Difficulty in knowing whether the Agile Establish metrics to be able to measure these
introduction has affected quality and parameters
performance in a positive or negative way
Transition: from customer interaction only at the Gradually involve customers more and more.
start/end of the project to customer interaction
throughout
Table 10: Challenges and recommendations related to Individual and Organisational
performance

58
6.4 Possible future research

During the writing of this thesis, we have identified several possible directions of further research.
Since this was an exploratory study based on the input of a limited number of interview participants
and two case studies, it would be interesting to further examine whether our conclusions still hold for a
larger sample size. Also the difference in how the adaptation is perceived by the different participants
(e.g. team members, management, customer) could be further explored. In addition, it would be
interesting to perform a dedicated case study in a company at the verge of adopting agile practices, to
evaluate the concrete effects of our proposed best practices.

59
7 Reference List
[1]. Adjei, D. and Rwakatiwana, P. Application of Traditional and Agile Project Management in
Consulting Firms. Umeå universitet/Handelshögskolan vid Umeå universitet. 2010.
[2]. Agile Collab, Interview with Ken Schwaber, http://www.agilecollab.com/interview-with-ken-schwaber
{Acc. 2011-03-18}
[3]. Al-Zoabi, Z., Introducing Discipline to XP: Applying PRINCE2 on XP Projects. Information and
Communication Technologies: From Theory to Applications, 2008. ICTTA 2008. 3rd International
Conference on , 2008. (7-11 April 2008): p. 1-7.
[4]. Andersen, E.S. Are We Getting Any Better – Comparing Project Management in the Years 2000 and
2008. Project Management Journal. 2010. vol. 41(4) p 4-16.
[5]. Augustine, S., Payne, B., Sencindiver, F. and Woodcock, S. Agile Project Management - Steering from
the Edges. Communications of the ACM, 2008. vol. 48(12).
[6]. Bennis, W. Managing the Dream. 2000. Perseus Publishing, Cambridge, Massachusetts. Chapter 16, p
212-226.
[7]. Blumenthal, B. and Haspeslagh, P. Towards a Definition of Corporate Transformation. 1994. Sloan
Management Review, 35 (3), p101-106.
[8]. Boehm, B., Get ready for agile methods, with care. Computer, 2002. 35(1): p. 64-69.
[9]. Boehm, B. and Turner, R. Management Challenges to Implementing Agile Processes in Traditional
Development Organisations. . IEEE Software, 2005. 22(5): p. 30-39.
[10]. Boehm, B. and Turner, R. , Observations on balancing discipline and agility. Agile Development
Conference, 2003.: p. 32-39.
[11]. Burke, W., Organisation Development: A Process of Learning and Changing.1994. Addison Wesley
Publishing, New York. 280
[12]. Burke. W. and Litwin. G. H. Causal Model of Organisational Performance and change. 1992. Journal
of Management. Vol. 18 (3). p 523-545.
[13]. Chan, F.K.Y. and Thong, J.Y.L. Acceptance of agile methodologies: A critical review and conceptual
framework. Decision Support Systems. 2009. Vol 46(4). p 803-814.
[14]. Conforto, E.C. and Amaral, D.C. Evaluating an agile method for planning and controlling innovative
projects. Project Management Journal. 2010. Vol 41(2). p 73-80.
[15]. Cunningham, W, Manifesto for Agile Software Development, 2001, http://www.agilemanifesto.org
{Acc. 2011-01-28}
[16]. Deemer, P and Benefield, G, The Scrum Primer: An Introduction to Agile Project Management with
Scrum, 2007, http://www.rallydev.com/documents/scrumprimer.pdf {Acc. 2011-03-10}
[17]. Don Wells, Extreme Programming: A Gentle Introduction., 1999,
http://www.extremeprogramming.org,{Acc. 2011-01-29}
[18]. Dove, R. Knowledge management, response ability, and the agile enterprise. Journal of Knowledge
Management. 1999. Vol 3(1). p 18-35.
[19]. DuBrin, Andrew J. Principles of Leadership, 2010, 6th Edition, South-Western Cengag Learning,
Canada
[20]. Fernandez, D. J. and Fernandez, J. D., Agile project management - Agilism versus traditional
approaches. Journal of Computer Information Systems, 2008. 49(2): p. 10-18.
[21]. Found, P. and Harvey, R. Leading the lean enterprise. Engineering Management Journal. 2007. Vol
17(1). p40-43.
[22]. Garson, G.D. PA 765: Case Studies, 2008, http://faculty.chass.ncsu.edu/garson/PA765/cases.htm {Acc.
2011-02-03}
[23]. Glaser, B. G. and Strauss, A. The discovery of grounded theory: Strategies for qualitative research.
1967, Chicago, IL: Aldine Publishing Co. 271
[24]. Goodpasture, J.C. Project Management the Agile Way - Making it work in the Enterprise. 2010. J. Ross
Publishing. 320
[25]. Great Britain Office of Government Commerce, Managing Successful Projects with PRINCE2. 2009
Edition. Stationery Office Books. 342
[26]. Griffiths, M. Teaching Agile Project Management to the PMI. Agile Conference. 2005. p 318-322.
[27]. Hass, K. B., The Blending of Traditional and Agile Project Management. PM World Today, May 2007.
IX(V): p. 1-8.
[28]. Haveman, H. A. Between a rock and a hard place: Organisational change and performance under
conditions of fundamental environmental transformation. 1992. Administrative Science Quarterly. Vol
37.p 48-75.

60
[29]. Iivari, J. and Iivari, N. The relationship between organisational culture and the deployment of agile
methods. Information and Software Technology. 2011. Vol 53(5). p 509-520.
[30]. InformPerils and Pitfalls of Agile Adoption, 2006,
http://www.informit.com/articles/article.aspx?p=441115 {Acc. 2011-01-30}
[31]. Jasny, M. How to choose right (for you) project management certifications. http://pmit.pl/en/project-
management/how-to-choose-right-for-you-project-management-certifications-part-3jak-wybrac-
wlasciwy-dla-siebie-certyfikat-kierownika-projektu-czesc-3/ {Acc. 2011-03-04}
[32]. Karlesky, M. and Vander Voord M. Agile Project Management (or Burning your Gantt Charts).
Embedded Systems Conference Boston (Boston, Massachusetts). ESC 247-267. 2008.
[33]. Karlstrom, D. and Runeson, P., Combining Agile Methods with Stage-Gate Project Management. IEEE
Software, 2005. vol. 22(3): p. 43-49.
[34]. Kotter, J.P. Leading Change. 1996. Harvard Business Press; 1 edition. 208
[35]. Krzanik, L., Rodriguez, P., Simila, J., Kuvaja, P. et al. Exploring the Transient Nature of Agile Project
Management Practices. 2010 43rd Hawauu International Conference on System Sciences. 2010. p 1-8.
[36]. Laanti, M., Salo, O. and Abrahamsson, P. Agile methods rapidly replacing traditional methods at
Nokia: A survey of opinions on agile transformation. Information and Software Technology. 2011. Vol
53 (3). p 276-290.
[37]. Leavitt, H.J. Applying organisational change in industry: Structural, technological and humanistic
approaches. 1965. Handbook of Organisations. Rand McNally , Chicago, Ill.
[38]. Lee, E.C. Forming to Performing: Transitioning Large-Scale Project Into Agile. Agile 2008
Conference. 2008. p 106-111.
[39]. Lewin, K. Frontiers in group dynamics. 1947. Human Relations. Vol 1. p5-41.
[40]. McMahon, P.E. Bridging Agile and Traditional Development Methods - A Project Management
Perspective. Systems and Software Technology Conference. 2004.
[41]. Merriam, S. B. Qualitative research and case study applications in education. 1998. San Francisco:
Jossey-Bass Publishers.
[42]. Munro, R. Enabling participative change: the impact of a strategic value. 1992. International Studies of
Management and Organisation. Vol 21(4). p52-65.
[43]. Murphy, Craig. Adaptive Project Management Using Scrum,
http://www.methodsandtools.com/archive/archive.php?id=18 {Acc. 2011-03-02}
[44]. Nawrocki, J.R., Olek, L., Jasiñski, M., Paliswiat, B., Walter, B., Pietrzak, B., and Godek, P.,
Balancing Agility and Discipline with XPrince. In Proceedings of RISE. 2005, p. 266-277.
[45]. Nebulon Pty. Ltd, Feature Driven Development, http://www.featuredrivendevelopment.com/ {Acc.
2011-01-29}
[46]. Nerur, S., Mahapatra, R. and Mangalaraj, G. Challenges of Migrating to Agile Methodologies.
Communications of the ACM, 2005. 48(5): p. 73-79.
[47]. Paivi Iskanius and Heli Helaakoski. Agility in a project-oriented supply chain. International Journal of
Management and Enterprise Development. 2009. Vol 7(4). p 358-372.
[48]. Pascale, R., and Alhos. A. The art of Japanese Management. 1981. Warner Books, New York.
[49]. Patton, J. Unfixing the fixed scope project: using agile methodologies to create flexibility in project
scope. Agile Development Conference. 2003. p 146-151.
[50]. Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK®
Guide). Fourth Edition. 2008,Project Management Institute. 459
[51]. Qumer, A. and Henderson-Sellers, B. A framework to support the evaluation, adoption and
improvement of agile methods in practice. Journal of Systems and Software. 2008. Vol 81(11). p 1899-
1919.
[52]. Ramel, D. Eclipse Survey Says Scrum Most Popular Methodology.
http://adtmag.com/articles/2010/06/17/ eclipse-user-survey-scrum-most-popular.aspx {Acc. 2011-01-
27}
[53]. Read, D. And Properjohn, G. Going Agile - A Case Study. Australian Software Engineering Conference
(19th: 2008: Perth, W.A.). 2008.
[54]. Rios, F. Traditional Project Management vs Scrum - Adapting Square Pegs to Round Holes, 2010,
http://www.projectsmart.co.uk/traditional-project-management-vs-scrum-adapting-square-pegs-to-
round-holes.html {Acc. 2011-02-03}
[55]. Ryan, J.J. and Scudiere, R. The Price of Agile is Eternal Vigilance. Agile 2008 Conference, 2008. p
125-128.
[56]. Sauders, M, Lewis, P and Thornhill, A. Research methods for business students. 2009, 5th Edition,
Pearson Education Limited.
[57]. Scrum Alliance, Inc, Scrum Alliance - Transforming the World of Work, http://www.scrumalliance.org
{Acc. 2011-01-25}

61
[58]. Schwaber, K. Agile Project Management with Scrum. 2004, 1st Edition. Microsoft Press. 192
[59]. Schwaber, K. “What is Scrum?,”, 2007, Scrum Alliance.
[60]. Scrum Methodology. Has Scrum Become the Face of Agile?, http://scrummethodology.com/has-scrum-
become-the-face-of-agile {Acc. 2011-01-27}
[61]. Siakas, Kerstin V. and Siakas, Errikos. The agile professional culture: A source of agile quality.
Software Process: Improvement and Practice. 2007. Vol 12(6). p 597-610.
[62]. Sidky, A., James, A. and Shawn B. A Disciplined Approach to Adopting Agile Practices: The Agile
Adoption Framework. Innovations in Systems and Software Engineering. 2007. Vol 3 (3). p203-216
[63]. Siegelaub, J.M., http://www.prince-officialsite.com/nmsruntime/saveasdialog.asp?lID=900&sID=277.
{Acc. 2011-02-27}
[64]. Sliger, M. A Project Manager's Survival Guide to Going Agile. Rally Software Development
Corporation Whitepaper. 2006.
[65]. Strauss, A. and Corbin, J. Basics of qualitative research: Techniques and procedures for developing
grounded theory. 1990, Thousand Oaks, CA: Sage Publications. 400
[66]. Sutherland, J V and Schwaber K, Business object design and implementation: OOPSLA ’95 workshop
proceedings. 1995, Springer 1st edition
[67]. Takeuchi, H and Nonaka, I. The New Product Development Game. 1986, Harvard Business Review
(January-February)
[68]. Tellis, W. (1997, July). Introduction to case study [68 paragraphs]. The Qualitative Report [On-line
serial], 3(2). http://www.nova.edu/ssss/QR/QR3-2/tellis1.html {Acc. 2011-01-25}
[69]. Tuckman, B. Developmental sequence in small groups. 1965. Psychological Bulletin. Vol. 63 (6).
p384–99
[70]. Tudor, D. And Walter, G.A. Using an agile approach in a large, traditional organisation. Agile 2006.
2006. p367-373.
[71]. Tushman, M.L. and O'Reilly, C.A. Ambidextrous Organisations: Managing Evolutionary and
Revolutionary Change. 1996. California Management Review. Vol. 38(4).
[72]. Weisbord, M.R. Organisational Diagnosis: Six Places to Look for Trouble with or without a Theory.
1976. Group & Organisation Studies. Vol 1(4). p430-447.
[73]. Weisbord, M.R. Productive workplaces: Organizing and managing for dignity, meaning and
community. 1987. Jossey-Bass, Inc, San Francisco. 448
[74]. Wikipedia. Scrum (rugby). http://en.wikipedia.org/wiki/Scrum_(rugby). {Acc. 2011-02-24}
[75]. Yahoo! News, New Survey Shows Complexity, Hybrid Agile Methods and Customer Demands Are
Driving Factors For Requirements Management, 2011,
http://news.yahoo.com/s/prweb/20110126/bs_prweb/prweb4999174 {Acc. 2011-01-30}
[76]. Yin, R. K, Case Study Research – Design and Methods. 2003. 3rd Edition. Sage Publications

62
8 Appendices

8.1 Interview questions

Introduction

In the context of our Master’s thesis in the field of Business Administration at the Blekinge Institute of
Technology, we are conducting research related to the Organisational Challenges when adopting
Agile Project Management practices in Traditional Organisations. In light of this, we are looking for
input from experienced project/programme managers and team members who are working (or have
worked) in a company environment where agile practices are/were first introduced. This open ended
interview questionnaire is intended to illicit information concerning both the main challenges
organisations face during such transformations, as well as best practices for overcoming these
challenges.

All provided company identification data will be held strictly confidential and analysis results will
solely be published on an aggregate basis. Of course we will be happy to share the results of our final
thesis reports with all participants.

Feel free to forward this questionnaire to any potentially interested parties who fit the participant
profile. The end date for our data collection is May 1st 2011. For any questions about this study, do not
hesitate to contact us.

Thank you very much for your participation!

Rami Hansenne rahd09@student.bth.se

Allan Hibner alhf09@student.bth.se

Participant Profile
x Name (will not be published):
x E-mail (will not be published):
x Company name (will not be published):
x Company sector:
x Company size: 1-100, 101-1000, 1000+ employees
x Function:
x Country:
x Would you like to receive the results of our thesis on completion: (yes/no)

Context
x Please briefly describe the usual type, scale and duration of projects and average project team
size at your organisation.
x Which traditional project management methodology (e.g. PRINCE2, PMBoK, custom in-
house,…) has been in use at your company and which type of agile practices (e.g. SCRUM,
DSDM,…) are being/have been introduced?
x As of when were agile project management practices introduced at your company?

Main Questions

Organisational Culture

63
 x Was agile adoption initiated from a strategic vision perspective (top management or business)
or was it introduced bottom up?
x What are your organisation’s main drivers for introducing agile practices (e.g. shorten time-to-
market, raise customer satisfaction, increase flexibility, …)?
x What were the main difficulties while introducing agile practices (e.g. resistance to agile ideas
or changes required in cross-departmental processes, customer interaction,…) and what was
undertaken to overcome these difficulties?

Leadership

x How did management and team members deal with changes in leadership style and autonomy
resulting from agile adoption and what was undertaken to guide this change?
x Which new competencies (if any) did management have to master to accommodate these
changes?

Structure

x What kind of team and responsibility restructuring was performed in your organisation to
accommodate agile methods and how were these changes received?
x What kind of training was required to overcome the learning curve?

Management Practices

x What were the main changes in management practices (such as in terms of scope, risk quality
management) introduced at your organisation resulting from agile adoption and what were the
observed results (both positive and negative)?

Work Unit Climate

x How did the introduction of agile teams affect the motivation/job satisfaction, expectations,
and interrelationships of team members?
x What measures were taken to facilitate teamwork in the new organisation?

Individual and Organisational Performance

x Has agile adoption at your organisation resulted in any measurable increase or decrease in
performance and/or quality at either an organisational or individual level?
x What kind of notable changes have been observed in customer satisfaction and/or
interactions?

Other

x Do you have any comments, suggestions for further investigation or other information related
to the topic of agile project management adoption?

Thank you for your participation!

64
8.2 LinkedIn Target Groups
The following LinkedIn groups were approached for soliciting interviewee participants:

LinkedIn Group Group Profile

Agile Project Managers “Group for Agile Project Managers (Scrum, XP, User Stories, Hyb) and
Employment / Digital Agencies involved in hiring for Agile projects
and contracts. All profiles are pre-screened for admission to this group
making a small group for real professionals.”
Agile Alliance “Purpose: To connect Agile practitioners. Join this group if you support
Agile Alliance and Agile in general.
One of the easiest ways for us to connect people was using Linkedin.
By recommending or certifying each other, via Recommendations
feature in LinkedIn, we can build a trusted network. Which offers an
alternative to certification.”
Scrum Practitioners “This is a group for Scrum professionals i.e. those actively practising
the Agile Project Management techniques advocated by the Scrum
Alliance and Scrum.Org. Open to all levels of experience and
certification.

This group exists to help support and spread the knowledge and
implementation of Scrum and Agile in general. Off topic postings or
jobs will be removed. Persistent or egregious offenders risk removal
from the group.”
Agile Project “The Agile Group is a project management community for
Management Group professionals who believe in agile methods to control projects through
iteration and incremental approach. The main objectives are a
combination of collaboration + cost effectiveness + on-time delivery +
meeting business changing needs.”
Agile “Share Knowledge, Get Answers, Collaborate with peers.

Members can contribute and share their Agile knowledge and

Resources. Get answers to their questions and collaborate with peers.

Agile Product & Project Management, Agile Software Development,

etc...”
The Project Manager “The largest project manager group on Linkedin. Connect with alumni,
Network friends, and colleagues to discuss PM methodology, classes, PMI PMP
certification, PDU classes and training, or to find Project Management
jobs.

The Project Manager Linkedin group, brought to you by

ProjectManagers.net, is a project management forum and group.
Members can use the group for discussions about project management,
project software, project methodology, project management
certification, or just to network locally for pm jobs and project
management related business opportunities.

Members of the group include project managers, PMO leadership,

project consultants, and project management software vendors, authors,
and bloggers.”
Agile & Scrum “This sub group is for all PM Link members on Linkedin that want to
discuss about Agile Project Management, Agile Software Development
and SCRUM methodology.”

65
The Agile Project “This group is for the community of Agile adopters.
Management Hub
If you’re a developer, product manager, project manager, QA - this is
the group for you.

if you are interested in Agile software development and want to learn

more about how to manage projects using Agile methodologies - this is
the group for you.

If you teach about Agile adoption. practice Agile, or want to get started
- this is the group for you.

Here you’ll find relevant information, articles, discussions and

resources. Of course, you are all invited to share, evaluate and join the
discussions.

This group intends be the online Hub for all things Agile. Scrum, Lean
and Kanban, and is powered by TargetProcess, Agile Project
Management Software, www.targetprocess.com”
PMO - Project “PMO - Project Management Office.
Management Office
Participants represent all the key industries, government offices,
defence and SMEs, giving the group a broad base of knowledge and
experience to draw on.

Program, Portfolio, Project Managers looking for best practices, tools,

methodology, certifications, Forum, Articles,...”
Scrum Practitioners, “Scrum is an iterative incremental process of software development
Scrum Masters commonly used with agile software development.

Those who adhere to the agile methodology (Scrum) in their work are
highly enthusiastic invited to share your thoughts, your knowledge and
ask questions.”
Agile Advocates “This group is for technology professionals who are interested in
networking, sharing expertise and job opportunities in the Southeast.
Most members of this group are connected to Agile, an Atlanta-based
IT resource that speeds time to talent for technology leaders. This group
is one of the many innovative ways Agile reduces our clients’ time to
talent and delivers superior performers. Join us to discover how Agile
can make a difference in your career.”
PRINCE2 Project “9,000+ Professionals: The definitive PRINCE2 & MSP group. Come
Management & MSP and discuss PRINCE 2 Project and Programme Management best
Programme Management practice, jobs, news, exams, documents, templates, training, events etc.
Foundation / Practitioner qualifications and Portfolio / Program PMO
Management.”
Agile PMP “The PMI Agile Community of Practice is the result of a grass-roots
initiative between a pioneering group of Agilists and the Project
Management Institute (PMI) to create a new Agile Community of
Practice within the PMI, with the stated purpose "to equip PMI
members with Agile knowledge and skills".

The PMI Agile Agile Community of Practice serves as a connecting

body between Agile and PMI groups, facilitating communication,
cooperation and collaboration between the Agile and PMI
communities.”

66
Real World Practices “While you can learn about best practices, Real World Practices focuses
specifically on how to apply and use best practices in the real world.

Best practices might include but are not limited to PMBOK, PMP,
Prince, Prince2, CMMI, ISO-9001, Agile, Scrum, ScrumMaster, CSM,
Kanban, Six Sigma, IEEE, ITIL, Unified Process, UML, RUP…”
Table 11: LinkedIn groups used to approach interview candidates

67