Keywords

1 Introduction

While the adoption of agile project management methodologies is widespread [1], the project management tasks in agile projects are uncertain, and this lack of clarity causes confusion in practice [2,3,4]. Agile methodologies provide events, processes, and artifacts that should allow projects to be flexible to change and deliver results in an iterative, incremental fashion. Some of the most popular agile project management frameworks—such as scrum, extreme programming (XP), and lean/Kanban processes—do not explicitly include a project manager role or project management tasks. For example, scrum includes three roles: a scrum master, product owner, and the team [5].

Shastri, Hoda, and Amor [6] found that the project manager, by all means, still exists in agile projects; however, their study left open the questions as to what activities the project manager performs. “The implementation of agile methods can have a very significant impact on the role of the project manager, but a better understanding of the circumstances under which the project manager role changes and how it changes is needed” [4, p. 11]. Even the Agile Practice Guide issued by the Project Management Institute (PMI) in 2017 states that the “role of the Project Manager in an agile project is somewhat unknown” [7, p. 37].

Several research articles start with the premise that there is an agile project manager, who is a facilitator or coach [8,9,10,11]. Noll, Razzak, Bass, and Beecham [2], however, found that tension was created when the scrum master, a coaching role in scrum, was expected to perform the project management tasks and coach the team. In addition, the boundary between the role of the project manager and that of the team is blurred and leads to difficulty at the team level [3, 12]. There is some speculation that the project manager is better suited to assume the product owner role [2] than the agile coach. This option, however, is not transparent in the methodology description [5, 13] and has not been addressed in the literature. While other studies have investigated agility in projects or the effects of specific practices on the success of projects applying agile methodologies [1, 14, 15], they have not clarified the project management activities.

The success rate for projects using agile methodologies is on a par with, if not better than, the success rate for projects managed under a traditional methodology [1]. In agile methodologies, some but not all of the typical project management responsibilities have been assigned to other roles [11]. Thus, if agile methodologies are followed rigorously and exclude a project manager, then the project manager role and some project management tasks may be obsolete. The literature provides conflicting information on the role of the project manager in agile projects, and it is limited in explaining how the other project roles are engaged in the project management activities. Thus, the question of who performs what project management activities in agile projects remains unanswered. Therefore, this study addresses the questions of how are traditional project managers engaged in agile projects and who executes what project management tasks in projects applying agile methodologies?

First, we performed a literature review to penetrate project management and the role of the project manager in project work under agile methodologies. We mapped the project management tasks under an agile methodology to the project management knowledge areas and processes from the International Organization for Standardization (ISO) project management standards. Next, we defined and conducted a survey to ascertain which project roles perform which project management tasks. Finally, we quantitatively analyzed the survey results using a case-controlled match analysis to answer the research questions.

The results from this study quantify subjective and theoretical speculation on who performs the project management tasks in agile projects. By providing a framework for the project management activities and the project manager’s role in agile projects, the results contribute to the project management literature on agile methodologies.

The next section reviews the literature. Section 3 describes the research methodology. Section 4 presents the data analysis and results. Section 5 provides a discussion of the results. The final section of this paper discusses the conclusions and implications.

2 Literature Review

2.1 Traditional Project Management Methodologies

“A project is a temporary organization to which [human, material, or financial] resources are assigned to do work to bring about beneficial change” [16, p. 1], and “project management is the means by which the work of the resources assigned to the temporary organization is managed and controlled to deliver the beneficial change desired by the owner” [17, p. 93]. Project management lifecycles, activities, and roles are codified in project management methodologies. The traditional, waterfall and plan-driven methodologies are lifecycles that follow a stage-gate or phased lifecycle. These methods have in common the creation of an upfront plan, where the time is limited, with the limitation and termination conditions known from the beginning [18]. The methodologies and frameworks for traditional projects are codified in the project management standards and frameworks, such as “ISO 21500:2012, Guidance on Project Management” [19], APM Body of Knowledge 6th Edition [20], and A Guide to the Project Management Body of Knowledge (PMBOK guide) [21]. There is a positive relationship between the use of a project management methodology and project success. This is the case if the methodologies are comprehensive—including tools, techniques, process capability profiles, and knowledge areas—or if they need to be supplemented with some elements [22].

2.2 Agile Project Management Methodologies

The Agile Manifesto is a set of four values and 13 principles that provide a framework for managing technology projects in a flexible way that responds to dynamic project situations [1, 23, 24]. The principles and values from the Agile Manifesto offer a framework on how people should work [24]. Consequently, the manifesto does not explicitly establish who should do the work. Several methodologies or frameworks can be considered to follow the values and principles described in the Agile Manifesto. Each agile methodology has its own set of rules, events, and practices; however, in general, they all encourage iterative and incremental development lifecycles, self-organizing teams, and evolutionary product development. Scrum, XP, lean, and Kanban are the most frequently referenced agile methodologies in surveys on agile adoption and in the project management literature [6].

2.3 Project Manager

The project manager is the authorized person who leads and manages project activities and is accountable for project completion [25]. The role is defined in ISO, Association for Project Management (APM), and PMI project management standards and frameworks. In addition, the standards describe subject areas in which a project manager is expected to be knowledgeable and processes that should be led or executed as part of managing a project. The project management literature agrees that the project manager has sole responsibility for planning and managing projects [25]. The project manager should direct the performance of the planned project activities and manage the various technical, administrative, and organizational interfaces within the project [19, 21].

The project manager role is not explicit in the agile methodology. Noll, Razzak, Bass, and Beecham [2] found that the scrum master, a coaching role in the scrum agile methodology, in practice combines project management activities with coaching; however, tension is created, since the scrum master is expected to balance management activities with coaching the team. The inherent suggestion in studies on project managers in agile projects is that the leadership style or skills, knowledge, personal attributes, and behavior of the project manager must be adapted [10, 11, 26, 27].

2.4 Project Management Tasks

In the ISO project management standards, 39 processes in 10 subject areas that cover five process groups are described for the project management role [19, 24]. The project management tasks in plan-driven methodologies are centralized to the project manager role.

In agile methodologies, some of the project management responsibilities are inherent in the methods, while other project management activities or tasks are not explicitly identified. Studies on project managers in agile projects have identified conflicts with other agile roles or assumed that project managers must adapt to manage agile projects [3, 5, 12, 13]. Binder, Aillaud, and Schilli [24] correlated the 12 agile principles to the ISO processes to establish a hybrid model for managing agile projects. They identified gaps and practice modifications that would need to occur to enable effective management of agile projects [3, 12]; however, they did not take a position on who performs the tasks. Shastri, Hoda, and Amor [28] describe the activities for an agile project manager from the project manager’s perspective without considering how other roles or the method assumes some of the project management responsibilities.

2.5 Summary

The project management tasks in plan-driven methodologies are centralized to the project manager role. In agile methodologies, some of the project management responsibilities are inherent in the methodological processes, while other project management activities or tasks are not explicitly identified. Research suggests that project managers are engaged in agile projects; however, the engagement of project managers engenders conflict and confusion. We could not identify any studies that show a view of project management tasks across all roles within an agile project. This deficiency in the literature means there is no clear guidance for project sponsors on the management of agile projects.

2.6 Research Questions

The goal of this research was to define a framework for project management tasks in agile projects. Therefore, this study addresses the questions of how are traditional project managers engaged in agile projects and who executes what project management tasks in projects applying agile methodologies?

To answer the research questions, we needed to investigate projects for the engagement and interaction of the methods and project roles in project management tasks. We used a mixed-method methodology, including a qualitative assignment of project roles to project management tasks, a quantitative study using a survey instrument to identify field practices, and a matching study to analyze the results.

3 Research Methodology

We performed a literature review to define the project management boundaries, authority, tasks, and roles in projects using agile methodologies. Next, we used quantitative analysis to determine how the project management tasks are practiced in agile projects. Finally, based on the case-controlled match analysis, we defined the project management task framework.

3.1 Theoretical Framework

We used the boundary, authority, role, and task (BART) system to investigate and define the project management task framework for agile projects. The BART system is used in Tavistock or in group relations and conferences as a method of individual learning through experience and reflection [29, 30]. Psychoanalyst Wilfred R. Bion developed the theory that an individual should be studied as a member of the group to which he or she belongs [29]. Bion’s seminal work and experiments lead to viewing a group as a collective entity. Given that the objective was to study the project management roles and activities within a temporary organization of group work, we identified the BART system as an effective framework for investigating the project management roles and responsibilities in projects.

The components of the BART system are as follows. The boundary is the container for group work, and it must be clearly specified, agreed upon, and adhered to [30]. Authority is the right to complete work. It assumes there is responsibility for activities and accountability for actions [30]. Authority should be clearly defined by the granter and should be understood, acted upon, and empowered with the right tools by the receiver [30]. The formal authority may be given to the group or body through delegation of responsibilities by the granter. The personal authority, or the way an individual assumes formal authority, may exert influence by inhibiting or exaggerating the execution of the authority. There are formal and informal roles. The formal role defines the duties, parameters, people and processes for interaction, and the outcomes or deliverables that define the performance expectations [30]. Formal roles are usually defined by written descriptions, such as job descriptions or contracts. Informal roles are defined when people fill gaps in authority and are assumed implicitly. The tasks are the work to be completed and include activities to support the mission of the group, activities to enable the group to survive as a group, and activities to manage the collective activities of the group [30].

3.2 Mapping Tasks and Roles

First, to identify project managers’ activities in agile projects, we evaluated peer-reviewed journal publications from 2006 to 2018. Given the lack of literature in this area, we created a task construct. We mapped the 10 project management knowledge areas and 39 processes from the “ISO 21500:2012, Guidance on Project Management” [19] standard to the agile principles according to the correlation matrix from [24] and to the scrum roles, artifacts, and events according to [5]. We chose the scrum methodology, as it is the most popular agile methodology in practice [6]. The areas without a mapping represented the gaps between processes in the ISO project management standards and those suggested by the agile principle and scrum. The gaps included processes in the stakeholder, cost, risk, procurement, and communications subject areas. Where there were gaps for the project management tasks, we developed measurement items. Thus, we used a web-based survey to request information on who performs these tasks in agile projects.

3.3 Survey

Second, we used a web-based survey to collect data on the roles engaged in projects and the project management tasks they perform. To explore the difference between the theoretical and practical applications of project management tasks, we employed a quantitative analysis method.

The population for the survey was comprised of project sponsors, project managers, and project team members who had executed agile and non-agile projects in the past 10 years. The number of potential projects is unknowable. Nevertheless, we noted that approximately 24,728 people were certified as agile by PMI at the time of the study [31].

We collected data from members of social media agile and project management groups. We sent invitations to complete a web-based questionnaire to social media groups on LinkedIn, Xing, and Twitter. To gather information from as many projects as possible without regard to project methodology, we chose a wide selection of project management and agile groups (e.g., PMI, Scrum Alliance). The membership numbers for the groups are in the hundreds of thousands; however, there is no method to determine how many people saw or read the invitations. It was, therefore, not possible to determine the response rate.

To ensure proper technical functioning, we tested the survey operations using different devices (i.e., PC and iPad). The survey was available over a 10-day period in January 2019. Respondents were asked to provide information on their last project. The respondents were promised confidentiality and anonymity. A total of 120 respondents started and completed the survey. We checked the responses for extreme responses (all zeros, all fives for a five-point Likert scale, or all sevens for seven-point scale). We performed checks to determine whether there were missing data for mandatory fields or all the same values had been selected for the matrix questions. If we had encountered such a situation, we would have classified the associated data as bad data and removed it. We found no bad data. We analyzed the survey data as described in the following sections.

Measurement Instrument.

This paper is concerned with the relationship between the roles in the project and the project management tasks they perform in agile projects; however, the effect of the role on task assignment should be evaluated against a performance criterion. To evaluate the impacts of the task assignment, we selected project efficiency and success. Furthermore, the importance of the task should be judged against a benchmark. In this study, we compared the task executions between agile and non-agile projects.

We used a measurement instrument to collect demographic data, project size attributes, project performance measures, project roles, and responsibility for project management tasks. We created the constructs based on project management literature and standards. Where possible, we used existing constructs. This section describes the survey questions used to collect the data and the derived measurement items.

Project Roles.

To elicit the project roles that were engaged in the project, the following two questions were used. What roles were involved in the project? (Select all that apply, including yours). What was your major role in the project? (Select one). For the analysis, we created five derived measures. We created a binary variable for role combinations as follows: agile coach when agile coach or scrum master was selected; team role when IT members, business members, hardware or software vendors, or others were selected; project sponsor role when investors in or sponsors of the project were selected; program management office role for program managers or members of project/program management; and the project manager role for the project manager. We created an additional variable, full scrum, for the situation where all scrum roles were present: product owner, agile coach, and at least one team member.

Methodologies.

To elicit the methodology used in the project, the following question was used: What methodology or framework most closely describes the one used in the project? In addition, we used the measure to create a derived measure for the methodology type to group the methodologies into agile, mixed, or plan-driven using the following assignment: (1) agile methodologies include scrum, XP, scrum/XP hybrid, Kanban, lean, scaled agile methods (SAFe, LESS, APM, DAD, RAGE, NEXUS, and scrum of scrums), custom hybrid-agile (multiple agile methodologies), and other agile methodologies (Feature-Driven Development, Dynamic Systems Development Method Atern, AgileUP, or others); (2) plan-driven methodologies include waterfall and other plan-driven methodologies (spiral or staged methodologies); and (3) mixed methodologies include iterative and custom hybrid-mixed methodologies (agile and non-agile methodologies).

Tasks.

Who was responsible for performing these tasks? Select one role per task. This was a matrix question used to identify which of the following six roles were responsible for the following 10 tasks:

  • Roles: project sponsor, project manager, agile coach/scrum master, product owner, team, and other; not applicable (N/A) was included as an option.

  • Tasks: establish project team; manage stakeholders; manage project team; control resources; establish budget; control costs; identify risks; assess, treat, and control risks; plan and administer procurements; and select suppliers.

We selected the tasks based upon tasks that were identified in the ISO standards as being applicable to project management but lacked a corresponding definition of a responsible role in the agile principles or scrum methodology. We created a matrix that identified the role that undertook the tasks and verified that the role was also selected as a project role during data entry.

Project Performance.

Following the model used in Serrador and Pinto [1], we created a composite variable for project efficiency. We created the variable as the mean value from responses to the following three questions. How did the project do in meeting the project budget goals? How did the project do in meeting the project time goals? How did the project do in meeting the project scope and requirement goals? Each question was based on a seven-point scale that ranged from under-performing to over-performing. These questions and scales were used in previous project management research [1]. In addition, each question resulted in a measure that we used in the comparative analysis: budget performance, time performance, and requirement performance, respectively. The overall success variable was based upon the following question: How successful was the project overall? (Select one). The question had a five-point scale that was previously used in project management research [1].

Control Data.

Demographic data on the project was used as control data and included the industry of the sponsoring organization and the country of the survey respondent. Similarly, the project attributes included the duration of the project in months and the number of team members. We transformed the control data into scale data for use in the comparative analysis.

Participant Profile.

The survey sample comprised 120 usable responses: 33% of the respondents had a project manager role; 11% were program managers; 9% were from a project management office; 9% were agile coaches or scrum masters; 8% were product owners; 24% were project team members from IT, business, software vendors, or others not in the selection list; and 3% were project sponsors. Less than 2% of the respondents were end-users. The participants had the option of specifying another role. The results seemed to fall into the categories of project management or a specialized team member. The organizations sponsoring the projects were distributed throughout 20 different industries. The participants were relatively evenly distributed across geographic regions: Europe (25%), Asia (19%), Africa (18%), Latin America and the Caribbean (18%), North America (16%), and Oceania (3%). Most of the projects had started within the past five years (81%) and lasted for more than one year (56%). Most of the projects (81%) had fewer than 21 team members.

3.4 Descriptive Statistics

We used SAS® Studio (Release 3.6, basic edition) to perform the statistical analysis, produce the tables and figures, the descriptive statistics, mean rankings, and Wilcoxon scores, and to explore the characteristics, establish the validity and reliability, and explain the relationship between the variables. The descriptive statistics provided insight into the content and structure of the projects, the involvement of the different project roles, and the relationship between the involved roles and the methodology. We used the Wilcoxon test to compare the means of variables between the three types of methodologies (agile, plan-driven, and mixed) and to establish the significance of the comparison. Wilcoxon scores with a p-value of less than 0.05 indicated that there were significant differences between the methodologies in terms of that variable. We conducted a correlation analysis to determine the association between the characteristics of the project, the roles within the project, and the project outcomes. We used the Kendall correlation coefficient to evaluate the strength and direction of the relationships between the variables. We elected to use the Kendall correlation coefficient due to the small sample size.

3.5 Case-Controlled Match Analysis

To evaluate the existence of project management tasks in agile projects, we conducted a case-controlled match analysis, using plan-driven projects as the control group. A case-controlled match analysis pairs cases in a treatment group with cases in a control group based upon a number of individual characteristics. This type of analysis is often used in observational studies to approximate a randomized trial and to reduce bias [32, 33]. For this study, this type of analysis had the advantage of providing a basis to explain the difference between agile and plan-driven projects.

In this study, we used the methodology type (plan-driven or agile) to define the target and control groups. We used a SAS® program from [33] to create a propensity score using multivariate logistic regression. We used the tasks and role assignments as the observational variables for the comparison. There was a 1:1 relationship between the observations, yielding 24 cases in each group. Afterward, the mean rankings and Wilcoxon scores were produced for the analysis. The results provided descriptive information on whether each task was executed in more or fewer agile cases than in plan-driven cases, represented in Table 3 by a plus or minus sign, respectively. A p-value less than 0.05, represented by asterisks in the table, identifies the significance of the difference between the two methodology types.

3.6 Validity and Reliability

We assessed the survey responses for scope, completeness, consistency, ambiguity, missing data, and extreme responses. For external validity, we used the existing constructs (with some modifications) and the literature to develop new constructs. For internal consistency, we conducted a correlation analysis to determine whether the items were significantly related to one another (p < 0.05).

In designing the measurement instrument and collecting the data, we took steps to limit common method bias (CMB). Item characteristic effects and context effects were mitigated by using existing constructs in the literature. Measurement context effects were mitigated by measuring the predictor and criterion at various locations in the measurement instrument. Nevertheless, because self-reports from a single source were used to garner information on the dependent and independent variables and the data were collected at the same point in time, the risk of CMB persisted. The measurements could have been affected by CMB due to respondents attempting to provide consistent responses across a number of variables [34]. We, therefore, performed a post-hoc statistical test to check for CMB: Harman’s single-factor test, which is considered the minimally acceptable test for CMB. To perform Harman’s single-factor test, we analyzed all the independent and dependent variables using unrotated factor analysis. A single factor explained 17.59% of the variance. The premise is that, if there is CMB, “one general factor will account for the majority of the covariance among the measures” [34, p. 889]. That the variance was lower than the heuristic of 50% suggests that CMB was not an issue [34].

The data were collected from multiple social media sites, some of which specialized in project management while others specialized specifically in agile practices. To determine whether there was a significant difference between the groups in terms of their responses, we used the Kruskal-Wallis test (for comparing several conditions from different respondents) to compare the means of the organizational performance variables [35]. There was no significant difference between the two groups (H (2) = 5.7643, p = 0.5675). No bias was uncovered; therefore, the data were reliable and valid.

4 Data Analysis and Results

4.1 Project Efficiency

Table 1 presents the mean comparisons between the methodology types; significant differences are based on the Kruskal-Wallis test scores being less than .05 for 95% confidence. We combined project cost, time, and quality performance into a single project efficiency variable by taking the mean value of the variables. We used Cronbach’s alpha to assess scale reliability; the .658 alpha was judged reliable for this exploratory research. [35]. There was no significant difference between the methodology types in terms of the composite project efficiency measure or the individual performance measures. Unlike in some other research, the mixed and plan-driven methods exhibited higher mean project efficiency than the agile methods [1].

4.2 Methodology

Scrum and waterfall were the most frequently used methodologies, at 22% and 20%, respectively. Of the agile methodologies, scrum combined with scrum/XP was the most widely used, at 24%. This finding is consistent with the results of other studies, which have found scrum to be the most popular agile methodology in widespread use [1, 6]. The methodology types and methodologies were not significantly correlated with any of the individual performance measures or the project efficiency factor. The methodology types were not significantly different in terms of team size or project durations.

Table 1. Comparative analysis with means and Kruskal-Wallis test scores
Full size table

4.3 Roles

The project manager role was involved in 67% of the projects, including 58% of the agile projects, 82% of the mixed methodology projects, and 79% of the plan-driven projects. The agile coach role was included in 35% of all projects, and the product owner role was included in 42% of all projects. There was no significant difference between methodology types in terms of other roles. The agile coach, product owner, and team combination, a full scrum team, was not present in all scrum-related projects. This implies that scrum is not being rigorously applied in practice. The project manager was more prominent in the plan-driven and mixed methodologies, and the agile coach and product owner were more prominent in the agile methodologies. Otherwise, there was no significant difference between the methodology types in terms of the roles. Table 2 illustrates that the presence of the agile coach role was significantly correlated with the time, requirements, and efficiency measures.

4.4 Tasks

Table 3 presents the results of the case-controlled match analysis and provides an overview of the project roles engaged in project management processes. In general, project management tasks were performed in all methodology types with no significant difference. The project manager was overwhelmingly responsible for the project management tasks in all types of methodologies.

Table 2. Kendall Tau-b correlation coefficients
Full size table

Conversely, the team was more often identified as being involved in assessing, treating, and controlling risks in plan-driven methodologies; meanwhile, in agile methodologies, the product owner was more often identified as being involved in these activities. This finding is consistent with Tavares, Silva, and Diniz de Souza [36] finding that in agile projects the artifacts are responsible for recording risks and their responses, the events for identifying, analyzing, and planning risk responses and monitoring risks, the project team for managing the technical risk, and the product owner for managing the business risks. The product owner was strongly represented in managing stakeholders; neither the team nor the agile coach was significantly engaged in this task. The project team was not at all involved in procurement in agile methodologies.

Figure 1 combines the qualitative results from the literature review with the quantitative results and thereby provides a consolidated view of project management responsibilities in agile projects. The rows represent the 39 ISO processes grouped into the 10 ISO subject areas, the columns represent the scum artifacts or events as method or the project roles considered in the study, and the color represents the relative degree to which the processes were executed. For example, the integration subject area includes seven processes: two of the processes map to five scrum artifacts and events. The scrum master role maps to one process for the subject area, the product owner role maps to two, the team role maps to five, and the project manager and sponsor role map to none. The details are presented in Tables 4 and 5.

Table 4 presents the qualitative results from the literature review combined with the quantitative results. It depicts the scrum artifacts, roles, and events aligned to the ISO project management subject areas and processes. The checkmark (✓) notes alignment based upon a formal reading of the methodologies; the plus (+) confirms that knowledge based on the results from the survey. The results signified that responsibilities have shifted from the project manager to the agile roles. Table 5 indicates the shift in responsibility from the project manager with a negative sign (−) and indicates the shift in responsibility toward the sponsor or other roles with a plus (+). Such a shift has occurred in most cases; however, the project manager remains significantly responsible for procurement activities.

Table 3. ISO process by project role
Full size table
Fig. 1.
figure 1

Heatmap of ISO process groups by project roles

Full size image

4.5 Summary

For agile methodologies, some of the project management responsibilities are inherent in the frameworks. The analysis clarified how the project management activities are distributed among the project roles.

Table 4. Project management framework: Scrum
Full size table
Table 5. Project management framework
Full size table

5 Discussion

First, while agile project methodologies are gaining in popularity, traditional methodologies continue to be in widespread use. Regardless of the methodology, the project management tasks as identified in the ISO standards for managing projects remain relevant. Project managers are engaged in agile projects to a greater degree than agile coaches or product owners. Project managers continue to perform management tasks and do not only act as a “gatekeeper,” as described by Taylor [3]. In this study, the sponsors and product owners undertook some management activities, whereas the agile coaches did not. Thus, this partially supports the proposition by Noll, Razzak, Bass, and Beecham [2] that assigning a former project manager to the product owner role rather than the scrum master role will result in a higher degree of project success.

In practice, the project manager focuses on team management and risk identification tasks, while the product owner focuses on scope and stakeholder management activities. The product owner is responsible for the scope before the project starts, during the project, and after the project is completed. A project manager is a transitory role and is not typically engaged in the market and withdrawal phases of a product lifecycle. Stated differently, the boundary for the product owner is the product features, whereas the boundary for the project manager is the project process. Thus, the pairing of sponsor and product owner represents a logical combination for both long-term product success and short-term project success. The agile coach’s boundary is the team, and the team’s boundary is the project work during an iteration.

For agile projects, the authorization to perform the work is given to the product owner [5]; for plan-driven methodologies, it is given to the project manager [21]. For plan-driven methodologies, the project termination criteria are defined at the start of the project; for agile methodologies, the endpoints emerge over time. This emergence enables flexibility to terminate projects early or to continue beyond an originally planned closing date [5]. The project management tasks in plan-driven methodologies are centralized to the project manager role. In agile methodologies, some of the project management responsibilities are inherent in the framework or distributed to the agile roles, although others are practiced by a project manager or other roles.

From this study, it became clear that the agile coach has a much more limited set of tasks than the project manager. The agile coach has two primary responsibility areas: developing the team and supporting all stakeholders, helping them to understand and apply the methods. In this regard, the management style suggested for an agile coach is that of an effective leader, facilitator, or coach [26]. This recommendation corresponds with studies that argue that a project manager capable of adopting a facilitator leadership style could lead an agile project [10, 11, 26, 27]; however, it is not suggested that the project manager also fill the coaching role as there is likely to be conflict related to the delegation and management styles required by the different sets of responsibilities [2]. Furthermore, the results indicated that the presence of an agile coach was correlated with project efficiency; however, correlation is not causation.

6 Conclusions

Although the tasks that would typically be executed by a project manager are not (explicitly) addressed by agile methodologies, they continue to be practiced. The team, product owner, and project sponsors are assuming the informal role in some project management tasks. The project manager, however, continues to be engaged, albeit with an altered task distribution and leadership style. Table 6 presents a summary of the scope of each role.

Table 6. Boundary, Authority, Role, and Task (BART) analysis for Agile methodologies
Full size table

6.1 Contributions to Knowledge

The results of this study quantify subjective and theoretical speculation on who performs the project management tasks in agile projects. By empirically defining the project manager’s tasks in agile projects, the results of this study contribute to the project management literature on agile methodologies. Although agile methodologies are in widespread use, this information was missing in practice and under-researched in academia.

6.2 Implications for Practice

The practical implication is that project sponsors should consider the project manager an essential role in all project types; however, at the same time, project managers should recognize their reduced role and acknowledge that the product owner is a co-equal partner. In addition, when staffing decisions require a trade-off in role assignments, the project manager role is closer to the product owner role than the agile coach role. Agile coaches add value and increase efficiency by focusing on the team.

The agile methodology authors should update their practices to identify the role the project team and product owner play in assessing, treating, and controlling risks and in selecting suppliers. Furthermore, they should update their practices to reflect the project management tasks that may be outside of the team operations but necessary for project sponsors or project managers to execute. Tables 4 and 5, and Fig. 1 provide a guideline for mapping specific project roles to project management activities.

Since the rigorous application of method artifacts, roles, and events is responsible for some typical project management activities, care should be taken to consider project governance when tailoring agile methods. Next, the agile coach plays a key role that can improve the productivity of project operations. Thus, the role should be formalized into traditional methodologies as a role separate from the project manager. Finally, the project management standards from ISO [19], PMI [21], and APM [20], as well as the PMI Agile Practice Guide [7], should be updated to reflect the findings from this study.

6.3 Implications for Research

In future studies, researchers investigating agile methodologies should consider the participants within the overall projects. We determined that fewer than half of the projects following the scrum methodology incorporated all the scrum roles. Thus, the actual results from project studies may inappropriately attribute successful outcomes to the methodology. The role of the “agile project manager” referenced in some studies in the literature is inconsistent with some agile methodologies and with practices. Specifically, in some cases, methodologies that describe the agile project manager do not specify whether the project manager is assuming the responsibilities of an agile coach combined with a project manager, nor do they mention whether an agile coach is present alongside the agile project manager. Thus, the construct of the agile project manager should be formalized in line with the results of this study.

6.4 Limitations and Further Research

The results of this study are not generalizable beyond the methodologies studied in this research. Specifically, software development projects have been the most active in applying agile methodologies. There were no measures to determine whether the project type skewed or biased the results. We lacked financial or factual data to measure project efficiency and performance; thus, we could only evaluate the perception of project performance as judged by the participants. Furthermore, the findings are limited due to the small sample size. Future research could focus on a qualitative study of the agile project organizations, seek to quantify the engagement of the separate roles or use strategies to avoid the limitations of this study.