Conference PaperPDF Available

Antecedents of Preference for Agile Methods: A Project Manager Perspective



Content may be subject to copyright.
Antecedents of Preference for Agile Methods: A Project Manager Perspective
David Bishop, D.Sc.
Dakota State University
Pam Rowland
Dakota State University
Cherie Noteboom, Ph.D.
Dakota State University
Using a Grounded Theory approach, this research
reveals a view from a project manager’s perspective on
the factors influencing preference for agile methods.
Fifteen managers were interviewed and theoretical
constructs developed reflecting the factors influencing
their preference. Positive, negative and contingent
factors emerged from the data. The core category
discovered is pragmatism. Project managers exercise
pragmatic assessment when expressing their preference
for agile methods. Seven factors that positively influence
preference are identified and discussed, along with two
negative factors and two contingent factors.
1. Introduction
The use of agile development methods in software
development and project management is popular in a
world demanding support for constant change and
innovation. The use of agile methods is still on the rise.
The 2016 VersionOne State of Agilesurvey shows
that while 94% of respondents’ organizations practice
some agile, 60% of the teams in those organizations are
not practicing agile [1]. The statistics indicate agile is
widely used, but there is still significant opportunity for
further adoption within organizations.
The variation in manager preferences for various
development methodologies is significant. A portion of
the preferences is attributed to several characteristics of
methodologies. The fit of the solution, the
circumstances of the problem, and the nature of the
challenge, influence the effectiveness of a methodology.
Agile development is defined as an excellent fit when
circumstances require that the project is ambitious, there
is a need for modifying deliverables with frequent input
from the customer, and where rapid delivery is
necessary [2]. In addition, the agile development
method lends itself to iterative and incremental
development, customer collaboration, and frequent
delivery [3]. Speed, efficiency, collaboration and
change management are considered key attributes of
agile development [4].
There is a lack of understanding of manager
preference for agile development methods. The goal of
this study is to contribute to the literature by identifying
factors that influence managerial preferences for agile
software development. The investigation will consider
project manager preferences for development
methodologies with an open lens to fully understand the
influences and perceptions of the managers.
We will first provide initial background on the topic,
then discuss the research design. Following this will be
a detailed description of the findings. We will conclude
with a discussion of the research and future directions.
2. Background
There have been theoretical developments to extend
agile development principles to a variety of different
contexts such as large and dynamic software
development projects [5], distributed software
development projects [6], data warehousing and
business intelligence projects [7], and game
development projects [8]. The literature on agile project
management has focused on comparing traditional plan-
driven approaches with incremental approaches [9-11].
These papers focus on the practices and processes
emphasizing the benefits of the agile approach. The
authors identify ways for managers to evaluate the use
of agile method. It is unclear how project managers
form their preference for or against agile methods.
Research on understanding project managers’ attitudes
toward agile development methods is limited. The
question of factors influencing project manager
preference for agile methods has not been fully
addressed in the literature. This is an important research
question to study as managers rationalize their choice of
methods seeking to improve project performance and
team effectiveness.
Research suggests that the adoption of agile is driven
by several influential factors such as project size,
application criticality, complexity, employee skillset,
and company culture [12-14]. The emphasis of agile
development is on teams and team interactions and
dynamics. Management is defined as a process of
planning, organizing, leading, and controlling. Within
agile development, the traditional role of the project
manager changes from command and controlto more
of a coach or facilitator[14]. The project manager
now has the responsibility of managing the collaborative
efforts of the team without stifling their creativity.
Managers need to be flexible to leverage each team
member’s expertise [15]. This focus is significantly
different than traditional systems where the focus was
Proceedings of the 51st Hawaii International Conference on System Sciences |2018
ISBN: 978-0-9981331-1-9
(CC BY-NC-ND 4.0)
Page 5435
on the process. Taylor’s research focused on
understanding how agile techniques shaped the
practices of project managers, and how they dealt with
conflict [16]. Her findings focused on how change in
methods influence human experience and can cause
some conflict. She also identified how project managers
should relinquish some control when using agile.
Organizational cultures and management have an
influence on development methods. Research has been
extensively conducted on the tensions and trade-offs
between stability and agility in organizational
management [17-19]. The literature on organizational
theory and learning gives solid reasoning for providing
an organizational climate conducive to adapting to
change. This adaptation is positively associated with
superior performance [18, 19].
Vinekar, et al. summarized the opposing
characteristics of agile and traditional development
methods as related to management [14]. Table 1 shows
this comparison.
Command and
Manager as
Manager as
Team reward
reward system
Table 1 - Agile and traditional methods
Bishop, Deokar and Sarnikar have investigated
preference from a software developer’s perspective
[20]. The current research seeks to extend that research
into the area of management preference for agile
software development methods. Consequently, our
research seeks to identify influential factors in project
manager’s preference (or lack of preference) for the
agile software development method. This desire led us
to our research question: What are the factors that
influence software development project managers’
preference for or against agile methods?
3. Research design
Since the goal is to develop empirically based
theory, we chose the grounded theory form of
qualitative research. This method is well established in
the field of Information Systems [21, 22].
Unlike quantitative methods, where a representative
random sample of a population is critical, grounded
theory uses theoretical sampling [23-25]. Theoretical
sampling seeks data from sources that will provide rich
information regarding the emerging categories and
theory rather than sources strictly intended to be
statistically representative of the target population [26].
We have performed a preliminary literature review
to orient our research to the literature. In keeping with
grounded theory principles, we have engaged the
literature review while attempting to avoid theoretical
expectations and bias [27].
3.1 Data collection
For data collection, we developed a list of semi-
structured interview questions, as well as an initial list
of managerial contacts. To develop our list of
participants, we started with our own professional
network of project managers who have agile experience.
After interviewing a participant, we would ask them for
additional contacts who might be able to contribute to
our study. This technique of identifying participants is
sometimes called the snowball technique or chain
referral technique. Although this approach may have
issues, if managed appropriately it can be useful for
qualitative research [28].
We performed interviews of these contacts, digitally
recorded the interviews, and transcribed the recordings
into written documents. Fifteen participants were
interviewed from across the Midwest and Western
United States. Companies ranged from small to Fortune
50-sized organizations. The interviews resulted in 345
minutes of recordings which were transcribed into 132
pages of narrative. The participant demographics are
summarized in Table 2.
Business Type
Page 5436
Business Type
Aerospace and
Table 2 - Participant information
3.2 Data analysis
Next, we analyzed the transcripts using grounded
theory coding techniques [24]. As part of a team of three
researchers we initially coded the transcripts using
Atlas.ti. We then compared our coding and developed a
set of concepts to group and conceptualize the codes.
Finally, we performed one more step of abstraction and
formed categories.
As we analyzed the codes we summarized them into
concepts, and then abstracted the concepts into
categories. Table 3 shows the concepts that support the
Not perfect, but better than
the alternative (waterfall);
Increased efficiency of
developers; Improved
quality; Better planning;
Deliver features faster;
Successful projects
Customer engagement;
Collaboration; Customer
influence; Customer value
Risk management
Reduced team liability; Fast
feedback; Increased
predictability; Improved
progress visibility
Improved communication;
Fast feedback; Team
engagement; Customer
Team satisfaction
Tech team likes agile;
Increased dev efficiency;
Team engagement;
Increased accountability;
Improved teamwork; Self-
organizing teams; Training;
Empowerment; Trust;
People focused
Incremental work
Increased predictability;
Iterative and time-boxed
work; Small chunks of
work; Better scope
Adapts to change better;
Increased flexibility
Desire for fixed
Some upper
management/clients want
defined deadline, cost and
Change averse
Management are change
Work fit; Cultural fit; Team
Hybrid necessary;
Hybridization leads to
Table 3 - Categories and concepts
4. Findings
4.1 Pragmatism
When summarizing the philosophical foundations of
agile methods, Nerur and Balijepally indicate the
philosophical view of Pragmatism for agile methods
[29]. Pragmatism, as a philosophy, views knowledge as
“arising from an active adaptation of the human
organism to its environment” [30]. This harmonizes
well with agile values and principles. In more colloquial
terms, Webster’s Dictionary defines pragmatism as “a
practical approach to problems and affairs” [31].
A theme of pragmatism emerged from the data.
Project managers found agile useful. It is not perfect, but
is often characterized as better than the alternatives. P6
says agile fits the nature of the work better than the
other methods we've used.”
As noted in Table 3, participants find a variety of
benefits when using agile approaches. They note
characteristics like increased efficiency, improved
quality, better planning, faster delivery of features and
successful projects. These experiences highlight the
practical value of agile methods leading to heightened
preference among project managers for agile methods.
Pragmatism is identified as the grounded theory
“core category” and is discussed further in Section 5 of
this paper. It provides a unifying theme that is supported
by each of the following categories.
Page 5437
4.2 Customer satisfaction
Project managers consider customer satisfaction a
primary goal of software development. Managers
indicate that agile allows more opportunity for contact
with the customers enabling them to meet the needs of
the customer throughout the project, thus increasing
satisfaction. With agile software development,
customers are involved throughout the project life cycle
and interaction is much more frequent than in traditional
methodologies [12, 32].
One aspect that contributes to participants’
preference for agile in relation to customer satisfaction
is customer engagement. As P14 says, “I think this
really does help us because the users are involved in
our daily scrums. So we can bring questions to them,
they're right down there with us and they can look at it
Another concept that leads to this category is
collaboration. Customers share in the work and
recognize the importance of their contribution to the
success of the project. P5 says agile is great for
Customers also have the opportunity to influence the
features and implementation through their feedback.
This naturally leads to higher satisfaction on their part.
P3 says that agile teams can, “use that feedback, make
quick decisions, [and] influence the direction of the
Agile allows the project to focus on things of value
to the customer leading to a product that satisfies their
needs. Rather than focusing on intermediate milestones,
approvals and non-software artifacts, agile focuses on
delivering a product that brings benefit to the customer.
As P10 states, agile gives “you the opportunity to work
on the things that have the highest business value.
Additionally, customer engagement, collaboration,
influence and value lead to customer satisfaction.
Customer satisfaction positively influences project
managers’ preference for agile. Customer satisfaction
increases the utility of agile in the eyes of project
managers making it an effective, successful and
pragmatic method of software development.
Participant P1’s statement of why she prefers agile
is a great summary for this category, “I just think the
opportunity to provide customer satisfaction is huge.”
4.3 Risk management
Risk management is used to determine the risk
exposure of a given course of action [33]. Software
projects are high risk because of the number of variables
that affect outcomes. Only about a quarter of software
projects succeed outright and billions of dollars are lost
annually to project failures [34].
Our risk management category emerged from
several concepts in the data: reduced liability, fast
feedback, predictability and progress visibility.
Participants from the services sector are particularly
attracted by the ability of agile to manage risk. P8 says
this about using agile methods with his projects: “It's all
about liability, just mitigating or minimizing that
liability for us.” With regard to getting fast feedback
P13 states, with agile, bringing the customer in early
on helps to alleviate that risk.
Regarding predictability, P12 says, “The promise is
far more predictability in delivery. Agile teams tend to
be extremely predictable in the amount of scope that
they can deliver in a period of time, much more so than
anything you get out of a waterfall approach.
We see progress visibility as an important concept
that participants attribute to reducing risk. Due to the
incremental delivery of working software customers
(and team members) have visual and experiential
validation of actual progress. This is much different than
a traditional waterfall approach where progress is
largely measured through document artifacts and
associated milestones rather than working software. P1
makes this point, I think that's what I like about it
[agile] the most, is that you're showing that product to
the customer. You have a deliverable result every sprint.
… You're showing results for your work done, which I
think is the difference the big difference between that
and Waterfall. Waterfall, you can't show results, and
they wonder what you're doing for all that long time.”
Risk management surfaces as an important category
from the data. The practical value of improved risk
management to project managers supports the core
category of pragmatism as an antecedent for agile
preference among managers.
4.4 Communication
Agile integrates effective communication within
teams [35]. It enables diverse project teams to move
through the cycle of ‘thought-action-reflection’ [13],
which improves the process and enables learning and
adaptation. Communication emerges from the data as a
category. Communication has the power to improve
transparency, understanding and interactions. The daily
scrum or standup meeting appears as a key mediator of
effective communication. As one participant, P15,
notes, “I'm a big fan of the daily stand-up. This is a
chance for the developers of different flavors [to] get
heard and share their experience and opinion about
working down the work for the iteration. I think this is
highly useful and absolutely important. Another
participant, P5, feels agile strongly influences the
Page 5438
communication, recognition and teamwork. “They meet
daily in a scrum to talk about what they’ve
accomplished, what they’re working on, what’s getting
in their way. They brainstorm ideas. They get to talk to
the users and hear what their needs are. They get to brag
a little bit about their accomplishments and what they’re
doing. And they get to show off a little bit with look
what I made for you. And they get to hear that
immediate feedback” (P5).
The speed of communication is another aspect noted
by a participant, “I would say early feedback, fast
feedback is a key thing” (P8). Other participants say
continuous communication positively influences the
process. “What I like about it is that the team is
continuously meeting and communicating and
addressing issues as they occur, because it allows
customer feedback quicker. So, what we try to do is we
try to get the customer very involved” (P9).
One of the positive contributions from
communication is improved experience and flow of
information. P4 contributes this comment: “It's a
quicker turnaround and quicker feedback from the
customer. And so, it's a better experience all around for
the customer as well as the engineer because we're just
we're touching base with them so often throughout the
whole process” (P4).
Another comment indicates the timing of
communication and interaction is a daily event, which
influences the project insight and understanding.
“We’re still in the basement but now we have business
users and sponsors who are with us almost daily. In
some cases, daily. And in some cases, maybe weekly or
monthly. But they have a lot more insight into what we
do on a day to day basis. A lot more hands on with
helping us drive our work efforts, our projects. And then
they get to see all the other stuff that comes along that
derails our projects” (P5).
The contribution of agile communication strategies
appears to result in transparency and understanding,
which contributes to achieving business strategy and
goals. One participant states, “I like agile methods a lot.
It’s a lot easier. It’s a lot better for us. It’s a lot better for
the business. It really lends itself to transparency. We’re
getting better in our communication between the
business units and IT with them being able to express
what they need and us being able to analyze better their
requirements and help them figure out what works for
them” (P5).
Some participants feel communication is the biggest
adjustment when changing methodologies as indicated
by this comment: “So I think the biggest difference
between the methodologies isn't necessarily how my
day-to-day of managing a project changes, it's more of
that day-to-day how I communicate with the clients and
even communicate with the team” (P11).
Participants’ preference for agile is positively
affected by their perception that agile enhances
communication within the team and between the team
and customers. We see that improved communication is
an effective benefit arising from the data and supporting
the pragmatic category of managerial preference for
4.5 Team satisfaction
Agile methods not only increase customer
satisfaction, but also increase the satisfaction of the
development team. According to the literature, there are
twice as many members of agile teams who are satisfied
with their jobs verses members of non-agile teams [36].
Team members’ satisfaction increases due to the ability
to influence decisions, working on satisfying projects,
and having relationships with the team and the users.
Both individual and team morale increase with agile
Project manager participants like the regular team
communication. “What I like about it is that the team is
continuously meeting and communicating and
addressing issues as they occur” (P9). They find
encouragement through the teamwork and commitment
of the team. The following indicate project managers’
views on team satisfaction: “That was encouraging just
to get to see the developers work together like that”
(P6); “Agile really lends itself to the team environment”
(P5); Agile really allows team members to kind of self-
organize, and manage their work, and work together”
(P1); “They can have a better sense of commitment to
the end goal. I think you have the morale is better with
the project team” (P6).
Software development is a human endeavor. The
data indicate that project managers recognize the
significance of human factors and perceive their
importance to team satisfaction. They recognize agile is
a useful methodology to accommodate the human nature
of teamwork.
One of the four Agile Manifesto’s values
emphasizes the human side of software development
stating, We have come to value: Individuals and
interactions over processes and tools” [32]. Recent
research has also focused on the human aspects of
software development in an agile environment [38, 39].
Our participants discuss a variety of teamwork
aspects to agile software development including self-
organizing teams, empowerment, ownership and trust.
P15 states, I think a key component that the software
development team has responsibility in organizing when
they do what is asked of them, and manage this process
and prioritization themselves. He goes on to say,
“Agile has to do a lot with trust” (P15).
Page 5439
From the perspective of the project manager, the
technical team enjoys benefits of agile through
increased efficiency, team engagement, accountability,
self-organization, empowerment and trust. Project
managers recognize that team satisfaction makes for a
better and more productive work environment, making
agile an attractive approach to project management.
4.6 Incremental work
Another category that emerges from the data is
summarized as incremental work. This encompasses a
range of concepts such as increased flexibility-- the
ability and freedom to adapt to change. It also includes
the notion of short delivery cycles that provide features
faster to customers, which enables faster feedback from
them. Incremental work also captures the idea of time-
boxed iterations, which managers viewed as providing a
better planning approach and producing higher degrees
of schedule predictability.
Incremental work resonates with the literature. It has
been shown to reduce complexity and demonstrates
compatibility with the way software is developed [40].
Regarding small units of work, one participant says,
“It makes it simpler for people in a way because you're
working on a limited number of items, so you're
focused” (P3). When it comes to incremental work and
delivering features faster, P3 says, “I can do a lot more,
be much more aggressive, make faster changes, and
make a better product.”
Delivering features faster lays the groundwork for
obtaining quicker customer feedback and adapting to
their emerging needs. P13 states the issue with waterfall
from the customer’s perspective: “They're not happy
with what they got, and part of the problem is they don't
know what they want until they see it. So, with agile,
bringing the customer in early on helps to alleviate that
risk.Agile “allows customer feedback quicker” (P4).
And P8 states, I would say early feedback, fast
feedback is a key thing.
With respect to time-boxing P1 says, “What you do
is you take a time-box and you determine an amount of
work that you can do in that time-box, that can actually,
from start to finish, deliver useable, working
product.” It is critical that the scope is also fixed within
an iteration, not just the time. P15 says, A key principle
that is important to me … which goes into process,
beyond principle is the idea that you work in
iterations where inside the iteration there is a fixed
commitment that doesn't get changed during the
Incremental time-boxed small chunks of work lead
to higher predictability. P5 says, “As a team we can see
how much work we can take on every three weeks
When you can say this is what we can do in three weeks
and you can deliver something to the users and they go,
oh, you know what? That’s enough.
The category of incremental work contributes to a
pragmatic preference for agile. Working in time-boxed
iterations leads to many benefits and project managers
are drawn to an effective methodology.
4.7 Adaptive
The adaptive category emerges with two facets from
the data. One facet covers the ability to adapt the agile
process to best fit the situation, such as corporate
culture, stakeholder needs or team dynamics. The
second facet deals with the ability of an agile project to
adapt to the changing functional requirements of the
According to Masood and Farooqi, The iteration
approach that defines agile project management
emphasizes the need to reconsider each of the completed
project cycle before moving to the next. This implies
that the project specifications, plans and designs may
keep changing in line with changes in the project
environment” [38].
The opportunity to change quickly and adapt to
business needs is indicated with participant comments
like “It's agility. It's the ability to change very quickly”
(P4) and “The nice thing about agile is you can
customize it to fit your business need” (P5). One
participant feels individualization of methodology is
possible. “There’s part of it that you like and parts of it
you don’t, you can draw from different pieces and make
it your own” (P5).
The second facet of adaptation is responding to
changing requirements. As P13 notes about traditional
waterfall methods, “We've had enough experience here
at [Large Corporate Entity] where we've built huge
technical systems that were great engineering feats, but
the market changed during that time of the development
and we didn't respond to the market.
Participants find that agile is better able to adapt to
changing requirements. Project managers appreciate a
methodology that allows them to respond to ever
changing functional requirements. This also resonates
with the values and principles found in the Agile
Manifesto [32].
Adaptability, both in process and product, often
makes agile more attractive than the alternatives.
4.8 Desire for fixed outcomes (negative factor)
Traditional software development methodologies,
such as waterfall, are based on a sequential series of
steps [41]. These traditional methodologies define and
document a set of requirements. The success of the
Page 5440
project depends on knowing all the requirements before
development begins. Making any changes during the
development life cycle can be difficult. The benefit of
detailed planning lies in determining the cost of the
project, the schedule, and allocating the needed
resources [42].
When stakeholders request fixed cost, schedule or
resources, the agile software methodology is
challenged. Project manager P12 states,
“Predominantly their [middle management’s] objection
is I won’t have an end date with fixed scope, fixed
quality, fixed resources that I can present to upper
management and they’re not going to buy-in, because
middle management tends, with few exceptions, to not
recognize that upper management got there by
understanding that there is no such thing as a 100%
predictable project. They think their job is on the line if
they’re not 100% predictable, whereas upper-
management would probably make some tradeoffs.”
Stakeholders may have expectations that cannot be
met by agile: “Agile usually runs into problems when it
comes to stakeholder expectations” (P8). With smaller
projects, agile is certainly advantageous, but with large
projects it is difficult to estimate the time and effort
needed to complete the software project using agile.
The perception and reality of stakeholders’ desire for
fixed outcomes diminishes some project managers’
preference for agile methods.
4.9 Change Averse (negative factor)
Upper management is known to resist change and
prefer maintaining the status quo [42]. Adopting agile in
an organization that is accustomed to more traditional
Systems Development Life Cycle brings change
throughout the organization. Astute project managers
recognize that key management stakeholders may be
change averse and we observe that this negatively
affects project managers’ preference for agile methods.
Participants mention the importance of management
support and buy-in for successful agile usage. However,
potential upper management concerns related to agile
methodology appear to reduce project managers’
preference for agile. The importance of management
support was indicated with participant comments like,
“First, [we] need management buy-in” (P8) or “We had
to get the executive level buy-in before it took off. They
really had to see the advantages. They had to become
engaged. They really needed to support it from that level
down. And then we saw it really take hold” (P5).
The change averse nature of some stakeholders
influences project managers as indicated by one
participant, P9, You have to have the organizational
buy-in and support that this is going to work. If the
organization does not believe in the concept of agile
development, then it's not going to work.”
If an organization’s top management is resistant to
change, it will negatively affect the desirability of agile
methods by the project manager.
One of the characteristics of being change averse
appears to be a sense of loss of safety found in the
information provided in the traditional project
management triangle of time, cost and scope. P12’s
comments indicate this: “Predominantly their objection
is I won’t have an end date with fixed scope, fixed
quality, fixed resources that I can present to upper-
management and they’re not going to buy-in” (P12).
Some participants note ways of dealing with the
managements being change averse with comments like,
“Upper management, I think you try and balance the
flexibility of the agile approach with the certainty of
kind of the deterministic outcomes and kind of push as
much as you can to let them know the risks involved
with the approach while still trying to provide
confidence in your abilities to execute on the project”
(P7). The upper management perception of agile
appears to be fear of losing control of the budget, the
deliverable and the schedule.
The comments in the change averse category
materialize as having power to negatively influence the
preference for agile among project managers. A
comment demonstrating the power of the culture change
is: “If a client does not have agile instituted in their
corporate culture already we can very rarely walk in
there and be successful in an agile method” (P11).
The project managers indicate a need to engage and
educate managers to understand the benefits of agile
prior to making a transition. P1 says, “I think that the
if you're able to get your buy-in from your stakeholders
your sponsors, and you are able to have a true product
owner that can speak for the requirements and
communicate those to the team, I think you can be very
successful at agile. The problem is IT departments try to
implement an agile methodology, but if they don't have
their sponsors and their business stakeholders on board
with that and able to operate in that same methodology,
then they have a real difficult time” (P1).
In some situations, the perceived change averse
nature of management negatively influences project
managers’ preference for agile methods.
4.10 Contingent factors
In addition to the positive and negative factors, a few
factors surface that, depending on the project context,
could be either positive or negative.
We recognize fit as one of these factors. We identify
three dimensions of the fit factor. First, there needs to be
Page 5441
a cultural fit, in addition there has to be a fit with the
work, and finally there needs to be a team fit.
Another contingent factor we term hybridization.
This has to do with the participants’ experiences with
combining agile with waterfall methods. In some cases,
the project manager could integrate these disparate
approaches effectively, providing the desired fixed
outcome information upward toward higher
management while allowing the team to operate in an
agile manner. In other cases, this dichotomy causes
confusion on the team, as P8 says, “You have a scope, a
budget, and a schedule. If you do, it's not agile, even
though we borrow the [agile] ceremonies … Just 'cause
we're using these ceremonies does not mean it's an agile
project, and sometimes our own employees get that
confused” (P8).
Consequently, contingent on the context of a specific
project and organization, fit and hybridization can either
be a positive or a negative influence on a project
manager’s preference for agile.
5. Limitations and discussion
5.1 Limitations
The study depends on a limited group of
participants. Although there are representatives from
diverse industries and company sizes, expanding the
size and diversity of the sample could help amplify the
findings and possibly expand to new concepts and
categories. We do sense from the data that the core
category discussed below is a significant and relevant
5.2 Core category
Grounded theory employs the idea of a core category
that relates all the categories [43]. We chose pragmatism
as the core category for the data. Pragmatism evaluates
the veracity of theories based on their practical utility.
The sentiment of practicality resonates with each of the
categories. Project managers consistently relate their
preference for agile in terms of the value of agile in their
practical experience. They contrast the utility of agile
with the problems they experienced with traditional
waterfall. For example, P12 says, I gave up waterfall
as soon as I had control over my own destiny, so I have
plenty of experience, but it’s all been I mean I would
never impose that on a development team.
Agile is effective from an interpersonal relationship
perspective (customer satisfaction, communication, and
team satisfaction) and it is effective from a project
perspective (risk management, incremental work, and
The negative factors arise because of unfavorable
experiences or perceptions. When a project manager
perceives she cannot meet stakeholder expectations for
fixed outcomes, there is a decrease in her preference for
agile because, from her perspective, it does not work.
Likewise, if the organizational culture is change averse,
then moving to agile may be an inappropriate choice,
not because it isn’t a good methodology, but because it
may not be practical in that environment. Finally, if
customers are not willing to engage throughout the
project in a timely manner, project managers are reticent
to employ agile methods because they will be
ineffective. The factors leading to preference for agile
among project managers are pragmatic in nature.
Our findings do not imply that agile is the best
methodology for all projects. The negative and
contingent factors point out circumstances where other
methods may be preferred. Regulatory requirements and
cultural fit may indicate that alternative software
development methodologies may be more appropriate.
But, in a wide variety of circumstances, project
managers find value in agile methods over other
methods for pragmatic reasons.
5.3 Future research
The results from this grounded theory research can
be strengthened by enlisting additional participants from
a variety of experiences [35]. One participant, P10,
suggested expanding the sample to include project
managers practicing outside of the United States.
Expanding to a more diverse set of project managers’
experiences offers the opportunity to enhance, expand
and solidify these findings.
Using the factors identified in this research, follow-
up opportunities exist to develop survey instruments to
measure these factors as constructs. With one or more
survey instruments, quantitative research could also be
performed to validate and explore the realtionships
between the constructs.
Finally, to develop a 360-degree view of agile
preference in software development, the authors will be
engaging in a grounded theory study of agile preference
from the customers’ perspective. The study will focus
on factors from the product owner, user and other
business stakeholders’ perspectives that influence their
preference for agile methods on software development
6. References
[1] VersionOne. (2017, April 6). 11th Annual State of
Agile Development Survey. Available:
Page 5442
[2] E. C. Conforto, F. Salum, D. C. Amaral, S. L. da
Silva, and L. F. M. de Almeida, "Can agile project
management be adopted by industries other than
software development?," Project Management
Journal, vol. 45, pp. 21-34, 2014.
[3] J. Cho, "Issues and Challenges of agile software
development with SCRUM," Issues in Information
Systems, vol. 9, pp. 188-195, 2008.
[4] K. N. Rao, G. K. Naidu, and P. Chakka, "A study of
the Agile software development methods,
applicability and implications in industry,"
International Journal of Software Engineering and
its applications, vol. 5, pp. 35-45, 2011.
[5] D. Batra, D. VanderMeer, and K. Dutta, "Extending
agile principles to larger, dynamic software projects:
A theoretical assessment," Journal of Database
Management (JDM), vol. 22, pp. 73-92, 2011.
[6] F. Bergadano, G. Bosio, and S. Spagnolo,
"Supporting collaboration between customers and
developers: a framework for distributed, agile
software development," International Journal of
Distributed Systems and Technologies (IJDST), vol.
5, pp. 1-16, 2014.
[7] N. Rahman, D. Rutz, and S. Akhter, "Agile
development in data warehousing," in Principles
and Applications of Business Intelligence Research,
ed: IGI Global, 2013, pp. 286-300.
[8] S. P. Cano, C. S. González, C. A. Collazos, J. M.
Arteaga, and S. Zapata, "Agile software
development process applied to the serious games
development for children from 7 to 10 years old,"
International Journal of Information Technologies
and Systems Approach (IJITSA), vol. 8, pp. 64-79,
[9] M. Ceschi, A. Sillitti, G. Succi, and S. De Panfilis,
"Project management in plan-based and agile
companies," IEEE software, vol. 22, pp. 21-27,
[10] M. Coram and S. Bohner, "The impact of agile
methods on software project management," in
Engineering of Computer-Based Systems, 2005.
ECBS'05. 12th IEEE International Conference and
Workshops on the, 2005, pp. 363-370.
[11] D. J. Fernandez and J. D. Fernandez, "Agile project
managementagilism versus traditional
approaches," Journal of Computer Information
Systems, vol. 49, pp. 10-17, 2008.
[12] B. Boehm and R. Turner, "Using risk to balance
agile and plan-driven methods," Computer, vol. 36,
pp. 57-66, 2003.
[13] S. Nerur, R. Mahapatra, and G. Mangalaraj,
"Challenges of migrating to agile methodologies,"
Communications of the ACM, vol. 48, pp. 72-78,
[14] V. Vinekar, C. W. Slinkman, and S. Nerur, "Can
agile and traditional systems development
approaches coexist? An ambidextrous view,"
Information systems management, vol. 23, pp. 31-
42, 2006.
[15] A. Cockburn and J. Highsmith, "Agile software
development: The people factor," IEEE Computer,
vol. 34, pp. 131-133, 2001.
[16] K. J. Taylor and K. J. Taylor, "Adopting Agile
software development: the project manager
experience," Information Technology & People, vol.
29, pp. 670-687, 2016.
[17] M. J. Benner and M. L. Tushman, "Exploitation,
exploration, and process management: The
productivity dilemma revisited," Academy of
management review, vol. 28, pp. 238-256, 2003.
[18] C. B. Gibson and J. Birkinshaw, "The antecedents,
consequences, and mediating role of organizational
ambidexterity," Academy of management Journal,
vol. 47, pp. 209-226, 2004.
[19] Z.-L. He and P.-K. Wong, "Exploration vs.
exploitation: An empirical test of the ambidexterity
hypothesis," Organization science, vol. 15, pp. 481-
494, 2004.
[20] D. Bishop, A. V. Deokar, and S. Sarnikar, "On
Understanding Preference for Agile Methods among
Software Developers," Information Resources
Management Journal (IRMJ), vol. 29, pp. 12-36,
[21] D. F. Birks, W. Fernandez, N. Levina, and S.
Nasirin, "Grounded theory method in information
systems research: its nature, diversity and
opportunities," 2013.
[22] R. Matavire and I. Brown, "Investigating the use of
grounded theory in information systems research,"
in Proceedings of the 2008 annual research
conference of the South African Institute of
Computer Scientists and Information Technologists
on IT research in developing countries: riding the
wave of technology, 2008, pp. 139-147.
[23] B. G. Glaser and A. L. Strauss, The discovery of
grounded theory: Strategies for qualitative
research. Piscataway, NJ: Transaction Books, 1967.
[24] K. Charmaz, Constructing grounded theory: A
practical guide through qualitative analysis: Sage
Publications Limited, 2006.
[25] J. M. Corbin and A. Strauss, "Grounded theory
research: Procedures, canons, and evaluative
criteria," Qualitative sociology, vol. 13, pp. 3-21,
[26] C. B. Draucker, D. S. Martsolf, R. Ross, and T. B.
Rusk, "Theoretical sampling and category
development in grounded theory," Qualitative
health research, vol. 17, pp. 1137-1148, 2007.
[27] C. Dunne, "The place of the literature review in
grounded theory research," International Journal of
Social Research Methodology, vol. 14, pp. 111-124,
[28] P. Biernacki and D. Waldorf, "Snowball sampling:
Problems and techniques of chain referral
sampling," Sociological methods & research, vol.
10, pp. 141-163, 1981.
[29] S. Nerur and V. Balijepally, "Theoretical reflections
on agile development methodologies,"
Communications of the ACM, vol. 50, pp. 79-83,
Page 5443
[30] R. Field, "John Dewey (1859-1952)," Internet
encyclopedia of philosophy, 2005.
[31] M. Webster. (undated). [Online]. Available:
[32] K. Beck, et al. (2001, February 22). Manifesto for
Agile Software Development. Available:
[33] B. Boehm, "Get ready for agile methods, with care,"
Computer, vol. 35, pp. 64-69, 2002.
[34] R. N. Charette, "Why software fails," IEEE
spectrum, vol. 42, p. 36, 2005.
[35] R. Hoda and L. K. Murugesan, "Multi-level agile
project management challenges: A self-organizing
team perspective," Journal of Systems and Software,
vol. 117, pp. 245-257, 2016.
[36] G. Melnik and F. Maurer, "Comparative analysis of
job satisfaction in agile and non-agile software
development teams," in International Conference
on Extreme Programming and Agile Processes in
Software Engineering, 2006, pp. 32-42.
[37] D. Larsen, "Team agility: exploring self-organizing
software development teams," Industrial Logic and
The Agile Times Newsletter, http://www/.
com/resources/TeamAgilityAgileTimesFeb04. pdf,
[38] Z. Masood and S. Farooqi, "Benefits and key
challenges of agile project management under recent
research opportunities," International Research
Journal of Management Sciences, vol. 5, pp. 20-28,
[39] T. Dingsøyr, T. E. Fægri, T. Dybå, B. Haugset, and
Y. Lindsjørn, "Team Performance in Software
Development: Research Results versus Agile
Principles," IEEE Software, vol. 33, pp. 106-110,
[40] N. A. Bonner, N. Kulangara, S. Nerur, and J. T.
Teng, "An Empirical Investigation of the Perceived
Benefits of Agile Methodologies Using an
Innovation-Theoretical model," Journal of
Database Management (JDM), vol. 27, pp. 38-63,
[41] S. Balaji and M. S. Murugaiyan, "Waterfall vs. V-
Model vs. Agile: A comparative study on SDLC,"
International Journal of Information Technology
and Business Management, vol. 2, pp. 26-30, 2012.
[42] M. Friesl and W. Kwon, "The strategic importance
of top management resistance: Extending Alfred D.
Chandler," Strategic Organization, vol. 15, pp. 100-
112, 2017.
[43] V. Stray, D. I. Sjøberg, and T. Dybå, "The daily
stand-up meeting: A grounded theory study,"
Journal of Systems and Software, vol. 114, pp. 101-
124, 2016.
Page 5444
... The agile project manager places greater emphasis on servant leadership that empowers, encourages and supports the team. The notion of command and control has no place in an agile environment (Bishop et al., 2018). The biggest challenge for the project manager is to strike a balance between the individual team members' autonomy within self-organising teams and the organisational strategies. ...
... The use of agile is becoming popular in a world demanding support for constant change and innovation (Bishop et al., 2018). The adoption of agile is driven by several influential factors such as project size, complexity, employee skillset, organisational culture and Industry 4.0 (Bishop et al., 2018). ...
... The use of agile is becoming popular in a world demanding support for constant change and innovation (Bishop et al., 2018). The adoption of agile is driven by several influential factors such as project size, complexity, employee skillset, organisational culture and Industry 4.0 (Bishop et al., 2018). Transitioning from a more traditional way of implementing projects to an agile environment where projects are delivered in an iterative way does not happen overnight. ...
In a fast-paced and changing world demanded by Industry 4.0, the continuous delivery of products and level of integration of technologies are required. This is achieved through the introduction of agile but agile itself demands changes in the way projects are managed. The role of the project manager itself is changing from a command and control to a collaborative and coaching style of leadership. Project teams on the other hand should be self-organizing and self-directed to be agile. Managing agile teams requires a different approach as the idea is to deliver workable solutions and products at a faster space. New project manager skills and competencies are required as well as ways to manage agile teams. A conceptual model is introduced, highlighting the required enablers for an agile environment. The enablers have an impact on how the agile project manager interacts with the agile team. The end result is that products are faster deployed enabling organizations to react to the changes demanded by Industry 4.0.
... The agile project manager places greater emphasis on servant leadership that empowers, encourages and supports the team. The notion of command and control has no place in an agile environment (Bishop et al., 2018). The biggest challenge for the project manager is to strike a balance between the individual team members' autonomy within self-organising teams and the organisational strategies. ...
... The use of agile is becoming popular in a world demanding support for constant change and innovation (Bishop et al., 2018). The adoption of agile is driven by several influential factors such as project size, complexity, employee skillset, organisational culture and Industry 4.0 (Bishop et al., 2018). ...
... The use of agile is becoming popular in a world demanding support for constant change and innovation (Bishop et al., 2018). The adoption of agile is driven by several influential factors such as project size, complexity, employee skillset, organisational culture and Industry 4.0 (Bishop et al., 2018). Transitioning from a more traditional way of implementing projects to an agile environment where projects are delivered in an iterative way does not happen overnight. ...
In a fast-paced and changing world demanded by Industry 4.0, the continuous delivery of products and level of integration of technologies are required. This is achieved through the introduction of agile but agile itself demands changes in the way projects are managed. The role of the project manager itself is changing from a command and control to a collaborative and coaching style of leadership. Project teams on the other hand should be self-organizing and self-directed to be agile. Managing agile teams requires a different approach as the idea is to deliver workable solutions and products at a faster space. New project manager skills and competencies are required as well as ways to manage agile teams. A conceptual model is introduced, highlighting the required enablers for an agile environment. The enablers have an impact on how the agile project manager interacts with the agile team. The end result is that products are faster deployed enabling organizations to react to the changes demanded by Industry 4.0.
... Inefficiencies of those methodologies forced the introduction of a new software development methodology that separates the development process into several sprints called Agile methodology. It reduces the problems of previous methods by encouraging adaptive planning, continual improvement, and deliver projects with less time to the customer [4]. However, again IT project managers could find inefficiencies of this Agile methodology. ...
... Traditional software development methodologies such as the Waterfall method apply a sequential method for developing Software. Therefore, it was not allowed rapid changes and poorly supported to increase the efficiency of the software development process [4]. According to the previous studies, user involvement is important over the IT project development life cycle and those requirements were caused by the origin of Agile methodology [7]. ...
... These projects are extremely dynamic and complex, involving many stakeholders that can impact or be impacted by them (Bosch-Rekveldt et al. 2011;Feige et al. 2011;Sanderson 2012;Flyvbjerg 2014;Chan and Oppong 2017;PMI 2017). Therefore, project managers should pay enough attention to stakeholders' expectations to engage with them successfully (Widén et al. 2014;Park et al. 2017;Xia et al. 2017;Bishop et al. 2018). Because every stakeholder may have abundant and diverse expectations, managers must fulfill their expectations in a proper manner and at the right time. ...
Full-text available
Stakeholder satisfaction in megaprojects has always been a critical concern in research and practice because of the dynamism, complexity, and uncertainty of the various relationships between the project and the stakeholder community. The most successful outcome for a megaproject would be achieved when it creates values fairly for stakeholder community to satisfy them. Therefore, because of the resource constraints, megaprojects should create value for stakeholders proportional to the value that they put into it. This article proposes a framework for priority setting in stakeholder engagement based on the balance of mutual value creation between the megaproject and stakeholder community. In this way, we developed an innovative and systematic approach by drawing on stakeholder theory, value creation theory, expectation disconfirmation theory, and fuzzy set theory while adopting from data envelopment analysis (DEA) concepts. This study contributes to the theory and practice of engineering management by examining stakeholder engagement to satisfy stakeholders fairly in megaprojects. Particularly, this study categorizes stakeholders based on the proportion of their salience to expectations to three main types: Modest, Fair, and Demanding. This typology will provide a road map for managers to prioritize the responses to stakeholders’ expectations. Finally, we applied the proposed approach for a real case of a megaconstruction project (MCP).
... In many large organizations, interdisciplinary teams whose members are often located thousands of kilometers away from each other are typically attempting to implement agile projects. Agile project management is seen as the answer to the growing dynamics of change and the emphasis on delivering results faster (Bishop, Rowland, & Noteboom, 2018). Increasingly, however, hybrid methods are used that combine elements of classic project management (PM) methodologies (such as Work Breakdown Structure (WBS)) with agile methods that allow for obtaining results in the shortest time possible (Münch, 2018). ...
This article considers the important role of digital communication in interdisciplinary projects. This paper describes the experience of interdisciplinary project teams and points to the consequences of the choice of communication channels and tools influencing project deliverables within those teams. The first section of this paper considers the influence of digital transformation on project management. The second section describes key project success factors concerning all types of projects and concludes that communication is one of important factors. The third section briefly defines interdisciplinary projects: SQUAD and BIM. This section also describes the communication methods and techniques that were used within these projects. Finally, the thesis that communication is one of the key factors of an interdisciplinary project’s success is confirmed. null The creation of the English-language version of these publications is fi nanced in the framework of contract No. 607/P-DUN/2018 by the Ministry of Science and Higher Education committed to activities aimed at the promotion of education.
A COVID-19 következtében megváltozott a világ működése, az együttműködési keretek és módok. A koronavírus bebizonyította, hogy minden szervezetnek képesnek kell lennie a nagyobb, előre nem látható zavarok és a környezeti változások, a bizonytalanságok kezelésére. A nemzetközi szakirodalomban több kutatás vizsgálta, hogy a COVID-19 milyen hatással volt az agilisan működő szervezetekre, illetve több tanulmány is arra mutat rá, hogy az agilitás nagyon hasznos megoldás volt számos COVID-19 válságot átvészelő szervezet számára, mivel az agilis csapatok, illetve szervezetek hosszú távon tudtak építkezni a dinamikusan változó turbulens környezetben is. A hazai szakirodalomban azonban nem esik szó arról, hogy a vírust megelőzően az otthoni távmunkavégzést kevésbé alkalmazó, agilisan működő kis szoftverfejlesztő cégekre, csapatokra milyen hatással voltak a COVID-19 által generált változások és milyen módon válaszoltak e változásokra a szervezetek. Jelen tanulmány elsősorban ezekre a kérdésekre keresi a választ és szeretné pótolni ezt a szakirodalmi űrt.
Conference Paper
Full-text available
The use of 3-Dimensional (3D) printing, known as Digital fabrication (DF) or additive manufacturing (AM), technology in the food sector has countless potential to fabricate 3D constructs with complex geometries, customization, and on-demand production. For this reason, 3D technology is driving major innovations in the food industry. This paper presents the construction of a chocolate 3D printer by applying the pressure pump technique using chocolate as a printing material. Here the conventional 3D printer’s design was developed as a chocolate 3D printer. As an improvement, a new extruder mechanism was introduced. The extruder was developed to print the chocolate materials. In the working mechanism, the 3D printer reads the design instruction and chocolate material is extruding accordingly, through the nozzle of the pump to the bed of the 3D printer followed by the design (layer by layer). The special part of this chocolate 3D printer is the pressure pump in the extruder part. That pressure pump provides pressure on melted chocolate from the chocolate container to the nozzle point. The usability and efficiency of the 3D printer were tested with sample designs. The obtained results were presented and discussed. Together with these advances this 3D printer can be used to produce complex food models and design unique patterns in chocolate-based sweets by satisfying customers.
Full-text available
Agile teams are not meant to have project managers. Instead, agile methods such as Scrum and XP define roles such as product owner, scrum master, and coach. Studies have uncovered the existence of the project manager in agile projects, pointing to disconnect between theory and practice. To address this gap, a Grounded Theory study with a mixed methods approach was conducted using multiple sources of data including over 45 h of interviews with 39 software practitioners and quantitative data from 57 questionnaire respondents. We present and describe the project manager’s role in agile projects in terms of (a) everyday activities: facilitating, mentoring, negotiating, coordinating, and protecting, performed by the project manager using; (b) three management approaches: hard, moderate, and soft; (c) four traditional project management activities continued to be performed by them, including: tracking project progress, reporting on project status, budgeting and forecasting, and managing personnel; and (d) the influence of the presence of the project manager on the frequency with which agile activities are carried out by the teams. Our study highlights the continued presence of the role of the project manager in agile software projects as a part of the transition from traditional to agile ways of working.
This article is intended to serve as an introduction to this special issue on agile practices. In doing so, we briefly survey a number of key issues that are emerging in the application of agile practices to software development (SWD) and, similarly, examine recent work on extending knowledge about these practices to other task domains. We note that the extant literature on agile practices has been criticized for lacking a theoretical basis and comment on various ways that a theory orientation can enhance the accumulation of knowledge in this area. We also address issues that expand our current understanding of agile practices as they apply to non-SWD tasks. We present a framework for surfacing and discussing some of these emergent issues. We comment on the articles in this special issue and situate them within the research framework. We discuss some of the topics we think are likely to become influential as agile practices move outside the SWD domain and, finally, we present some summarizing observations.
Full-text available
Frequent changes in project environment have made it increasingly difficult for project managers to use tradition project management methods that emphasize on development of rigorous plans and installation strict control mechanisms for ensuring there are no deviations. Agile project management (APM) has been recommended as alternative to the traditional approaches. In APM, teams use flexible and iterative approaches in implementing projects, which enable them to adjust plans in line with changes in the project environment. The purpose of this paper was to examine the benefits and challenges of using APM. It was found that APM methods present numerous benefits including reduction in the cost of rework, fast completion of projects, and greater customer satisfaction. However, the use of APM method is limited by challenges such as difficulties in scheduling tasks, difficulties in managing knowledge, and difficulties in managing large and multi-site projects. These challenges can be surmounted by blending elements of traditional project management into the agile methods.
Purpose Early research into Agile approaches explored particular practices or quantified improvements in code production. Less well researched is how Agile teams are managed. The project manager (PM) role is traditionally one of “command and control” but Agile methods require a more facilitative approach. How this changing role plays out in practice is not yet clearly understood. The purpose of this paper is to provide insight into how adopting Agile techniques shape the working practices of PMs and critically reflect on some of the tensions that arise. Design/methodology/approach An ethnographic approach was used to surface a richer understanding of the issues and tensions faced by PMs as Agile methods are introduced. Ethnographic fiction conveys the story to a wider audience. Findings Agile approaches shift responsibility and spread expert knowledge seeming to undermine the traditional PM function. However, the findings here show various scenarios that allow PMs to wrest control and become more of a “gate-keeper”. Ethnographic fiction communicates a sense of the PMs frustration with the conflict between the need to control and the desire for teams to take more responsibility. Originality/value Stories provide insight and communicate the experiential feel behind issues faced by PMs adopting Agile to surface useful knowledge. The objective is not how to measure knowledge, but how to recognize it. These reflections are valuable to fellow researchers as well as practitioners and contribute to the growing literature on Agile project management.
There is little doubt that agile software development (ASD) methods have gained widespread acceptance in industry. Despite the attention these methods have received, there is little empirical affirmation of the benefits that accrue to those who use agile methodologies. Grounded in the conceptual foundations of innovation diffusion and agile philosophy of development, the authors' study validates a model to assess the perceived advantage of an iterative approach to software development. Consistent with their predictions, the results suggest that evolutionary development - the cornerstone of agile development - is perceived to be less complex and more compatible with the work habits of developers. Further, the findings support the hitherto unsubstantiated claim that iterative development yields benefits to software developers. However, process flexibility, yet another important characteristic of agile development, had no significant impact on complexity, compatibility, and relative advantage. The implications of the study for academics and practitioners, and directions for future research are discussed.
We investigate the role of top management resistance against bottom-up initiatives for strategic change. While resistance has been mostly considered leading to inertia and rigidity by maintaining a particular strategic path, some scholars make the counterintuitive point that resistance could also be a facilitator of change. In this essay, we argue that such a generative perspective of top management resistance has important implications for strategy research. To do so, we draw on Alfred D. Chandler’s historic account of the emergence of the M-form at DuPont at the beginning of the 20th century. Based on this case, we illustrate three generative mechanisms of top management resistance for strategic change: the reframing, restructuring and the recoupling of strategic initiatives. We build on these generative mechanisms in order to develop implications for future research.
Agile methods are gaining widespread use in industry. Although management is keen on adopting agile, not all developers exhibit preference for agile methods. The literature is sparse in regard to why developers may show preference for agile. Understanding the factors informing the preference for agile can lead to more effective formation of teams, better training approaches, and optimizing software development efforts by focusing on key desirable components of agile. This study, using a grounded theory methodology, finds a variety of categories of factors that influence software developer preference for agile methods including self-efficacy, affective response, interpersonal response, external contingencies, and personality contingencies. Each of these categories contains multiple dimensions. Preference rationalization for agile methods is the core category that emerges from the data. It informs that while the very essence of agile methods overwhelmingly and positively resonates with software developers, the preference is contingent on external and personality factors as well.
Team performance has been studied in many disciplines, from management science and organizational psychology to information systems. Key findings from research in these disciplines have included the importance of establishing a common mental model in a team. Many studies in other disciplines have investigated software development teams because they’re examples of knowledge work in an innovative setting. Here, we review scientific studies of factors influencing colocated teams’ performance and propose five factors that strongly affect performance. We also compare these propositions with the Agile Manifesto’s software development principles. Our propositions are relevant for practitioners, project managers, and software development researchers.
Agile software development advocates self-organizing teams that display high levels of autonomy. Self-organizing agile teams are meant to share project management activities such as estimation, planning, and requirements elicitation with managers and customers. While prior literature has explored some individual management-related issues, little is known about how the high involvement of self-organizing agile teams influences everyday project management activities. Through a Grounded Theory study involving 21 agile practitioners across six software companies implementing scrum and XP, we identified a set of eight project management challenges as experienced by and as a result of self-organizing agile teams at multiple levels. These include delayed/changing requirements and eliciting senior management sponsorship at the project level; achieving cross-functionality and effective estimations at the team level; asserting autonomy and self-assignment at the individual level, and lack of acceptance criteria and dependencies at the task level. A mapping between the emergent challenges and standard project management activities is also presented. The article also shares practical implications and guidelines for agile teams, their managers, and customers for overcoming some of these challenges.