The Role of the Project Manager in Agile Software Development Projects

Abstract

Agile teams are not meant to have project managers. Instead, agile methods such as Scrum and 2 XP define roles such as product owner, scrum master, and coach. Studies have uncovered the 3 existence of the project manager in agile projects, pointing to disconnect between theory and 4 practice. To address this gap, a Grounded Theory study with a mixed methods approach was 5 conducted using multiple sources of data including over 45 hours of interviews with 39 software 6 practitioners and quantitative data from 57 questionnaire respondents. We present and describe the 7 project manager’s role in agile projects in terms of (a) everyday activities: facilitating, mentoring, 8 negotiating, coordinating, and protecting, performed by the project manager using; (b) three 9 management approaches: hard, moderate, and soft; (c) four traditional project management 10 activities continued to be performed by them, including: tracking project progress, reporting on 11 project status, budgeting and forecasting, and managing personnel; and (d) the influence of the 12 presence of the project manager on the frequency with which agile activities are carried out by the 13 teams. Our study highlights the continued presence of the role of the project manager in agile 14 software projects as a part of the transition from traditional to agile ways of working.

Full text

1
The Role of the Project Manager in Agile 1
Software Development Projects 2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

2
Abstract 1
Agile teams are not meant to have project managers. Instead, agile methods such as Scrum and 2
XP define roles such as product owner, scrum master, and coach. Studies have uncovered the 3
existence of the project manager in agile projects, pointing to disconnect between theory and 4
practice. To address this gap, a Grounded Theory study with a mixed methods approach was 5
conducted using multiple sources of data including over 45 hours of interviews with 39 software 6
practitioners and quantitative data from 57 questionnaire respondents. We present and describe the 7
project manager’s role in agile projects in terms of (a) everyday activities: facilitating, mentoring, 8
negotiating, coordinating, and protecting, performed by the project manager using; (b) three 9
management approaches: hard, moderate, and soft; (c) four traditional project management 10
activities continued to be performed by them, including: tracking project progress, reporting on 11
project status, budgeting and forecasting, and managing personnel; and (d) the influence of the 12
presence of the project manager on the frequency with which agile activities are carried out by the 13
teams. Our study highlights the continued presence of the role of the project manager in agile 14
software projects as a part of the transition from traditional to agile ways of working. 15
16
17
Keywords—project manager, agile software development, agile project management, scrum 18
19
20
21
22
23

3
1 Introduction 1
The project manager is considered pivotal in traditional software development projects involving 2
multiple aspects of managing teams such as leadership, team building, motivation, communication, 3
influencing, decision making, planning, and coaching [2]. In traditional software development 4
methods, such as the waterfall model [3], [4], the project manager sits within a well-defined 5
hierarchy in the project team [2], playing a role very similar to the one outlined in project 6
management literature [1]. 7
With its emergence in the late 1990s, Agile Software Development (ASD) introduced self-8
organizing teams to software engineering [15]. Self-organizing teams have been characterized as 9
teams displaying significant autonomy in taking decisions [7], managing workloads and allocating 10
work amongst themselves [8], [9]. Scrum introduced two new roles: the scrum master – primarily 11
responsible for facilitating team functioning and removal of impediments, and the product owner 12
– mainly responsible for representing the customer and guiding the product vision [10], [16], [17]. 13
XP introduced the role of the coach – tasked with process and team guidance [11]. In fact, the job 14
title and role of the project manager simply does not exist in popular ASD methods such as Scrum 15
and XP [10], [15], [16], [17]. 16
However, there is growing evidence that the job title of the project manager is still in existence in 17
organizations practicing ASD [12], [13], [14], [44], highlighting a gap between what agile theory 18
recommends and what is implemented in practice. Previous studies have investigated the project 19
manager’s preference for agile methods [20], their views on conflicts in the team [13], and the 20
underlying tensions emerging from conflicting expectations about the project manager’s role in 21
ASD projects [21]. Additionally, studies on self-organizing teams have hinted that a certain 22
proportion of the erstwhile manager’s responsibilities are carried out by the new roles such as 23
scrum master, and product owner [6], [22], [24]. To date there has not been a dedicated study 24
which comprehensively looks at the role of the project manager in agile projects. The ambiguity 25
surrounding the project manager’s role in ASD is clearly expressed by a leading practitioner 26
compendium on agile, the Agile Practice Guide, jointly published by the Project Management 27
Institute (PMI) and Agile Alliance, when it says that “the role of the project manager in an agile 28

4
project is somewhat of an unknown, because many agile frameworks and approaches do not 1
address the role of the project manager” [23]. 2
The ambiguity surrounding the project manager role can be broken down into the following 3
questions: Do agile projects have identified project managers (alongside agile roles)? What does 4
the project manager do on a regular basis in agile projects? What management styles or approaches 5
does the project manager adopt when carrying out their role? What influence, if any, does the 6
project manager exert on the agile practices carried out by the team? Are there any traditional 7
project manager activities still carried out in agile projects? We address and attempt to answer 8
these and a critical overarching question: “What is the role of the project manager in agile 9
projects?” 10
An earlier publication of the preliminary results [46], based on 21 interviews, had presented the 11
roles played by managers in agile teams: the mentor, coordinator, negotiator, and process adapter. 12
Our current paper is focused on the project manager role in depth. In this paper, we present a theory 13
of the role of the project manager in agile projects resulting from a Grounded Theory study with a 14
mixed method approach based on multiple and varied data including over 45 hours of semi-15
structured interviews with 39 software practitioners and quantitative data from 57 questionnaire 16
respondents. This theory explains how the project manager performs five different activities – 17
facilitating, mentoring, negotiating, protecting, and coordinating – on an everyday basis, by using 18
three different management approaches – hard, moderate, and soft – and the possible influence of 19
the project manager on the frequency with which agile practices are carried out by teams. The 20
project manager continues performing some of the traditional project management duties such as 21
tracking project progress, reporting on project status, budgeting and forecasting, and managing 22
personnel even in ASD projects. As far as we are aware this is the first Grounded Theory study to 23
present a comprehensive picture of the project manager in agile projects. 24
In the following sections we present the literature review, the research methodology, the key 25
findings, discussion and implications of the findings, a comparison to relevant contemporary 26
research, limitations, and the conclusion. 27

5
2 Literature Review 1
The following section presents a literature review which traces the evolution of traditional software 2
development, the role of the project manager, the introduction of agile methods in the software 3
industry, and the status of the project manager in agile software development projects. 4
2.1 Traditional Software Development 5
Waterfall, a popular traditional software development model, is a specification-driven approach 6
characterized by extensive planning, upfront requirements gathering, detailed documentation, and 7
a focus on immaculate execution of the process [3],[4]. Waterfall incorporates many aspects of 8
traditional project management such as the sequential arrangement of different development steps, 9
emphasis on extensive upfront planning and a phase-based approach [25]. 10
The main criticisms of the waterfall approach is linked to its poor flexibility to changes in the 11
project environment [26], [27]. The fact that the sequential waterfall model did not fit well into a 12
fluctuating software development environment was recognized early on, resulting in an alternate 13
spiral model proposed by Boehm [28]. This model focused on addressing risks and involving the 14
customer in the development process. To address the human aspects of software development, 15
Boehm and Ross also proposed a people centric theory of software project management (known 16
as Theory-W) which proposed that the project would be successful only if the project manager was 17
responsible for generating a win-win situation for users, customers, team members, and concerned 18
stakeholders [29]. 19
2.2 The traditional project manager 20
The earliest conceptualization of the project manager was given by Gaddis in the 1950’s as 21
someone who: “manages a team of professionals, whose job is finite in duration, who recruits the 22
project team, conducts project planning and is able to sell the project to stakeholders” [30]. More 23
recently, the 2018 edition of the Project Management Body of Knowledge (PMBOK), defines the 24
project manager “as the person assigned by the performing organization to lead the team that is 25
responsible for achieving the project objectives” [1]. A project manager is envisioned as a 26
connection between the project team and the stakeholders. In recent years, there has been a surge 27
in the demand for project managers across different industry sectors [31]. This is reflected in the 28
burgeoning membership of professional bodies such as PMI and an increase in their members who 29
hold project manager certifications [55]. 30

6
The PMBOK emphasizes that the project manager should possess some key competencies and a 1
range of interpersonal skills [1]. A project manager is expected to be proficient in leadership, team 2
building, motivation, communication, influencing, decision-making, political and cultural 3
awareness, negotiation, trust building, conflict management, planning, effective supervision, 4
budgeting, and coaching [1], [2]. Research studies have proposed individual competencies such as 5
leadership and communication skills [32], stress management [33], courage, and temperance [31]. 6
This model of the project manager role is not universally accepted [31], [34-36], [39], [40]. Based 7
on their qualitative study of large project-based organizations, Loufrani-Fedida and Missonier [39] 8
suggest it is unrealistic to expect the project manager to display all the competences ascribed in 9
the literature. They recommended that some of the individual competencies assumed for an ideal 10
project manager should be shouldered by functional managers [39], [40], who have operational 11
responsibilities for a department within the organization [1], and are typically not associated with 12
project teams. 13
Other criticism of the PMBOK’s view of the project manager’s role include Cicmil et al. [37], 14
objecting to its portrayal as a “skilled technician” i.e. a person whose role primarily centers on 15
controlling time, cost and the scope of the project, or as the “implementer” of a large body of 16
standards, practices and techniques prescribed by professional project management literature [36], 17
echoing the criticisms of Morris [38] and Morris et al. [34]. Overall, the current definition of the 18
traditional project manager in theory is seen to be at odds with practice even in traditional software 19
development projects. When looking to the current understanding of the project manager’s role in 20
agile software projects, things are more ambiguous. 21
2.3 Agile software development 22
Agile software development (ASD) is an umbrella term for a set of incremental and iterative 23
development methods such as Scrum [10], eXtreme Programming (XP) [11], dynamic software 24
development method (DSDM) [41], and feature-driven development (FDD) [42]. ASD has a clear 25
emphasis on people and on rapid response to change [7], [15]. In the last decades, the adoption of 26
ASD has been extremely rapid in the software industry worldwide [44], [54]. 27
In the recurring industry-based “state of agile” survey [14], [44], [75] Scrum was identified as the 28
most commonly used agile method. In the most recent iteration of the survey, 58% of respondents 29

7
indicated that their project used Scrum as a standalone agile method and over 76% when used in 1
combination with other methods [14]. The next popular standalone method was Kanban, with 7% 2
of respondents while XP was reported as being used by a minority (<1%) of the respondents. While 3
Scrum focuses on the project management aspects of agile such as estimation and planning, XP 4
focuses on development practices such as test-driven development and pair programming [45]. 5
In recent years there has been a flowering of research on “large scale agile”. This is in part a 6
reflection of the growing need in the software industry on clear guidelines regarding implementing 7
agile in large projects with multiple teams. Dikert et al in their systematic literature review (SLR) 8
have defined large scale agile as, “software development organizations with 50 or more people or 9
at least six teams [68]”. In their SLR, Dikert et al [68] discovered that Scrum was the most popular 10
method used in organizations which were undergoing large scale agile transformation. 11
2.4 The project manager in Agile software development 12
In ASD methods, such as Scrum, and XP, the job title and role of the project manager simply does 13
not exist [11], [16], [17]. Scrum introduced two new roles, namely that of the product owner and 14
the scrum master [10]. The product owner is the customer representative, whereas the scrum master 15
is primarily the internal facilitator [5]. XP introduced different roles such as the coach, consultant, 16
tracker, programmer, customer, tester, and the big boss [11]. Of these, the coach is responsible for 17
the process, guiding the team and learning from other XP teams [11]. It seems that the scrum 18
master, product owner and the XP coach roles share some characteristics and responsibilities of 19
the traditional project manager [1], [11]. Critically, the job title and role of the project manager 20
does not exist in agile methods. 21
Industry surveys [44] and recent research [12], [46] point to the continued existence of the job title 22
of the project manager in agile projects. The recent industry surveys have indicated that nearly 23
14% to 23% [44] of their respondents were project or program managers while a research study 24
shows nearly 67% of the respondents’ projects had a project manager present [12]. 25
Recognizing the reality of the project manager’s co-existence with self-organizing agile teams, the 26
Agile Practice Guide, a joint publication of PMI and the Agile Alliance, has re-fashioned the 27
project manager’s role as a “servant leader” [23]. As a servant leader, the project manager’s focus 28
is on coaching, collaboration, and stakeholder management. 29

8
While considerable research has been done into the various aspects of agile teams [13], [20], [21], 1
[47], research on the project manager’s role in agile is still scarce. 2
Taylor’s ethnographic study [21] on the experience of project managers in ASD identified that 3
underlying “tensions exist as PMs may still be held responsible for project outcomes, yet they are 4
expected to delegate decision making to the team” [21]. This tension is due to differing 5
expectations of management and the team [47]. While senior management expects the project 6
manager to take responsibility for project delivery and adopt a controlling approach if necessary, 7
on the other hand, the teams expect a light touch “servant leader” type approach [47]. 8
A recent study by Siddique and Hussein [13] addressed conflict within agile teams from a project 9
manager’s perspective, attributing it to a lack of experience of the project manager, lack of 10
customer involvement, budgetary issues, and ego conflicts within teams. The consequences of 11
such conflicts can be a drop in productivity, lowering of motivation, and poor decision making. 12
Bishop et al.’s [20] study on the reasons behind project manager preferences for agile methods 13
revealed that the project managers had a pragmatic approach when selecting an agile method. 14
Project managers appreciated the practical benefits of agile adoption such as adaptability, 15
increased efficiency and faster delivery of features but also identified negative factors, such as a 16
desire for fixed outcomes. 17
Overall, we find that the role of the project manager in traditional software development as defined 18
by traditional standards and the body of knowledge [1] is not universally accepted [34, 36-39]. 19
Furthermore, there is ample ambiguity around the role of the project manager in agile software 20
development as proposed in theory [5], [10], [11], [17] and identified in practice [12], [14], [44], 21
[46]. This leaves a critical gap in research, to define and describe the role of the project manager 22
in agile software development. 23
2.5 Recent Trends in Agile Research 24
Implementing agile on a large scale has been the topic of extensive research in the last few years 25
[60], [61], [62], [63], [64], [65], [66], [67], [68]. As early as 2013, Dingosyr and Moe [66] had 26
identified large scale agile transformation, inter-team coordination, and scaling of agile practices 27
as some of the key topics for future research in large-scale agile. This call to research has been 28
answered by several researchers in the last few years and one of the persistent focal points for 29

9
research has been inter-team coordination in large scale agile projects. Researchers have studied: 1
coordination in large scale agile using the multi-team systems perspective [60]; the manner in 2
which agile practices are tailored for the large scale implementation [61], [63], [68]; adoption and 3
sustenance of agile frameworks [64]; roles of the product owner [67]; and team autonomy [65]. 4
The coordination aspect was also studied by Gustavsson [63] who looked at the manner in which 5
coordination routines such as the scrum of scrums are enacted and the reasons for which they are 6
enacted in a particular manner. Paasivaara and Lassenius [68] investigated the ways in which large 7
firms such as Ericsson dealt with coordination challenges over large multi-team projects. A similar 8
approach was reported at Spotify by Šmite et al [61] who conducted a study of Spotify’s culture 9
of guilds to understand how coordination was carried out across multiple teams. Conboy and 10
Carroll [64], based on their long running research on adoption and sustenance of agile frameworks, 11
identified nine challenges associated with adopting large scale agile frameworks. Researchers have 12
also studied the role of the product owner in large scale agile [67]. Team autonomy is another area 13
of large scale agile that has been touched upon by researchers [65]. 14
Some of the works cited above are particularly relevant to our findings and are discussed in detail 15
in section 6. 16
3 Research Methodology 17
The starting point of our Grounded Theory (GT) study was to investigate the role of the project 18
manager in agile projects. To this end we conducted a quantitative study to see if the job title of 19
the project manager still existed. The results indicated the job title of project manager is still widely 20
used [12]. 21
This led to the next step where we designed the qualitative questionnaire to investigate the role of 22
the project manager. Before piloting the qualitative questionnaire to the first set of 10 participants, 23
it was felt necessary to gather information about the participant’s project and professional 24
background prior to the face-to-face interview. Thus, a quantitative questionnaire (the pre-25
interview questionnaire) was created which was sent to the participants a few days before the 26
interview. The complete pre-interview questionnaire has been uploaded to Dataverse and the link 27
has been provided in the references [76]. The pre-interview questionnaire was extremely useful as 28
we could use the information to tailor the interview questions appropriate to the participant’s 29
context. Additionally, as the qualitative interviews had fixed duration (usually under an hour), we 30

10
could focus in the interview on asking questions relevant to the participants project, rather than 1
using the precious interview time to gather demographic information. 2
After the first 10 interviews the pool of qualitative and quantitative questions was broadened to 3
include questions regarding agile practices and involvement of the project managers in selected 4
practices. 5
3.1 Grounded Theory as the Research Methodology 6
GT is defined as, “a general methodology of analysis linked with data collection that uses a 7
systematically applied set of methods to generate an inductive theory about a substantive area” 8
[48]. GT owes its genesis to the work of two sociologists, Barney Glaser and Anslem Strauss, who 9
developed it in the mid-1960s [49], [50]. 10
The growing attractiveness of GT to software engineering researchers [51] lies in two factors. 11
Firstly, GT is well suited to generate a theory for a relatively new discipline such as software 12
engineering. Secondly, GT is an inductive process rather than a deductive one. The inductive 13
process plays a critical role in uncovering the underlying concerns of software engineering 14
practitioners. Stol et al.’s [51] review of grounded theory application in computer science and 15
software engineering found 98 journal articles published between 1995 and 2015 that used GT or 16
used selected techniques from GT, including a large number of studies which have used GT to 17
study the human and social aspects of software engineering [6], [13], [18], [52-54], [56], [57]. An 18
additional benefit is GT’s flexibility to accommodate both qualitative and quantitative data, 19
although this has not been exploited fully thus far in software engineering research. 20
For this study, we have used the Glaser’s GT method with a mixed method approach using both 21
(qualitative and quantitative) data collected via interviews and questionnaires, as explained below. 22
While there is some level of mixing of qualitative and quantitative data in our study, there is also 23
a degree of separation between both the strands. A GT study by its very emergent nature makes 24
pre-determined and systematic mixing of qualitative and quantitative data challenging [50]. 25
3. 2 Quantitative Data Collection and Analysis 26
The quantitative data collection was conducted in two phases: The first phase was designed to 27
investigate whether the job title of the project manager still existed in agile projects. This survey 28
was posted on LinkedIn in several groups which had participation by software engineering 29
practitioners and the survey had 94 respondents. The analysis of this survey demonstrated that the 30

11
job title of the project manager was still extant in a majority of the respondent’s projects [12].The 1
second phase of quantitative data collection involved creating and administering a “pre-interview 2
questionnaire” to participants of the face-to-face interview. Participants for the interview process 3
were recruited through a call for participation posted on LinkedIn, and social media accounts of 4
agile groups such as Agile Auckland. 5
Additionally on LinkedIn, in order to shortlist participants for the interviews, BOOLEAN search 6
operators were used to identify software practitioners who were working in an agile environment. 7
For example, search terms such as “Agile & New Zealand” were used to generate lists of 8
prospective participants. Relevant participants were identified based on these searches and a 9
connection request was sent to them. Participants were made aware of the focus of the research, 10
that is, project managers, and, where requested, additional information pertaining to the research 11
project was sent. This was a time-consuming process and resulted in approaching between 300-12
400 practitioners. Out of these around 57 agile practitioners responded to our request and agreed 13
to participate in the research process. Once consent was obtained from the participants, they filled 14
in the pre-interview questionnaire. However, only 39 participants proceeded to the subsequent 15
interview process which formed the basis of the qualitative data. 16
The pre-interview questionnaire created using Google forms was used as it was felt essential to 17
build a picture of the participants’ backgrounds and demographics prior to the interviews. In this 18
way, the interview could focus more on the open-ended questions. The link was emailed to 19
participants at least one week prior to the interview. The response options to the questions included 20
a mixture of multiple choice questions such as “please select the relevant agile methodologies you 21
have used”, closed ended questions such as “is there a project manager on your project?” and 22
Likert scale type questions such as “please rate the frequency of using the practices listed below”. 23
The quantitative data obtained from 57 pre-interview questionnaire responses was mostly Likert 24
scale data. This was first cleaned by applying consistent labeling in the manual entry responses, 25
and the responses were compared to the interview transcripts to cross-check for any errors. Once 26
the survey data was validated and its integrity verified by running Cronbach’s Alpha test, it was 27
transferred into IBM SPSS v.24. The test scale of Cronbach’s Alpha goes up to 1. In terms of scale 28

12
reliability values over 0.8 are considered good while over 0.9 are very good [59]. The Cronbach's 1
Alpha is 0.939 for the section of our questionnaire which asked participants to grade the 2
involvement of different roles in agile practices. While for the section which asked respondents to 3
rate how frequently agile practices were used in their projects, the Cronbach Alpha is 0.895. We 4
used the descriptive statistical technique of cross-tabulation as it was found to be most suitable for 5
analyzing Likert scale data. 6
For example, a survey section asked participants about the frequency of use of common agile 7
practices such as daily scrum, user stories, and retrospectives which were derived from the list of 8
common practices used in the state of agile surveys [44]. The full list of practices can be seen in 9
Table 2 later. These had five response options: very frequently, frequently, occasionally, not used, 10
and not applicable. For analysis purposes we combined the results of “frequently” and “very 11
frequently” into a higher-level classification “High Frequency of Use (HFU)”. The cross tabulation 12
was run against two key questionnaire items: the identified presence of the project manager (PM) 13
on an agile project and the frequency of use of a set of common agile practices. The Percentage 14
Difference Level (PDL) is derived by the following formula: 15
PDL= (HFU as % of cases in which PM is present) - (HFU as % of cases in which PM is absent) 16
A positive PDL value indicates that the frequency of a practice goes up when the project manager 17
role is present. Similarly, a negative PDL value indicates that the frequency of a practice goes 18
down when the project manager is present. The results of the cross-tabulation analysis are 19
discussed in the findings section. 20
3. 3 Qualitative Data Collection and Analysis 21
The qualitative data was collected from 39 agile practitioners who agreed to an interview after 22
filling in the pre-interview questionnaire (summarized in Section 3.2). Thirty-two of these 23
participants were from New Zealand, five from India and one participant each from Australia and 24
the USA. Most of the interviews were on average an hour long and were conducted face to face, 25
except for four, which were conducted over Skype as the participants were unavailable in person. 26
All of the recorded interviews were transcribed using a professional transcriptionist who was 27

13
approved by the University. Prior to outsourcing of the transcription, the transcriptionist signed a 1
confidentiality agreement to protect participant data. 2
Table 1 PARTICIPANT DEMOGRAPHICS 3
Participant
Number
Job Title
Experience in
Agile
Team Size
Country
Project Sector
P01
Developer
2
11-15
USA
Banking
P02
Project Manager
<1
11-15
New
Zealand
Local Government
P03
Project Manager
4
6-10
New
Zealand
Telecommunications
P04
Project Manager
4
>25
New
Zealand
Local Government
P05
Programme
Manager
10
0-5
New
Zealand
Insurance
P06
Software Product
Manager
3
>25
New
Zealand
Banking
P07
Project Manager
5
6-10
New
Zealand
Insurance
P08
Project Manager
12
11-15
New
Zealand
Telecommunications
P09
Senior Project
Manager
5
16-20
India
Banking
P10
Product Owner
3
6-10
New
Zealand
Telecommunications
P11
Programme
Manager
10
16-20
New
Zealand
Finance
P12
Scrum Master
4
>25
New
Zealand
Local Government
P13
Developer1-Agile
Coach
2
10
0-5
New
Zealand
Accounting1-2
P14
Agile Coach
10
6-10
New
Zealand
Telecommunications
P15
Developer
4
0-5
New
Zealand
Finance
P16
Scrum Master
5
6-10
Australia
Utilities
P17
Project Manager &
(Scrum Master)
3
21-25
New
Zealand
Accounting
P18
Scrum Master
1
6-10
New
Zealand
Finance
P19
Scrum Master
5
6-10
New
Zealand
Education
P20
Technology
Consultant &
(Product Owner)
4
11-15
India
Telecommunications
P21
Scrum Master &
(Agile Coach)
7
>25
New
Zealand
Finance
P22
Developer
6
6-10
New
Zealand
Finance
P23
Software Engineer
& (Scrum Master)
1
6-10
New
Zealand
Taxation
P24
Product Manager &
(Product Owner)
5
16-20
New
Zealand
Software
P25
Quality Analyst
9
6-10
New
Zealand
Education

14
P26
Scrum Master
6
16-20
New
Zealand
Entretainment
P27
Senior Director
Product
Management
12
6-10
New
Zealand
Human Resources
P28
Project Manager1-
Scrum Master
2
10
6-10
New
Zealand
Retail1&2
P29
SAP Delivery Team
Manager & (Scrum
Master)
8
21-25
New
Zealand
Retail
P30
Solutions Architect
1
16-20
New
Zealand
Retail
P31
Programme
Manager1- Product
Owner
2
5
6-10
New
Zealand
Tourism1-Healthcare2
P32
Tribe Lead
8
0-5
New
Zealand
Healthcare
P33
Scrum Master1-
Software Engineer
2
3
6-10
New
Zealand
Human Resources1-
Software
2
P34
Software Engineer
5
0-5
New
Zealand
Healthcare
P35
Senior Test
Engineer
9
16-20
New
Zealand
Healthcare
P36
Team Lead &
(Scrum Master)
5
6-10
New
Zealand
Healthcare
P37
Project Manager1-
Scrum Master
2
2
6-10
India
Software1-Software2
P38
Scrum Master
4
6-10
India
Security
P39
Scrum Master1-
Scrum Master
2
9
6-10
India
Finance1-Payment
Solutions
2
(The numbers “1” & “2” in superscripts are used to differentiate the job title and project sector of the participants who spoke 1
about their role in multiple projects) 2
The interview included questions such as: 3
Please tell me briefly about your professional background and your current role in this 4
organization; 5
How would you describe the Project Managers role on the project? 6
Who was responsible for negotiating with stakeholders and how was negotiation done? 7
Were there any obstacles in the way of team functioning/performance? If yes, how were they 8
resolved? 9
What are the major challenges you have faced while working in the agile project? 10
How did you overcome those challenges? 11

15
Table 1 shows a breakdown of the participant demographics and project information. To ensure 1
confidentiality, the participants have been assigned code numbers beginning with a “P” i.e. P01, 2
P02, etc. During the interview process, a number of participants chose to speak about more than 3
one project in which they had worked in different capacities. For example, in one project they 4
might have been a team member, while in another they could have been a project manager. Thus, 5
they would be providing information from different perspectives and talking about different roles. 6
In such a scenario to avoid mixing up the data, we adopted a simple scheme to indicate the job title 7
and the project sector of the participant across more than one project. For example, in Table 1, for 8
participant P13, in the “Job Title” column, the job title “Developer1-Agile Coach2” indicates that 9
the participant was referring to a developer role in an earlier project and an agile coach role in a 10
later project. Similarly, moving to the column titled “Project Sector”, the label “Accounting1-2” 11
with the numbers in superscripts indicates that the project sector was the same for both the projects. 12
In addition to the data obtained from participants who were project managers, others such as testers 13
and developers provided substantial information regarding the role of project managers in their 14
projects. These project managers referred to by participants are identified by an alphanumeric code 15
(for example, PM1, PM2 etc.). 16

16
1
Figure 1 Emergence of key concepts and categories leading to the formulation of the theory of the 2 project manager in agile projects, using Grounded Theory data analysis. 3
The key techniques used to identify patterns within the interview data collected from 39 4
participants were the GT procedures of open coding and the constant comparison method [48], 5
[49]. The software used for data analysis was QSR nVivo v.11, a software tool for qualitative data 6
analysis. The analysis was performed by the primary researcher in consultation with the co-7
authors. Figure 1 shows an overview of the GT analysis process and the emergence of the key 8
concepts, categories, and the theory. As an example, we have given snippets of raw data followed 9
by a couple of key codes and concepts which constituted two key categories, that is, the activities 10
of facilitating and coordinating. In the following paragraphs we explain some of the key steps of 11
performing a Grounded Theory analysis. 12
Open coding: This is the process of coding the interview transcripts line-by-line. This is necessary 13
to identify substantive codes emergent within the data [48] . The first stage of analysis involved 14
sifting through the raw data (interview transcripts) and extracting snippets of data from the 15
transcript. Glaser and Holton have explained the process as, “The process begins with line-by-line 16
open coding of the data to identify substantive codes emergent within the data. The analyst begins 17
by coding the data in every way possible—running the data open” [49]. This data was then 18

17
assigned a code, which is a phrase that summarized the data snippet in a short and clear description, 1
usually between 2-5 words long. An example of data analysis from the raw data stage to the codes, 2
concepts and category is presented below. 3
Raw data: “The business analyst was extremely blunt when he was dealing with the product owner 4
in terms of decisions that were being made and whether something was worth doing or not doing, 5
which caused friction within the relationship. I would basically then facilitate a smoother 6
transaction in terms of stepping in to make sure we continue to work together.” – P07, Project 7
Manager, New Zealand. 8
Code: Resolving conflicts 9
Constant comparison method: This is a continuous and iterative process of generating codes by 10
analyzing interviews and then comparing the codes to those generated within the interview and 11
within other interviews in the dataset. This process results produces higher levels of abstraction 12
such as concepts and categories [48]. The code “resolving conflicts” was found to share 13
similarities with two other codes, namely, “facilitating issue resolution” and “clearing 14
obstacles”. These codes were grouped to a higher-level concept of “facilitating minesweeping” 15
where minesweeping refers to identifying and removing obstacles for the team. 16
Concept: Facilitating minesweeping 17
The concepts were further grouped to the category of the “Facilitating” as an informal activity 18
carried out by the project manager. The concepts which were grouped included: facilitating 19
minesweeping, facilitating team functioning and facilitating processes. 20
Category: Facilitating 21
Other categories which emerged in a similar way included mentoring, negotiating, coordinating, 22
and protecting. Together they represent the ‘everyday activities performed’, a key dimension of 23
the role of the project manager on agile projects. 24

18
Through the analysis, differences in how project managers approached the same activities 1
emerged. In particular, we found that project managers adopted from three management 2
approaches when performing these everyday activities: hard, moderate and soft. 3
The hard aspect reflects the assertive posture adopted by a project manager in the project. This 4
means a firm and assertive approach in the best interests of the team and the project given the 5
context. This does not signify an uncompromising and controlling attitude. The moderate approach 6
is a mixture of assertiveness and subtle persuasion. This can also be thought as the “middle path” 7
approach. The facilitation activity abounds with examples of this approach. 8
An approach was classified as soft when the thrust was on subtle and gentle persuasion. This does 9
not mean indecision or irresoluteness. The project manager only takes over the team controls in 10
exceptional circumstances. The soft approach is also a vote of confidence in the team’s capabilities. 11
Each of these approaches is discussed in the context of the everyday activities performed by the 12
project manager in the findings section. Finally, project managers were also seen to continue 13
performing some traditional project management activities, such as tracking project progress, 14
reporting on project status etc. 15
Memoing: Memos are a concrete record of the researcher’s decisions throughout the research 16
process. Glaser has defined memos as, “a theoretical note about the data and the conceptual 17
connections between categories written down as they strike the researcher” [58]. Memos by nature 18
are free-flowing chunks of text which allow the researcher to informally capture a snapshot of the 19
research in time. 20
Selective coding: In contrast to open coding, selective coding focuses only on the key categories 21
and concepts which are related to the emerging theory. Once the underlying key categories had 22
emerged we stopped open coding and began selective coding for the key categories. The 23
emergence of the key categories and the overall theory of the project manager in agile projects is 24
shown in Figure 1 and the final theory with its different dimensions is shown in Figure 2. Glaser 25
and Holton have emphasized that, “Selective coding means to cease open coding and to delimit 26

19
coding to only those variables that relate to the core variable in sufficiently significant ways as to 1
produce a parsimonious theory. Selective coding begins only after the analyst is sure that he/she 2
has discovered the core variable” [49]. 3
Theoretical coding: This is the process of using a theoretical structure to visualize the relationships 4
between the categories. GT has several theoretical coding families which helps researchers to 5
present their theory [58]. Theoretical coding has been explained as, “theoretical codes 6
conceptualize how the substantive codes may relate to each other as hypotheses to be integrated 7
into the theory. Theoretical codes give integrative scope, broad pictures and a new perspective” 8
[49]. Thus, theoretical coding is the process of using a theoretical structure to visualize the 9
relationships between the categories. In the GT milieu there are different types of theoretical 10
coding families. Some of the theoretical coding families are: the Six C family (causes, contexts, 11
contingencies, consequences, covariances, and conditions); the process family (stages, phases, 12
phasing’s, transitions, passages, careers, chains, sequences); the strategy family (strategies, tactics, 13
techniques, mechanisms, management); and the dimensions family (social norms, social values, 14
social beliefs) [58]. It is important that the theoretical coding model should fit the findings of 15
analysis, rather than forcing the findings into a theoretical family [58]. 16
17
Figure 2 . A grounded theory of the role of the project manager in agile projects described in 18 terms of four dimensions. 19
As the data findings emerged, initially the Six C model seemed like a good fit to visualize 20
relationships. However, our findings did not map onto the Six C model, primarily because of the 21
lack of ‘covariance’ related findings, which is one of the six C’s. We referred back to literature to 22
look for a more appropriate model. Thus, further reflection led us to conclude that the theoretical 23
a) Everyday activities performed
facilitating, mentoring, negotiating, coordinating,
and protecting b) Management approaches applied
hard, moderate, soft
c) Traditional project management activities
performed
tracking project progress, reporting on project status,
budgeting & forecasting, and managing personnel
d) Influence on agile practices
frequency of practicing scrum of scrums, velocity
measurement, & release planning increased while iteration
planning, definition of done, and user stories decreased with
presence of the project manager
The role of the project
manager
in agile projects

20
coding family best suited to our findings was the dimension family [48], [49] which enables the 1
findings to be presented a facets or aspects of a phenomenon, in this case dimensions of the role 2
of the project manager. Thus, the role of the project manager in agile projects is described in terms 3
of: 4
a) the everyday activities: facilitating, mentoring, negotiating, coordinating, and protecting, 5
performed by the project manager using 6
b) three management approaches: hard, moderate, and soft, 7
c) four traditional project management activities: tracking project progress, reporting on 8
project status, budgeting, forecasting, and managing personnel, and 9
d) the influence of the presence of the project manager on the frequency with which agile 10
practices are carried out by the teams. 11
A diagrammatic visualization is given in Figure 2. 12
Theory: The role of the project manager in agile projects 13
The dimensions (a), (b), and (c) represent findings of the qualitative data analysis while the 14
dimension (d) represents the results of the quantitative data analysis. The qualitative data were also 15
seen to supplement and help explain some of the results of the quantitative data analysis. All the 16
constituent elements of our theory are discussed in detail in the following sections. 17
4 Findings 18
In this section, we describe each dimension of the role of the project manager in agile projects: the 19
influence of the presence of the project manager on the frequency with which agile practices are 20
carried out by the teams, the project managers’ management approaches to everyday activities, 21
and the traditional project management activities performed by the project manager. While the 22
findings in sections 4.2 and 4.3 emerged from the GT analysis of the qualitative data, the findings 23
presented in section 4.1 are those that were obtained from the analysis of the pre-interview 24

21
questionnaire questions. This is an example of the treatment of qualitative and quantitative data in 1
a mixed methods approach to an exploratory GT study. 2
4.1 The Project Manager’s Influence on Agile Activities 3
In response to the question, do agile projects have identified project managers (alongside agile 4
roles)? We found evidence of the existence of project manager in 70% (N=40 of 57 pre-interview 5
questionnaires) including both primary participants and referred project managers. The product 6
owner was identified to be present by 85% and the scrum master by 83% of the participants. 7
In response to the question, what influence, if any, does the project manager exert on the agile 8
practices carried out by the team? The cross-tabulation analysis results are summarized in Table 9
2, where the last column “Percentage Difference Level (PDL)” shows the difference between the 10
HFU percentages in the second and third columns. A positive value of the PDL indicates that if a 11
project manager is present, there is an increase in the frequency of an agile activity. Whereas a 12
negative PDL value indicates that the frequency goes down when a project manager is present. 13
As can be seen from Table 2, the activities which exhibited the greatest increase in their frequency 14
of use when a project manager was present were the scrum of scrums meeting, project velocity 15
measurement, and release planning. These three agile activities showed a positive PDL of 15% to 16
24%. Each of the above agile activities has coordination and facilitation requirements. For 17
example, scrum of scrums is an agile activity which involves holding scrum meetings with 18
representatives from different agile teams working on a common project. This requires someone 19
who can coordinate between different teams and ensure that the meeting takes place. This is 20
supported by our qualitative data analysis where we found that the project manager was highly 21
involved in coordinating across different teams in agile projects. It was also clear that a part of the 22
project manager’s role involved traditional project management duties such as tracking project 23
progress, budgeting, and forecasting. This explains why the activities of project velocity 24
measurement and release planning saw a noticeable positive effect in their frequency of use. 25

22
Table 2 Influence of the project manager on frequency of use of agile activities by the team 1
Agile Activities
HFUa as % of cases
in which PM is
present (N=40)
HFU as % of cases
in which PM is
absent (N=17)
Percentage
Difference Level
(PDL)
Scrum of Scrums Meeting
53% (N=21)
29% (N=5)
24%
Project Velocity
Measurement
68% (N=27)
53% (N=9)
15%
Release Planning
80% (N=32)
65% (N=11)
15%
Team Based Estimation
63% (N=25)
54% (N=9)
9%
Daily Scrum/Daily Standup
90% (N=36)
83% (N=14)
7%
Short Iterations/Sprints
68% (N=27)
65% (N=11)
3%
Kanban Board
75% (N=30)
77% (N=13)
-2%
Product Backlog
88% (N=35)
91% (N=16)
-3%
Iterations/Sprint Reviews
78% (N=31)
83% (N=14)
-5%
Sprint Backlog
83% (N=33)
88% (N=15)
-5%
Information Visualisation
83% (N=33)
94% (N=16)
-11%
Retrospectives
78% (N=31)
94% (N=16)
-16%
Agile Games
32% (N=8)
54% (N=7)
-22%
User Stories
63% (N=25)
89% (N=16)
-26%
Iterations/Sprint Planning
43% (N=17)
71% (N=12)
-28%
Definition of Done
60% (N=15)
100% (N=13)
-40%
(aHFU=High Frequency of Use. The percentages in the table correspond to N=40 in cases where 2
project manager was present and N=17 where project manager was not present. The PDL was calculated 3
by the formula PDL= (HFU as % of cases in which PM is present) - (HFU as % of cases in which PM is 4
absent)) 5
On the other hand, activities such as iterations or sprint planning, definition of done, and user 6
stories saw a marked negative PDL when the project manager was present. The magnitude of 7
negative PDL ranged from negative 22% to 40%. We did not find any direct support of this result 8
from our qualitative data analysis of the interview data. Further investigation is needed to 9
understand this indication of a negative influence of the project manager on these agile activities. 10
4.2 The Project Managers’ Approaches to Everyday Activities 11
In response to the questions, what does the project manager do on a regular basis in agile projects? 12
And, what management styles or approaches does the project manager adopt when carrying out 13
their role? we present a mapping of the everyday activities of the project manager with the 14
management approaches in Table 3. These are described in detail below, with examples. 15
16

23
Table 3 Mapping of the project managers’ activities with management approaches 1
Activity
Description
Management Approach
Examples
Facilitating
Clearing obstacles and issues,
facilitating the project teams
functioning, increasing process
efficiency, and ensuring quality
control.
Moderate to Hard
P02,P03, P04,P07,
P08,P20, PM7
Mentoring
Empowering the team on the
path of self-organization,
educating the team and
stakeholders in agile practices,
and ensuring team adherence
to agile practices.
Hard, Moderate, and
Soft
P02,P03, P04,P07,
P08, P37
Negotiating
Negotiating project funding,
issues, scope and commitment
to work, with customers,
vendors and the development
team.
Moderate to Hard
P07,P10, P13, P28,
P31
Coordinating
Coordinating project logistics,
such as release of deliverables
and human capital, and
coordinating collaboration
between the customers, teams
and technical specialists.
Moderate
P02, P07, P17,
PM2, PM3, PM6,
PM8, PM9
Protecting
Shielding the team from
external interference and
pushing back on scope creep.
Hard
P06, P08, P28,PM2
2
Overall, based on the qualitative interview data and instances of the everyday activities identified, 3
it was seen that nearly all project managers were involved in facilitating, while over half were 4
involved in coordinating and negotiating, less than half were involved in mentoring, and few 5
(approximately one quarter) were involved in protecting. We have defined the management 6
approaches as follows: 7
• The soft approach: This approach is characterized by the project manager adopting a 8
“hands-off” approach to the teams day-to-day functioning, encouraging the team to become 9
self-sufficient by acting as a coach, and creating an atmosphere which facilitates open 10
discussions. 11
• The moderate approach: This approach is characterized by the project manager facilitating 12
and coordinating across issues and people in the agile projects. The project manager is 13
ready to jump in and lend a hand to the team whenever necessary. 14

24
• The hard approach: This approach is characterized by the project manager adopting an 1
assertive and uncompromising stance when the project manager feels that the team or 2
stakeholders attention needs to be focused in a particular channel. This approach is 3
particularly used when there is a persistent obstacle to the teams functioning. 4
4.2.1 Project Managers’ Approaches to Facilitating 5
Facilitating involves the project manager clearing obstacles and issues, facilitating the project 6
teams functioning, increasing process efficiency, and ensuring quality control. Based on the 7
qualitative data analysis, the project manager’s approach to facilitation can be classed as 8
somewhere between moderate and hard. The hard aspect of facilitation was when an assertive 9
posture was adopted by the project manager. Some of the terms used by participants which 10
illustrated the hard approach were “driving them” and “poke and prod”. While terminology such 11
as “discuss”, “jump in”, “lend a hand” showed the more moderate to soft approach. However, 12
based on a majority of participant reports (N=17), the project manager’s attitude towards 13
facilitation was more aligned between the moderate and hard aspects. The project managers’ 14
moderate to hard management approach to facilitating is explained with examples below. 15
The project managers’ approach was determined by who they were dealing with. For example, in a 16
government project, the government body had outsourced development of a key component to a 17
third-party vendor. The vendor used agile while the government organisation used waterfall. Before 18
the vendor could start development, technical specialists at the customer end had to clear the 19
documentation. This became a bottleneck and delayed the vendor’s development team, who were 20
eager to get started. The project manager (P02) who was an external contractor brought in by the 21
government body, pushed the technical specialists to clear the documentation as soon as possible. 22
On the other hand, when dealing with the team, the project manager’s (P03) attitude was to assist 23
the team. Even if the stakeholders were using a waterfall approach, the project manager (P03) let 24
the team practice documentation at a level where it satisfied stakeholder demands but did not 25
become cumbersome for the team. 26

25
Several project managers (e.g. P04, P07, and P08) maintained good relations with the team but did 1
not hesitate to be firm on certain issues. If the project manager (P04) observed that the team’s 2
collective voice was being muffled by a particular dominant member, the project manager did not 3
hesitate to address the issue even if it led to possible conflict with the dominant team member. 4
However, P04 ensured that every team member had a say in the meetings as it was essential to 5
empower the whole team. This was very much the hard approach in action. With the rest of the 6
team, P04’s approach can be best characterized as moderate. 7
Transition to agile from waterfall can be confusing to team members and cause conflicts with team 8
members used to a stage-gate model of development. In this situation, transition “pangs” amplified 9
minor issues. As was appropriate in this scenario, the project manager (P08) adopted a moderate 10
stance and brought the “warring parties” to the negotiating table. P08 was successful in getting a 11
compromise between the developers and testers in this case. 12
The only instance we came across of a project manager with a soft approach to facilitation was in 13
the case of an entertainment sector project. The project manager (PM7) was a first-time project 14
manager and had a complete hands-off approach towards the team. PM7 let the scrum master (P26) 15
facilitate at the team level, while he took care of the dealings with senior management. 16
Thus, overall, the project manager’s approach to facilitation can be described as between moderate 17
to hard. 18
4.2.2 Project Managers’ Approaches to Mentoring 19
Mentoring involves the project manager empowering the team on the path of self-organization, 20
educating the team and stakeholders in agile practices, and ensuring team adherence to agile 21
practices. The project managers’ approach to mentoring moved between the hard, soft and medium 22
approaches depending on the situation, as explained below. 23
There was an interesting demonstration of the soft aspect when the project manager was a motivated 24
“early adopter” of agile. Here, the project manager (P37) came across the concepts of agile while 25
looking for ways to improve the productivity and gradually “injected” agile practices such as the 26

26
daily stand up without introducing them as agile practices. The team became convinced of the 1
benefits of agile once they had experienced some. 2
But the soft aspect of mentoring really came into play when the project managers doubled up as 3
informal scrum masters. Some indicative terms used by project managers to flag this approach were, 4
“not constantly checking up”, “open discussion”, “like a coach”, and “becoming self-sufficient”. 5
On a telecommunications project, the project manager (P03) acted as the scrum master as well. 6
While the team was beginning to mature in agile, the customer organization operated in a very 7
traditional waterfall way. With the team, P03 acted as the scrum master and saw his role more as a 8
coach. The team was enthusiastic about agile with good all-round participation in activities such as 9
planning poker. When interfacing with the customer, P03 assumed the role of the project manager 10
and educated the customer on the rationale behind agile. 11
The hard aspect of mentoring was when an assertive posture was adopted by the project manager. 12
“Pushed”, “move along” were some of the terms used by project managers to describe this 13
assertiveness. For example, on a local government project, the project manager (P02), intervened 14
to keep meetings on track and within time. In this scenario, the team was taking its first steps in 15
agile and needed a lot of oversight. Product demonstrations were one area where the team became 16
lax. P02 had to push them to hold regular demonstrations. P02 also informally set up one of the end 17
users as the product manager and facilitated regular team interactions with them. 18
This hard aspect was also seen in a banking sector project where although the organization was 19
mature in agile, the team was essentially composed of beginners in agile. Initially, enforcing agile 20
practices remained a large part of the project manager’s (P07) repertoire. As the team matured in 21
agile, P07 lessened his degree of control until a stage was reached when the team became more self-22
organizing. In P07’s own words, “they could have operated without me needing to be there”. 23
A mixture of the hard and soft aspect gave rise to the middle path or the moderate approach. This 24
was seen on another local government project, where the project manager (P04), was managing 25
three different teams. P04 personally set up and ran the daily stand up meeting and did a combined 26
stand up with all the teams once a week. The team was transitioning to agile from a waterfall 27
environment. The project manager gave the team a lot of freedom to challenge existing practices 28
including agile and gave them a free hand with the project documentation. Here, P04’s role was 29

27
evolving into a hybrid of the scrum master and project manager roles. In fact, P04 saw his role more 1
as a coach than as a controlling project manager. 2
4.2.3 Project Managers’ Approaches to Negotiating 3
Negotiating involves the project manager negotiating project funding, issues, scope and 4
commitment to work, with customers, vendors and the development team. 5
In terms of negotiation, the project manager’s approach fell between hard and moderate 6
approaches. Negotiation is part of the project manager’s traditional responsibilities [4] and even 7
in some agile projects the project manager oversaw negotiations. This view was supported by 8
several participants (P02, P08, P10, P13, P28, P31, and P35) who saw negotiation as one of the 9
key responsibilities of the project manager. Some terms indicative of this approach were: “get to 10
the point”, “negotiate”, “plan”, “convince”, and “talk”. 11
A good example of the likely need for the project manager to exist alongside the product owner in 12
an agile project was demonstrated in the case of P07. While the product owner’s role is to act as 13
the customer representative, the project manager’s key focus was to ensure that all project 14
deliverables were completed successfully. The project manager could adopt a hard stance on behalf 15
of the team when negotiating funding with the customers. In the case of P07, the project manager 16
told the senior management that the project deliverables would not be met without further funding, 17
backing this up with a strong business case. It was generally seen that scrum masters, though 18
sometimes involved in negotiating certain aspects with the customers such as project scope, steered 19
clear from tracking finances and negotiating funding. These were seen to fall under traditional 20
project management activities covered by the project manager (described further in the next sub-21
section). 22
This moderate to hard continuum was also useful when dealing with vendors, who 23
sometimes needed to be chased up for delivery of features. 24
4.2.4 Project Managers’ Approaches to Coordinating 25
Coordinating involves the project manager coordinating project logistics, such as release of 26
deliverables and human capital, and coordinating collaboration between the customers, teams and 27
technical specialists. 28

28
The project manager’s approach to coordinating was moderate. “Come together” “discuss”, 1
“coordinate”, “overall delivery”, “release process”, and “right resources” were some of the terms 2
used by project managers to indicate coordination. 3
Coordination usually involved coordinating the release of deliverables, resourcing and staffing the 4
teams, liaising with senior management, and sprint coordination. A majority of the project 5
managers (P02, P07, P17, PM2, PM3, PM6, PM8, and PM9) were responsible for coordinating 6
the delivery of features completed by multiple teams. The project manager was responsible for 7
ensuring that the deliverables met the standards and the release was done in synchronization. One 8
of the project managers (P17) termed the entire multiple team environment as an “ecosystem”. P17 9
identified his key responsibility was to keep the ecosystem functioning. In projects with multiple 10
teams, the project manager (PM2, PM9) looked after sprint coordination. The project manager’s 11
role as the coordinator also finds indirect confirmation from our quantitative data (see section 4.1). 12
The project manager’s presence possibly led to an increase in the scrum of scrums meeting, which 13
exhibited a PDL of nearly 24%. This could mean that the project manager is leading multi-team 14
projects which necessitate agile activities such as the scrum of scrums meeting, which in turn are 15
key coordination mechanisms in large scale agile. This aspect will be further discussed in section 16
5. 17
4.2.5 Project Managers’ Approaches to Protecting 18
Protecting involves the project manager shielding the team from external interference and pushing 19
back on scope creep. The project manager adopted the hard approach to protect the team from 20
external disruptions. The hard stance was particularly on display when the project manager was 21
trying to prevent scope creep (e.g. P08, P28). The project manager acted as a barrier against last 22
minute changes by the customers. This naturally called for a hard or firm approach. However, this 23
hard approach did not emerge in isolation. The project manager built up good collaborative 24
relationships with the stakeholders by frequent meetings and clear communications. It was this 25
moderate approach during business-as-usual which gave the project manager confidence to take a 26
hard stance when protecting the team. 27
The project manager (PM2), who oversaw external and internal project dependencies, actively 28
pushed back on the scope creep. P06 had a very good collaborative association with the project 29
manager and consulted PM2 frequently regarding the impact of changes on the project. 30

29
4.3 Traditional Project Management Activities 1
In response to the question, are there any traditional project manager activities still carried out in 2
agile projects? We found the project manager performing some traditional project management 3
activities. As several participants pointed out, even with the team being self-organizing, there was 4
the need for a role to tackle external dependencies and administrative overheads. 5
Tracking project progress: One of the most common activities of the project manager was to 6
keep an eye on the project’s progress. This was done by observing the agile project management 7
tools such as JIRA (P05) and burn up charts, and by tracking project velocity (P06, P07, P27, and 8
P31) which the teams maintained, and creating custom project documents to track progress. 9
Tracking progress was done in either “active” or “passive” modes. The active mode involved 10
talking with team members and gaining insight into the bottlenecks which were holding up project 11
velocity. The passive mode involved tracking project velocity using tools like those used in 12
Kanban. 13
Reporting on project status: Project reporting was generally driven by traditional management 14
layers which overlaid onto the agile teams (P04, P08, P10, and P14). In the case of a public-sector 15
project, the project manager (P04) clearly identified that fixed deadlines (delivery dates) and 16
budgets drove the reporting. This necessitated periodic generation of status reports destined for a 17
variety of stakeholders. 18
“From a reporting point of view, I had to follow their reporting methods. I had to kind do all the 19
finances, kind of like a burnup chart.” – P04, Project Manager, New Zealand. 20
Budgeting and forecasting: Interestingly, one of the possible reasons for the continued existence 21
of the project manager in agile projects was given by a scrum master, who opined that the project 22
manager was needed to carry out project management activities such as financial management and 23
reporting, as these fell outside the domain of the team. Financial tracking along with generating 24
regular project status reports was identified as part of the daily administration responsibility of the 25
project manager (P07, P08). Additionally, dealing with customer invoices was also a part of the 26
project manager’s responsibility (P08, P14). 27

30
Managing Personnel: Another administration aspect was personnel management which included 1
conducting routine performance reviews and appraisals (P09, P39), career progression planning, 2
resolution of outstanding personnel issues (P20), and holidays (P39). 3
5 Discussion and Implications 4
As mentioned in section 2.4, cornerstone practitioner literature on Agile, particularly that on 5
Scrum, does not envision any role for the project manager in its framework [17]. However, as we 6
have shown in our present and previous study [12], the role of the project manager is still in 7
existence even in agile projects. Thus, our findings are particularly relevant as they allow us to 8
present an approximation of where exactly the project manager fits in the agile scheme of things 9
in the software industry. In Table 4 we have presented a mapping of the activities of the project 10
manager (from our study) and the similarity or point of difference with those given in the scrum 11
guide. From Table 4, it can be seen that most of the activities performed by the project manager in 12
our study should be, as per the scrum guide, performed by the scrum master. Additionally, Table 13
4 also shows the traditional project management activities that are still carried out by project 14
manager even in agile projects. These activities do not have any analogous activity assigned to any 15
of the scrum roles (scrum master, product owner, and development team) in the scrum guide. This 16
gap between practitioner literature and our findings, does seem to indicate that there is a need for 17
a role (like the project manager) who can track project progress, do budgetary reporting, and 18
conduct personnel management. 19
Table 4 A comparison of project manager activities from our study with the scrum guide. 20
Role responsible for the activity in
the scrum guide
Project Manager activities from our study which
map to the activities in the scrum guide
Clearing obstacles and issues
scrum master
Facilitating the project teams functioning
scrum master
Increasing process efficiency
scrum master
Ensuring quality control
scrum master
Empowering the team on the path of self-organization
scrum master
Educating the team and stakeholders in agile practices
scrum master
Ensuring team adherence to agile practices
scrum master
Coordinating collaboration between the customers,
teams and technical specialists
scrum master
Shielding the team from external interference
scrum master
Pushing back on scope creep
scrum master
Project Manager activities not in the scrum guide
Tracking project progress
Not in the scrum guide

31
Reporting on project status
Not in the scrum guide
Budgeting and forecasting
Not in the scrum guide
Managing Personnel
Not in the scrum guide
Negotiating project funding, issues, scope and
commitment to work, with customers, vendors and the
development team
Not in the scrum guide
Coordinating project logistics, such as release of
deliverables and human capital
Not in the scrum guide
1
Additionally, there were some important considerations which dictated what stance the project 2
manager adopted: a) Was the project manager playing a double role, that is, acting as the scrum 3
master as well; b) Was the project manager an enthusiastic early adopter of agile; and c) Was the 4
team transitioning to agile? Each of these points is discussed below. 5
The duality of the project manager’s role is one of the findings of our research. We found 6
conclusive evidence of the project manager simultaneously performing the scrum master role. This 7
is also reflected in the mapping presented in Table 4. Depending on the organizational context and 8
the circumstances of the project, the project manager could be called upon to perform the role of 9
the scrum master (P06, P09, P10, P14, P17, P20, P28, and P35). The project manager thus had to 10
adopt a dual approach to deal with different entities such as the development team and 11
stakeholders. One of the common reasons for the duality of the project manager’s role was 12
organizational resource constraints and the organization transitioning from waterfall to agile. This 13
also seems to suggest that the project manager role might be interim while the organization 14
grapples with the transition to agile. So long as the need for traditional project management 15
activities continue in an organization (for example, due to their unique contexts), the project 16
manager role is likely to be present. 17

32
1
Figure 3 The relation between the activities and the management approaches adopted by the 2 project manager 3
Another key finding was the management approach adopted by the project managers when dealing 4
with customers, team members, and suppliers. The inter-relationship between the activities and the 5
management approaches is shown in Fig.3. A majority of the project managers were found to 6
adopt a moderate approach, closely followed by the number of project managers adopting a hard 7
approach. In fact, the soft approach was adopted by very few project managers. It was found that 8
some project managers had a consistent approach across different activities (such as facilitating 9
and mentoring). The mapping of the approach with the activity is given in Table 3. 10
Another aspect was that a few project managers had a consistent approach across different 11
activities. For example, P07 and P02 adopted a hard approach across different activities such as 12
facilitating, mentoring, and negotiating. The key point is that in these cases it was the project 13
manager who was taking the initiative to introduce agile to the team members. 14
On the process side of things, some project managers took care of the scrum ceremonies such as 15
running the daily standups, the sprint, and could also write user stories. While the traditional 16
project management aspect consisted of personnel management, negotiation, project delivery and 17
planning. This suggests that the project manager’s role is still needed in performing non-agile (but 18
essential) activities such as performance reviews and multiple team coordination. 19
The project manager playing the role of the scrum master has certain advantages and 20
disadvantages. The advantage is that the project manager is aware of the constraints faced by the 21

33
team and in this formal title can effectively liaise with stakeholders to resolve those constraints. 1
On the flip side, the roles of the scrum master and project manager calls for different perspectives 2
on certain issues. It is also possible that if the project manager is an early adopter of agile he might 3
convince the team to transition to agile. This is an aspect which merits further investigation. 4
With traditional organizations looking to experiment with agile, the managers in the pilot agile 5
teams often find themselves in a difficult situation. This is due to limited freedom to innovate, a 6
large traditional working overhead, and the feeling of impermanence stemming from the agile 7
implementation. Our recommendation to senior management is to be clear as to the purpose of 8
adopting agile. Additionally, senior management needs to avoid the scenario of project manager’s 9
trying to satisfy waterfall and agile requirements simultaneously. 10
This study will help guide new and existing project managers to better understand the various 11
aspects and boundaries of their new roles on agile projects and enable them to better facilitate self-12
organizing teams. Our classification of the approaches (hard, moderate, and soft) to performing 13
the everyday activities will help managers to implement a behavioral pattern depending on the 14
context. Our statistical data also provides project managers with tips on which agile practices are 15
likely to benefit from their presence and which practices are best handed over to the team. 16
Gradually withdrawing from controlling agile practices will help the team become self-organizing 17
by putting trust in the team’s ability to take decisions. Another more concrete implication is that 18
our findings can be used to create a job description for the agile project manager. For example, the 19
person specification in the job description could read as follows: 20
“We are looking for versatile and adaptable Project Manager (PM) with strong facilitation skills. 21
The PM should be the grease that drives the team machine as it sets new benchmarks in quality 22
and delivery while staying true to agile principles. The PM needs to be a mentor to whom team 23
members can look upto, a great wall behind whom the team can carry on their work uninterrupted, 24
a lithe negotiator who can negotiate the best deal for the company and the team, and a master 25
coordinator who can juggle often conflicting requirements with ease”. 26
The above job description is quite rudimentary but it does give an idea of the ways in which the 27
findings of this study can be used by practitioners. 28
29

34
6 Related Work 1
Different roles in ASD (such as product owner, scrum master, the customer and the team) have 2
been studied to varying extents in the past few years. Researchers have identified different 3
activities carried out by the scrum master [19], [69]. The role of the product owner has also been 4
in the spotlight and researchers have investigated the role in the industry vis-à-vis the theoretical 5
definition [24], [67], [70], [71], [72], and [73]. The team in ASD projects has been studied from 6
the viewpoint of self-organization [18], [6], the transition to self-organization [56], project 7
management challenges from the perspective of the self-organizing team [74], and the effect of 8
customer collaboration [52]. 9
However, there is a scarcity of prior empirical work dealing decisively with the role of the project 10
manager in agile projects. Existing literature has focused on understanding the reasons behind 11
project managers’ preferences in agile contexts [20], the effect of agile adoption on the working 12
styles of the project manager [21], and the project manager’s perspective on conflicts in agile teams 13
[13]. 14
Our finding of the project manager’s dual role as the scrum master supports a recent study on the 15
role of scrum masters that reported a high frequency of project manager acting as the scrum master 16
[19]. The project manager acting as the customer proxy was observed by Taylor [21] but we did 17
not find evidence of this in our study. 18
Interestingly, one research area which corroborates some of our findings is recent research on 19
scaled agile [60], [61], [63], [64], [65], and [68]. As mentioned in section 2.5, intra-team 20
coordination is one aspect of scaled agile which has received attention from researchers. One of 21
the key challenges identified by Dikert et al [68] in extant literature was that of multiple team 22
coordination, where traditional and agile methods existed side by side. Another challenge, in our 23
view linked to the coordination one, identified by Dikert et al [68] was the conflict between the 24
need for additional management positions to manage the scaling-up with the need to encourage 25
self-organization. One of the studies included by Dikert et al [68] in their SLR has noted the need 26
for project managers to act as change agents. Our activity of coordination, carried out by the project 27
manager using the moderate approach, reflects the project manager’s approach slowly undergoing 28
a metamorphosis into a more agile approach. 29

35
Another finding from our study is that the project manager possibly had a high level of influence 1
on the scrum of scrums meeting (see section 4.1). Gustavsson [63] looked at the manner in which 2
coordination routines such as the scrum of scrums are enacted and the reasons they are enacted in 3
a particular manner. Gustavsson [63] found that the scrum of scrums was tailored by organizations 4
to suit their project context. This could involve varying the frequency of meetings or throwing 5
open participation to a wider section of stakeholders. Our study also suggests that the high level 6
of influence of the project manager on Scrum-of-Scrum (SOS) meetings could be due to the project 7
manager coordinating multiple teams. 8
Paasivaara and Lassenius [62] reported that one of the ways in which large firms such as Ericsson 9
dealt with coordination challenges over large multi-team projects was to facilitate community 10
based decision making by setting up communities of practice (COP’s). In this scenario the teams 11
followed a democratic decision making process and even product owners had very limited say in 12
this process. One of the key characteristics of the COP identified was the presence of facilitator 13
who kept the teams on track [62]. A similar approach was reported at Spotify by Šmite et al [61], 14
who identified Spotify’s culture of guilds as one of the mechanisms for facilitating “lightweight 15
coordination” across regions. In both the studies neither Ericsson nor Spotify had any project 16
managers. However, our findings suggest that in project where the project manager is present, he 17
or she is involved in performing facilitation activities. 18
Conboy and Carroll [64], based on their long running research on adoption and sustenance of agile 19
frameworks, identified nine challenges associated with adopting large scale agile frameworks. 20
These challenges included foundational issues such as developing a definition of large scale agile 21
appropriate to the organizational context and maintaining the spirit of self-organization when 22
undertaking the transformation. Researchers have also studied the role of the product owner in 23
large scale agile [67] and reported on the creation of product owner teams. The members of these 24
teams undertook a range of activities including communication and risk assessment. 25
Team autonomy is another area of large scale agile that has been touched upon by researchers [65]. 26
The key challenges the researchers reported were that of goals being set without the involvement 27
of the teams and interference in the teams work due to external dependencies. Our activity of 28
protecting performed by the project manager with its attendant hard approach is a possible solution 29
to the above mentioned challenge. 30

36
The focus of all the studies mentioned above is on a particular aspect of agile or the project 1
manager’s perspective on issues which affect the team and the project in ASD. None of the above-2
mentioned studies have explored the project manager’s day-to-day role and responsibilities. Our 3
study fills this critical research gap. 4
7 Limitations 5
A Grounded Theory study generates a “mid-ranged” theory that is limited to the contexts studied 6
and remains open to modification based on new data to suit new contexts [48]. Our participants 7
represent a wide range of project sectors, ranging from telecommunications and banking, to 8
government, tourism and retail. Through theoretical sampling, we managed to include a variety of 9
roles such as developers, solutions architects, and test engineers in addition to various management 10
roles to provide multiple perspectives. Our theory is open to modification and extension based on 11
future research work in different contexts. 12
In using a mixed data Grounded Theory method, we have made use of a pre-interview 13
questionnaire which provided quantitative data while the subsequent interviews provided 14
qualitative data. The modest sample size of the quantitative data (N=57) is supplemented with a 15
decent sample size of qualitative data (over 45 hours of interviews with 39 participants). 16
To ensure the reliability of the data and to prevent mixing up of participant experiences from 17
different projects, these were carefully coded (as explained in the section on research 18
methodology). The responses to the questionnaire were kept at hand during the interview process 19
and any contradictions (for example, regarding project details) were clarified with the participants 20
directly. 21
In a Grounded Theory study, the verifiability of the theory generated can be assessed by the rigor 22
of the research method and evidence that the theory has emerged from the collected data [48], [49]. 23
To ensure verifiability and to keep our coding procedures as transparent as possible, we have 24
provided explanations of our coding procedures and the process of derivation of concepts and 25
categories in the research methodology section. 26
One of the key limitations of the quantitative study is that it looked at a limited set of variables. 27
Given the exploratory nature of the study, variables were limited to those that emerged as 28
significant across the participant base. Factors such as size of project and whether it is a multi-29

37
team project were not factored into the analysis or the questionnaire. The above factors can 1
influence whether management decides to utilize the project manager to coordinate multiple 2
project teams and even dictate the level of involvement of the project manager in practices such as 3
scrum of scrums. These aspects can be explored in more structured studies in the future. 4
The possibility of sampling and response bias in quantitative data collection was minimized by 5
adopting targeted strategies to minimize bias. To reduce the likelihood of sampling bias we 6
recruited not only project managers, but a diverse sample of participants such as developers, 7
testers, product owners, and scrum masters in addition to Project Managers. 8
Response bias was minimized in a majority of cases by verifying the completed pre-interview 9
questionnaire with the interview participants during the interview. As with most such studies, 10
response bias in terms of not being able to include those who did not wish to participant in the 11
study remains. 12
8 Conclusion 13
In this paper we have presented the role of the project manager in ASD projects. The findings are 14
based on interviews with 39 agile practitioners and the pre-interview questionnaire with 57 15
respondents. 16
The key contribution of this study is the mixed data Grounded Theory of the role of the project 17
manager. We have presented the theory in terms of the dimensions of the project manager’s role 18
in agile projects. One of the dimensions is the project manager performing activities such as 19
facilitating, mentoring, negotiating, coordinating, and protecting. Some of these activities fall in 20
the domain of the scrum master as per classic agile literature [5], [17]. We observed this unique 21
arrangement reported by nearly one-fifth of our participants. 22
Another closely related dimension is that of the project manager adopting a hard, moderate, or soft 23
management approach depending on the activity performed by the project manager. As illustrated 24
in Fig.3, the project managers applied all three management approaches to mentoring. While in 25
the case of coordinating, the project manager’s approach was moderate. The nature of negotiations 26
meant that the project managers’ approach was between moderate and hard approaches. Their 27
approach to facilitating was also between moderate and hard. To protect the team from external 28
disruptions project managers adopted the hard approach. The management approach used was 29
partly influenced by different factors such as: the project manager also playing the scrum master 30

38
role; the project manager being an enthusiastic early adopter of agile; and the team was 1
transitioning to agile. The project manager while carrying out the activities also carried out 2
traditional duties such as project tracking, project reporting, budgeting & forecasting, and 3
personnel management. Thus, our findings suggest that the project manager’s role is needed in 4
performing non-agile activities which are essential within an organizational framework. 5
Additionally, the phenomenon of the project manager acting as the scrum master suggests that this 6
arrangement is transitory till the time the organization can implement agile. 7
Additionally, the pre-interview survey data provides evidence that the project manager’s presence 8
on an agile project can possibly influence the frequency with which agile practices are carried out 9
by the team. The agile practices which exhibited the greatest increase in their frequency of use in 10
the presence of a project manager included scrum of scrums meeting, project velocity 11
measurement, and release planning. Practices such as sprint planning, definition of done, and user 12
stories saw a marked negative trend when the project manager was present. This aspect in 13
particular merits further investigation. 14
Our findings show that the role of the project manager in agile projects involves performing 15
everyday activities such as facilitating and mentoring, using hard, moderate, and soft management 16
approaches, while retaining some the traditional project management duties such as tracking 17
project progress and budgeting. Understanding the role of the project manager in agile projects 18
will help practitioners better manage expectations of this role and ease their agile transitions. 19
Acknowledgment 20
We would like to thank the participants of this research and the University of Auckland Ethics 21
Committee. 22
23
References 24
[1] Project Managerment Institute, A guide to the project management body of knowledge, 6th 25
Edition. Newtown Square, PA: PMI, 2018. 26
[2] N. Pettersen, "What do we know about the effective project manager?," Int. J. of Project 27
Manage., vol. 9, no. 2, pp. 99-104, 1991. 28

39
[3] W. W. Royce, "Managing the development of large software systems," in Proc. of IEEE 1
WESCON, vol. 26: Los Angeles, 1987. 2
[4] H.D. Benington, “Production of large computer programs”,in Proc. of the 9th Int. Conf. on 3
Software Eng.,Monterey, CA, March 30-April 2, 1987,pp. 299-310. 4
[5] J. A. Highsmith, Agile project management : creating innovative products. Boston: Addison-5
Wesley, 2004. 6
[6] R. Hoda, J. Noble, and S. Marshall, "Self-organizing roles on agile software development 7
teams," IEEE Trans. on Software Eng., vol. 39, no. 3, pp. 422-444, 2013. 8
[7] A. Cockburn and J. Highsmith, "Agile software development, the people factor," Comput., 9
vol. 34, no. 11, pp. 131-133, 2001. 10
[8] T. Chow and D.-B. Cao, "A survey study of critical success factors in agile software projects," 11
J. of Syst. and Software, vol. 81, no. 6, pp. 961-971, 2008. 12
[9] L. Chagas, D. de Carvalho, A. Lima, and C. Reis, "Systematic literature review on the 13
characteristics of agile project management in the context of maturity models," in Int. Conf. of 14
Software Process Improvement and Capability Determination, 2014, pp. 177-189. 15
[10] K. Schwaber and M. Beedle, Agile software development with scrum. Upper Saddle River, NJ: 16
Prentice-Hall, 2002. 17
[11] K. Beck and C. Andres, Extreme programming explained : embrace change. Boston, MA : 18
Addison-Wesley, 2005. 19
[12] Y. Shastri, R. Hoda, and R. Amor, "Does the Project Manager Still Exist in Agile Software 20
Development Projects?, in 23rd Asia-Pacific Software Eng. Conf., Hamilton,2016, pp. 57-64. 21
[13] L. Siddique and B. A. Hussein, "Grounded theory study of conflicts in norwegian agile 22
software projects: the project managers' perspective," J.of Eng., Project, and Prod. Manage., 23
vol. 6, no. 2, pp.120-135, 2016. 24

40
[14] Digital.ai Software Inc. (2020). VersionOne 14th Annual State of Agile Report. Digital.ai 1
Software Incorporated. [Online]. Available: https://stateofagile.com/#ufh-i-615706098-14th-2
annual-state-of-agile-report/7027494 3
[15] M. Fowler and J. Highsmith, The agile manifesto, Software Develop. Vol.9, no.8, pp. 28–35, 4
1991. 5
[16] G. B. P.Deemer, C.Larman,and B.Vodde. (2012). The Scrum Primer. [Online]. Available: 6
http://scrumprimer.org/ 7
[17] J. Sutherland and K. Schwaber.(2017). The scrum guide: the definitive guide to scrum. 8
Scrumguides.org.[Online].Available: 9
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-10
US.pdf#zoom=100 11
[18] R. Hoda, J. Noble, and S. Marshall, "Developing a grounded theory to explain the practices of 12
self-organizing Agile teams," Empirical Software Eng., vol. 17, no. 6, pp. 609-639,2012. 13
[19] J.Noll, MA Razzak, JM Bass, and S.Beecham, “A study of the Scrum Master’s role”, in Int. 14
Conf. on Product-Focused Software Process Improvement,Innsbruck, 2017, pp. 307-323. 15
[20] D. Bishop, P. Rowland, and C. Noteboom, "Antecedents of Preference for Agile Methods: A 16
Project Manager Perspective," in Proc. of the 51st Hawaii Int. Conf. on System Sciences, 2018. 17
[21] K.J Taylor, "Adopting agile software development: the project manager experience," Inform. 18
Technology & People, vol. 29, no. 4, pp. 670-687, 2016. 19
[22] M. L. Drury-Grogan and O. O'dwyer, "An investigation of the decision-making process in 20
agile teams," Int. J. of Inform. Technology & Decision Making, vol. 12, no. 06, pp. 1097-1120, 21
2013. 22
[23] Project Management Institute, Agile practice guide.1st Edition. Newtown Square, Pennsylvania 23
: PMI, 2017. 24
[24] J. M. Bass, "Agile method tailoring in distributed enterprises: Product owner teams," in IEEE 25
8th Int. Conf. on Global Software Eng., Bari, 2013, pp. 154-163. 26

41
[25] R. B. Rowen, "Software project management under incomplete and ambiguous specifications," 1
IEEE Trans. on Eng. Manage., vol. 37, no. 1, pp. 10-21, 1990. 2
[26] B. Boehm, "A view of 20th and 21st century software engineering," in Proc. of the 28th Int. 3
Conf. on Software Eng., Shanghai, 2006, pp.12-29. 4
[27] D. Robey, R. Welke, and D. Turk, "Traditional, iterative, and component-based development: 5
A social analysis of software development paradigms," Inform. Tech. and Manage., vol. 2, no. 6
1, pp. 53-70, 2001. 7
[28] B. W. Boehm, "A spiral model of software development and enhancement," Comp., vol. 21, 8
no. 5, pp. 61-72, 1988. 9
[29] B. W. Boehm and R. Ross, "Theory-W software project management principles and 10
examples," IEEE Trans. on Software Eng., vol. 15, no. 7, pp. 902-916, 1989. 11
[30] P. O. Gaddis, "The project manager," Harvard Bus. Review, vol. 37, no. 3, pp. 89-97, 1959. 12
[31] C. Bredillet, S. Tywoniak, and R. Dwivedula, "What is a good project manager? An 13
Aristotelian perspective," Inter. J. of Project Manage., vol. 33, no. 2, pp. 254-266, 2015. 14
[32] D. H. Stevenson and J. A. Starkweather, "PM critical competency index: IT execs prefer soft 15
skills," Inter. J. of Project Manage., vol. 28, no. 7, pp. 663-671, 2010. 16
[33] R. Müller and J. R. Turner, "Matching the project manager’s leadership style to project type," 17
Inter. J. of Project Manage., vol. 25, no. 1, pp. 21-32, 2007. 18
[34] P. W. Morris, L. Crawford, D. Hodgson, M. M. Shepherd, and J. Thomas, "Exploring the role 19
of formal bodies of knowledge in defining a profession–The case of project management," 20
Inter. J. of Project Manage., vol. 24, no. 8, pp. 710-721, 2006. 21
[35] J. K. Pinto and G. Winch, "The unsettling of “settled science:” The past and future of the 22
management of projects," Inter. J. of Project Manage., vol. 34, no. 2, pp. 237-245, 2016. 23
[36] S. Cicmil and D. Hodgson, "New possibilities for project management theory," Project 24
Manage. J., vol. 37, no. 3, pp.111-122, 2006. 25

42
[37] S. Cicmil, T. Williams, J. Thomas, and D. Hodgson, "Rethinking project management: 1
researching the actuality of projects," Inter. J. of Project Manage, vol. 24, no. 8, pp. 675-686, 2
2006. 3
[38] P. W. Morris, The management of projects. Thomas Telford, 1997. 4
[39] S. Loufrani-Fedida and S. Missonier, "The project manager cannot be a hero anymore! 5
Understanding critical competencies in project-based organizations from a multilevel 6
approach," Inter. J. of Project Manage., vol. 33, no. 6, pp. 1220-1235, 2015. 7
[40] D. E. Hodgson and S. Paton, "Understanding the professional project manager: Cosmopolitans, 8
locals and identity work," Inter. J. of Project Manage., vol. 34, no. 2, pp. 352-364, 2016. 9
[41] J. Stapleton, DSDM : business focussed development. Boston: Addison-Wesley, 2003. 10
[42] S. R. Palmer and M. Felsing, A practical guide to feature-driven development. Pearson 11
Education, 2001. 12
[43] C. Larman and V. R. Basili, "Iterative and incremental development: A brief history," Comput., 13
vol. 36, no. 6, pp. 47-56, 2003. 14
[44] VersionOne Inc. (2018). The 12th Annual State of Agile Report. VersionOne Incorporated. 15
[Online]. Available: https://explore.versionone.com/state-of-agile/versionone-12th-annual-16
state-of-agile-report 17
[45] M. Pikkarainen, J. Haikara, O. Salo, P. Abrahamsson, and J. Still, "The impact of agile 18
practices on communication in software development," Empirical Software Eng., vol. 13, no. 19
3, pp. 303-337, 2008. 20
[46] Y. Shastri, R. Hoda, and R. Amor, "Understanding the Roles of the Manager in Agile Project 21
Management," in Proc. of the 10th Innovations in Software Eng. Conf., Jaipur, 2017, pp.45-22
55. 23
[47] S. Nkukwana and N. H. D. Terblanche, "Between a rock and a hard place: Management and 24
implementation teams’ expectations of project managers in an agile information systems 25
delivery environment," South African J. of Inform. Manage.,vol.19, no.1, 2017. 26

43
[48] B. G. Glaser, Basics of grounded theory analysis. Mill Valley, Calif.: Sociology Press, 1992. 1
[49] B.G.Glaser and J. Holton, “Remodeling grounded theory”, Forum: Qualitative Social 2
Research, vol. 5, no. 2, pp.47-68, 2004. 3
[50] K. Charmaz, Constructing grounded theory, Thousand Oaks, CA: Sage Publications Ltd., 4
2006. 5
[51] K.-J. Stol, P. Ralph, and B. Fitzgerald, "Grounded theory in software engineering research: a 6
critical review and guidelines," in Proc. of the 38th Int. Conf. on Software Eng., Austin, 2016, 7
pp.120-131. 8
[52] R. Hoda, J. Noble, and S. Marshall, "The impact of inadequate customer collaboration on self-9
organizing Agile teams," Inform.and Software Technology, vol. 53, no. 5, pp. 521-534, 2011. 10
[53] V. Stray, D. I. K. Sjøberg, and T. Dybå, "The daily stand-up meeting: A grounded theory 11
study," J. of Syst. and Software, vol. 114, pp. 101-124, 2016. 12
[54] T. Dybå and T. Dingsøyr, "Empirical studies of agile software development: A systematic 13
review," Inform. and Software Technology, vol. 50, no. 9-10, pp. 833-859, 2008. 14
[55] Project Management Institute. (2017). Annual report 2017. [Online]. Available: 15
https://www.pmi.org/annual-report-2017/at-a-glance 16
[56] R. Hoda, & J. Noble, “Becoming agile: a grounded theory of agile transitions in practice.” In 17
Proc. of the 39th Int. Conf. on Software Eng., Argentina, 2017, pp. 141-151. 18
[57] M. Waterman, J. Noble, & G. Allan, “How much up-front?: a grounded theory of agile 19
architecture.” In Proc. of the 37th Int. Conf. on Software Eng., Florence, 2015, pp. 347-357. 20
[58] B. G. Glaser, Theoretical sensitivity : advances in the methodology of grounded theory. Mill 21
Valley, Calif. : Sociology Press, 1978. 22
[59] M. Tavakol and R. Dennick, "Making sense of Cronbach's alpha," Int. J. Med. Educ., vol. 2, 23
pp. 53-55, Jun 27 2011. 24

44
[60] Scheerer, A., Hildenbrand, T., & Kude, T. (2014, January). Coordination in large-scale agile 1
software development: A multiteam systems perspective. In 2014 47th Hawaii international 2
conference on system sciences (pp. 4780-4788). IEEE. 3
[61] Smite, D., Moe, N. B., Levinta, G., & Floryan, M. (2019). Spotify guilds: how to succeed with 4
knowledge sharing in large-scale agile organizations. IEEE Software, 36(2), 51-57. 5
[62] Paasivaara, M., & Lassenius, C. (2019). Empower Your Agile Organization: Community-6
Based Decision Making in Large-Scale Agile Development at Ericsson. IEEE Software, 36(2), 7
64-69. 8
[63] Gustavsson, T. (2019). Dynamics Of Inter-Team Coordination Routines in Large-Scale Agile 9
Software Development. Dynamics, 5, 15-2019. 10
[64] Conboy, K., & Carroll, N. (2019). Implementing large-scale agile frameworks: challenges and 11
recommendations. IEEE Software, 36(2), 44-50. 12
[65] Moe, N. B., Dahl, B., Stray, V., Karlsen, L. S., & Schjødt-Osmo, S. (2019, January). Team 13
autonomy in large-scale agile. In Proceedings of the 52nd Hawaii International Conference on 14
System Sciences. 15
[66] Dingsøyr, T., & Moe, N. B. (2013). Research challenges in large-scale agile software 16
development. ACM SIGSOFT Software Engineering Notes, 38(5), 38-39. 17
[67] Bass, J. M., & Haxby, A. (2019). Tailoring product ownership in large-scale agile projects: 18
managing scale, distance, and governance. IEEE Software, 36(2), 58-63. 19
[68] Dikert, K., Paasivaara, M., & Lassenius, C. (2016). Challenges and success factors for large-20
scale agile transformations: A systematic literature review. Journal of Systems and 21
Software, 119, 87-108. 22
23
[69] Bass JM, "Scrum Master Activities: Process Tailoring in Large Enterprise Projects," in 2014 24
IEEE 9th International Conference on Global Software Engineering, 2014, pp. 6-15. 25
[70] Bass JM, S. Beecham, J. Noll, and M. A. Razzak, "All Hands to the Pumps: The Product Owner 26
Role in Small Companies Lero Technical Report: 2017", 2016. 27

45
[71] Kristinsdottir S, M. Larusdottir, and Å. Cajander, "Responsibilities and Challenges of Product 1
Owners at Spotify-An Exploratory Case Study," in Human-Centered and Error-Resilient 2
Systems Development: Springer, 2016, pp. 3-16. 3
[72] Oomen S, B. De Waal, A. Albertin, and P. Ravesteyn, "How Can Scrum Be Succesful? 4
Competences of the Scrum Product Owner", In Proceedings of the 25th European Conference 5
on Information Systems (ECIS), Guimarães, Portugal, June 5-10, 2017. 6
[73] Sverrisdottir HS, H. T. Ingason, and H. I. Jonasson, "The role of the product owner in scrum-7
comparison between theory and practices," Procedia-Social and Behavioral Sciences, vol. 119, 8
pp. 257-267, 2014. 9
[74] Hoda R and Murugesan LK, "Multi-level agile project management challenges: A self-10
organizing team perspective," Journal of Systems and Software, vol. 117, pp. 245-257, 2016. 11
[75] VersionOne Inc. (2019). The 13th Annual State of Agile Report. VersionOne Incorporated. 12
[Online]. Available: https:// https://stateofagile.com/#ufh-i-613553418-13th-annual-state-of-13
agile-report/7027494 14
[76] Shastri Y, Hoda R, Amor R (2020) “Survey of roles in agile project management and their 15
involvement in agile practices”. https://doi.org/10.7910/DVN/QEASRH, Harvard Dataverse, 16
V1. 17
18
19
20

Author Biography
Author 1: Yogeshwar Y. Shastri completed his PhD degree from the department of
Electrical, Software and Computer Engineering at The University of Auckland, New
Zealand. He received his Master’s degree from the University of Sheffield, UK and his
Bachelor’s degree from Amravati University, India. Email address:
ysha962@aucklanduni.ac.nz; Tel.: +64 210 850 7449.
Author 2: Rashina Hoda, PhD (Victoria University of Wellington), B.Sc. Hons (Louisiana
State University), is an Associate Dean (Academic Workforce) and an Associate Professor
in software engineering at the Faculty of Information Technology at Monash University.
Her research focuses on human-centred software engineering, agile software development,
and grounded theory. Rashina received a distinguished paper award at ICSE2017 and a
distinguished reviewer award at ICSE2020. She serves on the IEEE Transactions on
Software Engineering reviewer board and IEEE Software advisory panel, as associate
editor for the Journal of Systems and Software and on the program and organising committees for ICSE and XP
conferences. Rashina is currently writing a book on Grounded Theory for Software Engineering. For more
information please visit: www.rashina.com.
Author 3: Prof. Robert Amor, School of Computer Science, University of Auckland, New
Zealand. Robert Amor received his BSc (Hons) and MSc degrees from Victoria University of
Wellington, New Zealand. After receiving his PhD from the University of Auckland, New
Zealand he spent five years working at the Centre for Construction IT at the BRE in the UK.
He is currently in the School of Computer Science at the University of Auckland and a
professor in that department. Prof Amor undertakes research in the field of Construction
Informatics. Achieving interoperability is his core research interest and to achieve this he
investigates integrated environments which covers information modelling (e.g., BIM), process
modelling, user interaction, implementation frameworks, information mapping, and
communication strategies. Since 2003 he has coordinated the working group W78 (IT for Construction) for the
International Council for Research and Innovation in Building and Construction. He is also Editor-in-Chief of the
Journal of Information Technology in Construction.