1
CHAPTER 1. INTRODUCTION
Introduction to the Problem
Project management has been around for centuries, but only within the last two
decades has it been considered a discipline with defined processes and professional
certification requirements (Hodgson, 2002; Morris, Crawford, Hodgson, Shepherd, &
Thomas, 2006). Initial project management best practices were based on linear processes
such as manufacturing, construction, and military acquisition, all of which typically had a
stable requirements base. The standardized process methodology used to manage these
efforts provided a highly controlled and predictable framework to guide the project from
conception to completion. Software development programs have attempted to use this
approach to manage uncertainty by clearly defining the desired end state and developing
detailed plans at the beginning of the project, and then executing them as written (Nerur,
Mahapatra, & Mangalaraj, 2005).
Unfortunately, these traditional methods do not work as well in software
development projects because they are generally not stable or predictable. This
methodology mismatch results in a high failure rate, often attributed to an inability to
respond quickly to changing technical and functional requirements (Lindstrom & Jeffries,
2004). For commercial projects, failure can result in missed opportunities and profit loss,
but for government projects, failure directly affects taxpayers. For example, the United
2
States Government Accounting Office (2008) reported a cost of $25.2 billion dollars
because hundreds of programs were failing or underperforming.
Background of the Study
Traditional project management methodologies that are appropriate for stable,
predictable projects are not as appropriate for software development projects. A reason
for the inconsistency in methodologies is that software development is inherently
uncertain. For example, because software is intangible, it is difficult for users to define
the desired product at the beginning of the project. In addition, the high level of
complexity associated with software development can result in unforeseen technical
issues. In an attempt to increase the probability of success for these unpredictable
projects, agile development methods were created which included loosely controlled
processes, minimal up front planning, and decentralized decision making (Meso & Jain,
2006). Two popular processes are eXtreme Programming, which focuses on software
product development, and Scrum, which focuses on managing the software development
project (Salo & Abrahamsson, 2008). These processes allow software requirements and
design to evolve over the life of the project instead of being constrained by a pre-
specified plan. For a project manager, this means that they no longer have a defined end-
state to measure progress against or have total command and control over the
development process, yet they are still responsible for the project’s success.
Transition to agile development can be difficult for a project manager accustomed
to a highly structured, plan-driven methodology. For project managers, knowing how the
project is progressing within stated cost and schedule constraints to achieve the specified
goals provides a sense of control and competence, even if the predictive approach is
3
ineffective (Bourne & Walker, 2005). The absence of these detailed planning documents
can create ambiguity, and possibly make the project manager feel inept. Increased
uncertainty associated with the more dynamic agile process methodology may cause
stress and job dissatisfaction for the project manager, or it could have the opposite effect
and be exhilarating. Understanding how project managers emotionally deal with the
complexity and uncertainty of this new approach can help organizations recruit and
develop project managers who best fit this environment (Sauer & Reich, 2009). There are
many technical documents written on the benefits of this development method for
software developers (Alberto, 2009; Chow & Cao, 2008; Dyba & Dingsoyr, 2008), but
there is a lack of scholarly research concerning how managers experience this high rate of
uncertainty.
Purpose of the Study
The purpose of this phenomenological study is to describe and understand the
experiences of decision uncertainty for project managers of agile software development
teams. This study contributes to the body of knowledge concerning the psychological
aspects of project management, by attempting to address the gap in previous literature on
the uncertainty effect of the agile methodology on project managers. It also provides a
strong foundation to launch additional research into how individuals manage complex,
dynamic situations in the workplace.
Significance of the Study
Industrial/organizational psychologists have conducted numerous studies on
project management. These include topics such as identification of change agent
4
competencies for IT project managers (Kendra & Taplin, 2004), differences in cognitive
styles between male and female project managers (Tullett, 1995), and the cultural
influence on data sharing in project teams (Sackmann & Friesl, 2007). However, there is
little research available on how agile software development methods affect project
managers.
In an effort to increase the success rate of software development efforts, many
organizations are moving away from traditional software development methodologies,
which have been found to be too rigid, and transitioning to agile methods. This transition
can be difficult for a project manager who was used to a highly structured, plan-driven
methodology. The unpredictable workflow may cause increased stress and job
dissatisfaction, or it may result in a sense of job fulfillment and satisfaction for the project
manager.
There may be multiple explanations for this difference in perception, such as
locus of control, personality, coping strategies, or willingness to accept risk. For example,
an internal locus of control can help ease stress associated with uncertain environments
because the individual feels they have the power to control the outcome (Kammeyer-
Mueller, Judge, & Scott, 2009). Personality type may also play a role in how comfortable
an individual is with ambiguity (Bouckenooghe, Vanderheyden, Mestdagh, & Laethem,
2007). Coping mechanisms can be associated with the individual’s error orientation, or
their willingness to make errors in order to learn, balanced against their ability to accept
risk (Arenas, Tabernero, & Briones, 2006), or how proactively they manage the stressors
(Aspinwall & Taylor, 1997). Another possibility is that in a non-rational situation, some
project managers may be more comfortable using their intuition to make decisions than
5
others (Leybourne & Sadler-Smith, 2006). Understanding the experiences of project
managers who make decisions under great uncertainty can help uncover patterns
associated with uncertainty stressors as well as beneficial coping mechanisms to deal
with them. The research results might be used to develop assessment tools to hire project
managers best suited for uncertain environments, develop training programs for project
managers who are transitioning to agile software projects, and provide direction for
future research in agile project management.
Research Design
A qualitative approach has been selected for the study. This is the best approach
because the research question focuses on understanding the experience of uncertainty that
managers deal with in projects that use an agile software development methodology.
Qualitative research can be used to understand the human aspect of this problem since
analysis is based on first-hand narratives from the participants (Creswell, 2007). The
research problem, because of its relative newness in the field of software development
and project management, is not well addressed in the scholarly literature. Qualitative
research may be ideal as an initial approach to understand this situation, because there is
not sufficient information to conduct an empirical study (Patton, 2002). This study can
provide a basis for future research to include quantitative studies.
Phenomenology is the specific qualitative design that has been selected for the
study. This approach is appropriate when there is little information available on a
particular topic. It provides a method to study and understand the phenomenon through
first-hand accounts of individuals who have experienced it in their daily lives (Kostere &
Percy, 2006). In this particular topic, it offers a holistic analysis of the experience of
6
uncertainty associated with management of software teams that utilize the agile
development methodology.
The key focus of the study was the experience of decision making under
uncertainty for agile software development project managers. There were three main
elements of interest: (a) decision making processes, (b) agile software development, and
(c) project management. This study examined how project managers experience
uncertainty when using an agile software development methodology. The unit of analysis
was the individual. Nine project managers of agile software teams were selected as
participants. They were purposefully chosen based on their role as a project manager of a
Scrum agile software development effort. Of the available agile methodologies, Scrum
was selected because it is an agile software management framework, and that it provided
a common context among all of the participants. Focusing on this methodology reduced
variance in the sample. Data collection was accomplished via individual telephone
interviews. Interview observation notes that documented the participant’s reaction to the
questions and the interview setting were recorded. Data was analyzed in accordance with
Moustakas’ (1994) phenomenology research approach. This approach is defined by
reviewing the data and identifying each topic-related statement, defining the meaning
units from the topic statements, grouping the meaning units into themes, and then
building the textual and structural descriptions of the experience of uncertainty.
Definition of Terms
The following conceptual definitions were used in this study:
Agile software development. A process to develop high quality software based on
principles of rapid and continuous software design and testing, in order to accommodate
7
evolving user requirements (Nerur et al., 2005). The process allows the user to evolve
and refine their ideas and concepts through many small design and development cycles.
Decision making processes. These processes consist of choosing among
alternative options with the goal of choosing one that will ensure the highest probability
of achieving the objective. The decision process can be based on established rules, or
decision maker preferences based on emotions or previous experiences (Mellers,
Schwartz, & Cooke, 1998).
Project management. “The application of knowledge, skills, tools and techniques
to project activities to meet the project requirements” (Project Management Institute,
2008, p. 8). The Project Management Institute (PMI) is an international professional
organization that has developed a set of processes and procedures that are used for project
manager certification. This information is based on the traditional or rule-based project
management approach that specifies and documents the intended product up front, and
then builds the product in accordance to the detailed plan (Nerur et al., 2005).
Research Questions
The main research question was, “How do project managers experience and
describe decision uncertainty associated with the agile software development
methodology?” The key phenomena – decision-making processes, agile software
development, and project management - were observed during the interviews. The
primary interview question was “As a project manager of an agile software development
team, what kind of personal experiences did you have with decision uncertainty?” The
following guiding questions, categorized by the area of interest, were used to gain a
deeper understanding.
8
1. Project management
a. Tell me about your background and experience as a project manager?
b. What about you, such as your personality traits, or your ability to solve
problems, led to your selection for the project manager position?
2. Agile software development
a. What do you think led your organization to adopt agile practices?
b. What is your background and experience leading agile development
teams?
c. When you first learned that you were going to be leading an agile
development project, what were your thoughts and concerns?
3. Decision making processes
a. Once your project got underway, what were the things that kept you up at
night?
b. Tell me about what it was like for you to deal with ______ (pick one of
the concerns mentioned in the previous question) in a typical day, or in a
critical event that happened to you.
c. What was it like for you as the project progressed?
d. What have you learned about yourself, specifically your ability to handle
the ambiguity of leading an agile development project?
Assumptions and Limitations
Assumptions
Topical assumptions. Based on initial research, it was assumed that there was
limited or nonexistent research on the study topic. The need for qualitative project
management research was identified (Cicmil, Williams, Thomas, & Hodgson, 2006), yet
it appeared that none had been produced for either traditional or agile project
management. In addition, it was assumed that project managers experience decision
uncertainty on an agile software development team based on the researcher’s personal
experience as well as that of an agile project management expert (S. Broderick, personal
communication, May 2009).
9
Methodological assumptions. It was assumed that this is a complex research
problem and that a phenomenological analysis was the best methodological approach to
understand how project managers deal with decision uncertainty. It was assumed that the
researcher would be able to obtain a representative participant sample who would be
reflective and able to clearly articulate their experiences.
Limitations
The research topic is relatively new, so most of the available literature was in the
open press rather than in academia. This was a potential limiting factor, and required the
search to extend beyond the psychology domain into business and technology. An
additional limitation of the study, a common one for qualitative research, was that the
results might not generalizable due to the small sample size and the subjective nature of
the data collection.
Organization of the Remainder of the Study
The remaining four chapters of this document describe the research to understand
the lived experiences of project managers who lead agile software development teams.
Chapter 2 provides a synthesis of relevant research related to, or supporting this study.
Chapter 3 provides details on the study methodology and design. Chapter 4 presents the
data analysis and results, and chapter 5 offers conclusions of the study results and
recommendations for future studies on the research topic.
10
CHAPTER 2. LITERATURE REVIEW
This chapter addresses literature relevant to the study research question,
specifically: “How do project managers experience and describe decision uncertainty
associated with the agile software development methodology?” Since this study used a
qualitative research approach, the purpose was to discover new information based on the
participant’s experiences of a specific phenomenon rather than to validate previous
knowledge or theories (Creswell, 2007; Patton, 2002). The literature review provides a
thematic framework to explore and understand the experiences of agile software
development project managers, something not currently addressed in the scholarly
literature. This study is important in a larger context of Industrial/Organizational
Psychology because, as Hartman (2008, p. 267) stated, “A project manager’s primary tool
is their mind. Finding new ways to prepare the mind for effective project management is
needed if we want to advance the profession.”
Literature for this review was selected based on relevance to the research topic of
managing projects under uncertainty. This included data collection from multiple
domains such as manufacturing, software development, mathematics, business
management, and psychology. Literature from each of these domain areas included
scholarly sources, most of which were published in the last five years, as well as primary
non-scholarly sources such as those from agile software development thought leaders.
This collection of sources was reviewed and analyzed to build an integrated framework
11
for the data collection and analysis aspects of this study. The researcher’s point of view
during the review was as a project management practitioner who was trying to call
attention to the psychological needs of managing a project in an uncertain and ambiguous
environment. To focus the review, topics were organized from general to specific in the
following order: (a) complex adaptive systems, (b) new product development, (c)
traditional project management, (d) agile project management, and (e) decision
uncertainty. There was some overlap among these topics, and the intent was to show
these relationships and to build a strong conceptual foundation for the remainder of the
study.
The first topic, complex adaptive systems, was developed at the Santa Fe Institute
in the 1960s (Anderson, 1999). This theory was originally focused on the natural
sciences, but is also applicable to a wide variety of domains to include psychological
research in the development of the nervous system (Holland, 1995), knowledge transfer
(Goldstone & Sakamoto, 2003), and psychotherapy (Anchin, 2008). For this study, the
focus was on managing and leading in dynamic and uncertain organizational
environments, so the characteristics of complex adaptive systems were relevant.
The second topic, new product development, was focused on conceptualizing and
creating new products in order to meet customer or market demands. This included
developing and manufacturing tangible products such as, but not limited to, automobiles,
household appliances, and food products, and also included intangible products such as
software programs and systems. This process was traditionally based on a linear plan-
driven methodology, but in the 1980s, researchers such as Takeuchi and Nonaka (1986)
12
began addressing process changes needed to manage highly dynamic, uncertain
environments.
The third topic, project management, was related to new product development
because it is a process associated with creating something new (Project Management
Institute, 2008), but instead of focusing on the development of the product, it is used to
manage the overall project and ensure that it is successfully completed. As with new
product development, it has also evolved from a traditional plan-driven methodology.
However, increased complexity and uncertainty, especially in software development
programs have resulted in process changes. This alternate approach, called agile, changed
the project manager’s role from the traditional command and control approach, to a coach
or facilitator focused on enabling and facilitating the software development team, and
with building and managing relationships as the team “ambassador” (De Meyer, Loch, &
Pich, 2002, p. 63). However, in this environment, the project manager must also be able
to manage the psychological effects of decision making under uncertainty. This topic is
addressed in the final section, which discusses how uncertainty might influence project
managers of agile software development teams.
Complex Adaptive Systems
An understanding of complex adaptive systems theory is relevant to this study,
because organizations need the ability to manage and lead in dynamic and uncertain
organizational environments. Technological and economic changes are increasing and
organizations that cannot adapt do not survive (Biedenbach & Soderholm, 2008). As the
economic market becomes more competitive and technology innovation increases, many
organizations are moving away from the traditional mechanical or probabilistic view of
13
management towards one that is more organic. This evolution may be a result of the
transition from an industrial to knowledge-based economy (Uhl-Bien, Marion, &
McKelvey, 2007). This shift requires management and leadership to become more
adaptive to internal and external change and place more emphasis on flexibility rather
than on accuracy (Miller & Page, 2007). This organic view of the environment provides
the foundation for the remainder of this literature review by describing the uncertain and
ambiguous situation in which agile software developers must operate. This section first
discusses the background of the complex adaptive concept, and then describes how it is
relevant to new product development and project management practices.
Complex Adaptive System Characteristics
Leading scientists, such as Murray Gell-Mann, a physicist, and John Holland, a
computer scientist and a psychologist (Holland, 1998) developed complex adaptive
system theory at the Santa Fe Institute. The theory was built upon systems theory, as
defined by von Bertalanffy (1968), that acknowledged systems were complex, but the
new theory added that systems organically adapt to their environment in a manner similar
to that of biological systems (Holland, 1995). This adaptation included behaviors that
were non-linear and unpredictable. The definition of complex adaptive system theory is
relatively abstract, resulting in differences of opinion on how to describe it. Murray Gell-
Mann (1994), one of the theory developers, acknowledged this by stating that scientists
use different terms to explain the same thing, and that they also have differing
perspectives on the concept meaning and definition. For example, John Holland (1995)
describes it as the following seven basic concepts:
14
1. As a way to simplify the system, the lower level activity is aggregated into
system categories or building blocks.
2. These aggregates are combined based on the tagging of the individual agents,
which defines similarities and boundaries among the aggregates, and defines
important interactions within the system. A flag is an example of a tag in that
it is “used to rally members of an army or people of similar political
persuasion” (1995, p. 13).
3. Activity within the system is non-linear, meaning that a small action can have
large unanticipated reactions.
4. There are flows of inputs and outputs in the system, and these vary over time.
5. There is great diversity, or heterogeneity in the system that can be defined as
“perpetual novelty” (1995, p. 31).
6. The agents, or elements of the system, have internal models or schemas that
define how they are supposed to act.
7. Known aspects of the system, such as the aggregates, can be combined in
various new ways similar to how a set of child’s building blocks can be
recombined into new structures.
Gell-Mann (1994), on the other hand, only focuses on the following four main
characteristics:
1. The system can be described as a data flow into the system, which can include
internal actions, and a data flow out of the system in the form of products and
system modifications.
2. Anomalies or unexpected behaviors can be overlooked or even misidentified
as normal behaviors.
3. Expected behaviors are packaged as schemas.
4. Schema behaviors are constantly reinforced and refined by system feedback.
These descriptions are similar in that there are data flows in and out of the system, and
that behavior within the system is based on models or schemas, but they differ in the
requirement for diversity and continual feedback.
Plowman et al. (2007) offer a composite definition of complex adaptive systems
that specifies the following: The system is made up of agents that interact in expected
and unexpected ways; that these behaviors are dependent on fluctuations from the initial
15
system environment; that the system fluctuates between equilibrium and chaos; and that
innovation and creativity emerge when the system nears chaos. Other important themes
of complex adaptive systems are that the whole of the system is more than the sum of the
individual parts (Anderson, 1999; Holland, 1998), and that the parts are interconnected in
non-obvious ways (Ford, 2008) so that a small change in one area can result in large
unexpected cascading changes in the overall system. This non-linear behavior can result
in agent and aggregate self-organization, as well as emergent system behavior (Holland,
1998).
Complex Adaptive Systems and Organizations
From an organizational standpoint, this concept introduces a radical departure
from the industrial-age style of bureaucratic management and leadership, which viewed
organizational members and processes as a well-controlled, predictable machine (Ugarte,
Agirre, & Juaristi, 2009). It assumed that the whole (such as a problem, project, or
organization) could be reduced into manageable pieces, and then recombined back into
the complete whole. Control was enforced through highly defined processes and
regulations, and change was introduced periodically in order to make corrections or
stabilize the system (Ford, 2008; Walker, Armenakis, & Bernerth, 2007). Learning in
these organizations was considered single loop (Argyris, 2002), meaning that it was to fix
mistakes or improve the existing processes. Once the change was implemented, the
system returned to status quo until another change was required.
In the knowledge era, organizations can be viewed as complex adaptive systems
(Anderson, 1999), especially when they encourage disequilibrium and move near the
edge of chaos (Ugarte et al., 2009). As mentioned previously, organizations near the edge
16
of chaos experience innovative, emergent behaviors. In these constantly changing
organizations, continuous learning is a mindset or culture that may help increase their
capacity for change (Meyer & Stensaker, 2006). Weick and Quinn define this as “a
pattern of endless modifications in work processes and social practice. It is driven by
organizational instability and alert reactions to daily contingencies” (1999, p. 366). In
other words, these organizations are constantly changing and learning, and are in a state
of continual disequilibrium.
The traditional controller leadership style (Plowman et al., 2007; Uhl-Bien et al.,
2007) assumes that the leader can remove ambiguity and uncertainty, and map out a clear
path for their followers. However, this style may be less useful in today’s highly complex
environment. Instead, these leaders need to act as a tag, as defined by Holland (1995),
that rallies and influences behavior of their followers to achieve the organization’s
strategic vision (Marion & Uhl-Bien, 2001). They need to become enablers or facilitators
(Plowman et al., 2007) to provide their followers what they need to succeed, and they
need to balance this with just enough control to ensure that the organization does not fall
into chaos (Augustine, Payne, Sencindiver, & Woodcock, 2005). This style of leadership
is similar to transformational leadership, defined by Yukl (1989, p. 269) as “influence by
a leader on subordinates, but the effect of the influence is to empower subordinates to
participate in the process of transforming the organization.” This style of leadership has
been correlated with success in highly innovative projects (Amason et al., 2007).
Relationship to New Product Development and Project Management
New product development, project management, and decision uncertainty, have
relationships with complex adaptive systems. For example, new product development
17
efforts that are highly innovative have complex adaptive system characteristics due to the
unknowns associated with development of novel products. McCarthy, Tsinpoulos, Allen
and Rose-Anderssen define this as “the principal role of NPD [new product development]
agents is to make judgments and choices that bridge the gap between an idea and reality”
(2006, p. 438). From a project management perspective, software development projects
can be considered complex adaptive systems (Augustine et al., 2005; Benbya &
McKelvey, 2006; Meso & Jain, 2006) due to their high level of complexity and
uncertainty. This is due to organizational interactions such as requirements change and
stakeholder involvement, and system interactions such as technological changes (Benbya
& McKelvey, 2006). However, the greatest source of complexity in a project may be the
organizational dynamics rather than the result of technology (Xia & Lee, 2004). An
understanding of the complex adaptive system framework can help project managers
embrace uncertainty and successfully lead a project in an ambiguous environment
(Benbya & McKelvey, 2006). The remainder of this chapter addresses each of these
topics in more detail to help establish a framework to understand the experiences of
project managers on agile software development teams.
New Product Development
In a highly competitive market, the ability to successfully develop and launch a
new product is critical to an organization’s survival (Brown & Eisenhardt, 1995; Craig &
Hart, 1992; Harmancioglu, McNally, Calantone, & Durmusoglu, 2007). New product
development processes and level of control differ based on the level of innovation. This
can range from minor changes to existing products, which may use a linear development
process, to the other end of the spectrum with groundbreaking new products, which may
18
need a completely different approach (Craig & Hart, 1992). This section defines several
of these processes, and then explains how uncertainty is controlled in each.
New Product Development Processes
The three commonly used new development process categories, as described by
Brown and Eisenhardt (1997) in their three decade meta analysis of new product
development processes are; (a) the rational plan which is focused on executing an overall
step-by-step approach to achieve a well defined end state; (b) communication web which
is focused on internal cross-functional team communication and knowledge transfer, and
through gatekeepers with external stakeholders; and (c) disciplined problem solving
which includes harmonizing the ability of the cross-functional team to solve problems on
their own with a strong “heavyweight”(1997, p. 359) project manager. These categories
are used to group model types described by Cunha and Gomes (2003) that range from
plan-driven to emergent.
Rational plan. Two types of rational plan processes are the sequential and
compression models (Cunha & Gomes, 2003). These are based on the stage-gate process,
the most well known new product development process, which includes decision points
or gates in between the linear process steps. The compression model is similar to the
sequential model in that a main planning assumption is that everything can be known up
front, but the steps are overlapped to reduce the project schedule and meet reduced
timelines (Cunha & Gomes, 2003; Eisenhardt & Tabrizi, 1995). Rational plan processes
are generally best for routine, well-defined development efforts, but not for those that
include excessive uncertainty or ambiguity (McCarthy et al., 2006).
19
Communication web. One way to handle product development complexity is to
increase collaboration and knowledge sharing among the team members. This is similar
to the system data flows described by both Holland (1995) and Gell-Mann (1994). For
these efforts, Cunha and Gomes (2003) propose a highly collaborative model called
integrative which includes coordination among all elements of the new product
development effort, not only within the cross-functional team, but with external
stakeholders as well.
Disciplined problem solving. Cunha and Gomes (2003) suggest two adaptive
model types for product development in complex environments, flexible, and
improvisational. Like the compression model discussed earlier, the flexible model
assumes high speed, but unlike the model, it accommodates uncertainty. It does this by
making design decisions as late as possible in the process, often developing multiple
options in parallel until enough is known to make a decision (Cunha & Gomes, 2003).
The improvisational model allows a cross-functional, self-managed team to operate and
solve problems in highly dynamic environments, structured around simple rules such as a
well-defined vision, team roles, and milestones (Cunha & Gomes, 2003). This
experiential or “act in order to think” (Weick, 1998) model, is similar to a jazz
performance (Ford, 2008) in that the end product will evolve during the project life cycle.
This process can help manage high uncertainty and ambiguity in the nebulous front end
of the effort (Koch & Leitner, 2008), but it can also lead to high levels of stress for the
team members (Cunha & Gomes, 2003) because it may be hard to make sense of what is
going on, or what to do next.
20
Controlling Uncertainty
It is a given that there will be uncertainty with creating a new product, especially
when it is compounded by market and technology uncertainty. An objective of these
processes is to reduce uncertainty associated with incomplete information and differing
interpretations of the same information (Brun, Saetre, & Gjelsvik, 2008). Therefore,
careful selection of an appropriate development approach is an important consideration.
For example, selection of a rational plan such as the stage-gate method may not be
appropriate due to what Takeuchi and Nonaka (1986) described as a relay race in which
one functional team hands the product off to the next at the end of each gate. For a
routine, well-understood project, such as incremental product improvement, this approach
may be acceptable. However, for an innovative or high change project, this approach will
hinder creativity and potentially slow down product development by holding decision
making to the end of a stage gate (Harmancioglu et al., 2007; Steffens, Martinsuo, &
Artto, 2007). Another factor to consider in methodology selection is the relationship
between project control and performance. Applying high control in a stable environment,
such as that inherent in traditional plan-driven methodologies may be an acceptable
practice, but not in dynamic or chaotic environments (Davis, Eisenhardt, & Bingham,
2009). In these unstable environments, control should be applied lightly to guide the
team, similar to the transformational leadership style previously mentioned. This may be
an uncomfortable change for a project manager who traditionally led a team by using a
command and control leadership style.
21
Traditional Project Management
In a similar fashion to new product development, project management is defined
as “a temporary endeavor undertaken to create a unique product, service, or result”
(Project Management Institute, 2008, p. 5). There is significant overlap between the two
processes. However, new product development success is generally defined as fielding
the product in a timely manner and having satisfied customers. In project management,
success is defined as completing the project within budget, schedule, and scope goals
(Baccarini, 1999). However, instead of using processes to design and build the product,
project management centers on processes and procedures to control the product
development so that it is successfully completed in accordance with customer goals. It is
the responsibility of the project manager to achieve these objectives (Project
Management Institute, 2008).
This section describes the history of project management, and the processes
defined by the Project Management Institute’s Project Management Body of Knowledge.
This set of processes and procedures is considered the de facto leader (Howell, Windahl,
& Seidel, 2010) due to its global proliferation and acceptance across multiple industries.
The second half of the section describes how uncertainty is controlled in this traditional
project management approach. This information provides a basis for the next section,
which explains an alternative approach called agile.
History
As mentioned in chapter 1, managing projects is not new. It has been around for
millennia, as evident in great architectural works such as the pyramids and the Great Wall
of China (Geraldi et al., 2008). In a manner similar to new product development, the
22
traditional method of project management is based on well-defined processes and
procedures and assumes that every problem is solvable (Nerur et al., 2005), but unlike
new product development, these processes have been standardized into a discipline or
profession over the last thirty years.
In the 1930s, project management practices started to become more well defined
as a result of construction projects such as the Hoover Dam (Kwak & Anbari, 2008);
however, these processes and procedures did not begin to become standardized until the
1960s. Early literature on this period dealt with accomplishing the project within the
constraints of scope, budget, and schedule, and by focusing on the processes and their
automation, with little mention of the customer or team dynamics (Jugdev & Müller,
2005). It was also during the late 1960s (Project Management Institute, n.d.) that the
Project Management Institute, now considered the leading global project management
professional organization, was created. During this period, project management followed
a military-like command and control style (Bourne & Walker, 2005), and the rational,
plan-based project management framework was being continually refined.
The popularity of project management helped it expand beyond engineering and
construction into the business domain, an environment that was typically more complex
(Bourne & Walker, 2005). The business domain included additional stakeholders,
competing requirements, and a product that may not be as well-defined as that in either
engineering or construction. Later, in the 1990s the focus began to include social science
theories and tools (Walker, Cicmil, Thomas, Anbari, & Bredillet, 2008) addressing
human management aspects of project management such as team development and
leadership, as well as refined processes on managing risk in complex, uncertain projects
23
(Kloppenborg & Opfer, 2002). This resulted in an introduction of social science theory
and tools into the project management discipline, and started a shift from following the
process steps precisely in order to ensure success, to managing the complex human
element of the project.
Controlling Uncertainty
As Atkinson, Crawford, and Ward state so succinctly, “Much good project
management practice can be thought of as effective uncertainty management, clarifying
what can be done, deciding what is to be done, and ensuring that it gets done” (2006, p.
688). The majority of this uncertainty is at the beginning of the project (Project
Management Institute, 2008), when there is limited understanding of the stakeholder
requirements, capabilities of the project team, and potential product technological or
design issues (Atkinson et al., 2006).
In a rational project management approach, as defined by the Project Management
Body of Knowledge (2008), this uncertainty is addressed in the planning stage through
estimation techniques to determine the schedule milestones and tasks, required
resourcing, and costs associated with the tasks. Potential risks are then identified and
prioritized, and a mitigation plan is developed for those that might have the biggest
impact on project success. Detailed project planning documents are then baselined and
placed under change management control. These documents are used to manage the
project, and corrections are made as needed to get the effort back on track, in other
words, the objective in this type of project is to maintain homeostasis (Ford, 2008). This
assumes predictability and that things will progress according to plan (Cicmil, Cooke-
24
Davies, Crawford, & Richardson, 2009), and that project problems are likely because the
processes were not adhered to adequately (Hodgson, 2002).
This rational approach assumes that the end state is well defined and that
executing a highly detailed plan will lead to success. However, it is a bit of a
contradiction that the Project Management Body of Knowledge (2008) defined a project
as a new venture, yet defines a set of standardized processes and procedures that assume
predictability (Kosaroglu & Hunt, 2009). In this situation, the project manager is
responsible for controlling the overall project activity and ensuring that everything is
progressing as planned. On projects with high uncertainty, a project manager must follow
an approach that is in opposition to the traditional plan-based practices of the profession.
Agile Project Management
History
The project management community has not been as quick to embrace an
alternative to the rational plan-based approach as new product development. Some
researchers (Benbya & McKelvey, 2006; Bourne & Walker, 2005; Cicmil et al., 2009)
have expressed their doubts about the utility of the traditional project management
process in contemporary organizations and projects. This includes statements that this
process is in contradiction to reality by assuming that everything can be known up front.
In complex, high change projects, it is not effective to decompose the objectives into
small pieces because they rapidly change, and doing so provides a false sense that each
element is known and controllable. By focusing on the minutia, the complexity of the
overall effort can be overlooked (Ivory & Alderman, 2005). As in complex adaptive
systems, the whole is more than the sum of the parts (Anderson, 1999; Holland, 1995).
25
One reason for delay in accepting alternatives may be that the accepted project
management methodology, as defined by the Project Management Institute’s Project
Management Body of Knowledge (2008), is considered the current paradigm. It is the
recognized “implicit body of intertwined theoretical and methodological belief” (Kuhn,
1970, p. 16) that currently defines the project management profession. Many project
managers still consider project failures the result of not following the traditional process
adequately rather than considering that the wrong process was selected for the effort
(Hodgson, 2002). On high velocity projects, some project managers will utilize the
rational-based schedule compression approach hoping that by squeezing the tasks closer
together they can achieve an aggressive timeline (Collyer & Warren, 2009). The Project
Management Institute (2008) calls this “crashing” (p. 156) or “fast tracking” (p. 157) and
cautions that these techniques can increase schedule risk and project rework.
Because of this narrow focus, many project managers may not consider an
alternative approach (Howell, Windahl, & Seidel, 2010) because it is not validated by the
professional project management community. The Project Management Body of
Knowledge is slowly including information that indicates acceptance of alternative
approaches to include references to “progressive elaboration” (2008, p. 5) that describes
iterative development and feedback loops (but only for prototype development), and an
appendix devoted to people skills such as team building and leadership. An increase in
human-focused aspects of project management may in time lead to a more emergent
approach.
26
Controlling Uncertainty
Due to the high rate of failure on software development projects, potentially
related to the intangible nature of the end product (Atkinson et al., 2006), alternative
product and project management practices were initiated. These are focused more on the
human resource management aspects of the project, to include communication, self-
managed teams, and leadership (Jugdev & Müller, 2005) as well as on reflection and
continual learning (Perminova, Gustafsson, & Wikstrom, 2008). These also focus on the
product itself, rather than the technical or mechanistic management of the project and its
resources (Legris & Collerette, 2006). Some consider these alternative approaches to be
undisciplined, but in reality, they are robust empirical processes that rely on continuous
change management processes (Geraldi et al., 2008). This again may be related to the
perception that this new approach is not in accordance with the accepted practices of the
project management discipline.
In the late 1990s, the software development community began to address the need
to change. In 2001, a group of 17 software developers, who called themselves the Agile
Alliance, drafted the Agile Manifesto that boldly defined a set of guiding principles for
agile methods (Beck et al., 2001). The purpose of this effort as described by Fowler and
Highsmith (2001, p. 29), two founding members of the Agile Alliance was that,
We are uncovering better ways of developing software by doing it and helping
others do it. We value: Individuals and interactions over processes and tools;
working software over comprehensive documentation; customer collaboration
over contract negotiation; and responding to change over following a plan.
This manifesto set the stage for a common set of principles and defined a group identity
for the agile community. The human aspect of this approach, in contrast to the
27
mechanistic focus of the traditional project management methodology, is a primary
reason for success on mature agile software development teams (Dyba & Dingsoyr,
2008).
Scrum Methodology Changes to the Project Management Role
One agile methodology, that is mostly project management (Dyba & Dingsoyr,
2009) focused, is called Scrum. As mentioned in the new product development section,
Takeuchi and Nonaka (1986) introduced this rugby metaphor in the late 80s as a way for
a cross-functional team to collectively move the ball down the field, in contrast to the
traditional functional relay race approach in which one functional team handed off the
product to the next at each phase gate. The software community built upon the metaphor
and tailored it into an agile project management methodology. This process was first
detailed in “Agile Project Management with Scrum” (Schwaber, 2004), and then in a case
study detailing how Primavera, a plan-based software development organization,
transitioned to the Scrum approach (Schatz & Abdelshafi, 2005). The Scrum process
consists of three primary roles (Schwaber, 2004):
1. The Product Owner. This individual provides the prioritized product
requirements, budget, and expected release dates.
2. The Team. A cross-functional, self-managed team who estimates and selects
the number of priority requirements that will be implemented in each Sprint,
or iteration.
3. The Scrum Master. Similar to a project manager role, but instead of being a
manager, this individual acts as the leader. This individual has indirect
authority through empowering and facilitating the team to achieve the project
vision, interacting with senior management, removing barriers to team
success, and ensuring that the team is following the Scrum methodology
correctly.
28
On Scrum development projects, the role of the project manager changes from a
command and control style intent on achieving the project plan, to facilitation of team
collaboration and removal of obstructions to the team’s success. Since the team is self-
managed, decision-making takes place at the team level, consequently moving control
from the project manager to the development team (McAvoy, 2009). Instead of focusing
on executing a detailed plan, as was the norm in traditional project management, the
Scrum Master ensures that the team is collaborating effectively among themselves and
with the Product Owner. They allow the team to focus on the project tasks, while they
maintain the vision or the whole of the project, and enable the team to deliver it (Jugdev
& Müller, 2005). A difficulty in this role change (Nerur et al., 2005) is that the project
manager may not be willing to give up the control and authority that they used to have.
Decision Uncertainty
Organizations are changing, and so is the way they are doing work. There is an
acceptance of change rather than fighting it, and this is changing the way that projects are
being managed. This moves away from a mechanistic approach to one that is organic and
can adapt to the changing environment (Ford, 2008). This new work environment
embraces the concepts of complex adaptive systems theory. For the traditional project
manager who used well established processes and tools to define and control the project,
this shift to a change embracing project environment can introduce anxiety and decision
uncertainty (Cicmil et al., 2009) because they no longer have everything planned out.
They no longer control the project execution.
29
Project Manager Role Change
Traditional project management, such as that embodied by the Project
Management Institute, is considered the accepted professional paradigm. Certification
granted through this organization is based on procedural and tool knowledge, most of
which is left-brain oriented (Hartman, 2008), but includes little on the human aspects of
project management (Geraldi et al., 2008), such as leadership and team building. This is
acceptable for a plan-driven approach, but is inadequate for an agile project manager
whose primary task is to lead the project team. Traditional project management followed
an episodic or controlled change approach that made corrective changes to re-align the
project to the baseline plan. However, agile project management requires continual
change as the project evolves which can take an emotional toll on the team and the
project manager (Diefenbach, 2007). This change from performance goals to learning
includes a change in the team’s error orientation (Arenas, Tabernero, & Briones, 2006)
from avoidance on traditionally managed projects, to that of a continual learning. This
continual change approach is similar to the adaptive or improvisational environment as
described in the new product development section, which accommodates continual
change.
Another major change for the agile project manager is the loss of control over the
project performance and team members. The comfort of following a specific
methodology and measuring project performance against it provides a sense of order,
predictability, and competence. However, trying to exert control in a complex, highly
adaptive environment, such as an agile software development project, is a paradox
(Bourne & Walker, 2005; Karp & Helgo, 2008) because reality cannot be controlled.
30
Relinquishing this control as a central member of the project team, even if it was not
realistic to begin with, can lead to a sense of desperation. It can also lead to a greater
sense of uncertainty, defined as “an individual’s perceived inability to predict something
accurately” (Milliken, 1987, p. 136), which is potentially made worse in an already
uncertain environment.
Loss of Control and Increased Stress
As noted by Troup and Dewe (2002), having a sense of control is an important
factor of work-related stress. Bordia, Hobman, Jones, Gallois, and Callan (2004) have
shown a negative correlation between job-related uncertainty and control, as well as
control and psychological tension. For the agile project manager, the role change from
command and control to facilitation may result in a sense of helplessness, inadequacy,
and may make them feel that they are no longer needed. The relative ambiguity of the
role, in relation to the well-defined role and responsibilities of a traditional project
manager, may also lead to uncertainty and stress. This aligns with the three components
of role-related stress as defined by Ortqvist and Wincent (2006): (a) conflict in role
expectations, (b) ambiguity concerning what actions or behaviors are needed to be
successful, and (c) a perceived inability to achieve the role obligations. Uncertainty may
be one of the primary reasons why employees resist change (DiFonzo & Bordia, 1998),
and job-related uncertainty can create anxiety that can affect job performance and
retention (Bordia, Hunt, Paulsen, Tourish, & DiFonzo, 2004).
Coping with Decision Uncertainty
According to the crisis decision theory (Sweeny, 2008), when faced with a
negative event, individuals go through a three-step decision process as part of the coping
31
process: first, they determine the severity of the crisis, then they determine possible
response alternatives, and finally evaluate the options to determine the optimum one for
the given situation. This can result in different coping strategies (Troup & Dewe, 2002),
such as problem-focused coping that can include trying to learn the new job, or deciding
to quit, avoidance coping, or it can include emotion-focused coping such as acceptance,
which can result in a sense of control over the situation. Kammeyer-Mueller, Judge, and
Scott (2009) include avoidance coping behaviors such as drinking or drug use as an
additional, but highly detrimental coping mechanism. Aitken and Crawford (2007)
concluded from their research study that project managers generally rely on planning and
active coping, similar to the problem-focused approach. This makes sense in that project
managers in a plan-based environment reduce uncertainty through detailed planning
activities. If agile project managers were studied, it would be interesting to see if the
results would be similar.
Personality of the project manager may also play a role in how well they cope
with the new role. This may include openness to change (Allen, Jimmieson, Bordia, &
Irmer, 2007) and having a positive attitude (Kaplan, Bradley, Luchman, & Haynes,
2009); both coping strategies can help ease psychological strain associated with the new
role. Additionally, research conducted by Brunborg (2008) indicated that individuals with
a high core self-evaluation, defined as high self-esteem, internal locus of control, high
self-efficacy, and emotional stability, have been shown to have decreased levels of job
stress. It is possible that personality variables such as these may be contributing factors to
how agile project managers cope with the changes in their role expectations.
32
Conclusion
Based on this literature review, the researcher expected to observe and identify
several themes in the research participants' descriptions of their experiences associated
decision uncertainty as an agile software project manager. These may be related to role
uncertainty associated with changing from a highly defined project management process
to one based on continual change and emergence, or a role change from a manager
focused on tools and techniques to a leader focused on enabling the team to achieve a
vision.
33
CHAPTER 3. METHODOLOGY
Purpose of the Study
The purpose of this research was to explore the lived experiences of agile
software development project managers. The study followed Moustakas’ (1994)
transcendental phenomenological methodology. This method was selected because it
offered a means to gain a deep understanding of multiple project managers’ experiences
with the phenomenon of decision uncertainty, and to discover common experiences they
have shared (Creswell, 2007). The study contributes to the body of knowledge
concerning the psychological aspects of project management, and attempts to address a
current gap in the scholarly literature on the uncertainty effect of the agile methodology
on project managers. It also provides a strong qualitative research foundation to launch
future qualitative and quantitative research into how individuals manage complex,
dynamic situations in the workplace.
Research Design
The majority of the research on traditional project management to date was
focused on process tasks such as risk management, requirements management, and
schedule estimation (Jiang, Klein, Wu, & Liang, 2009; Little, 2006; Turnquist & Nozick,
2004), rather than on the psychological effects on the project manager. Research on agile
software development has focused on the developer or development teams and the
34
relationship with the product stakeholders (Ferreira & Cohen, 2008; McAvoy & Butler,
2009; Moe, Dingsoyr, & Dyba, 2009), instead of the psychological effects on the project
manager. Additionally, most of the existing research has been quantitative. The need for
qualitative project management research has been identified (Cicmil et al., 2006), yet it
appears that this has not yet been addressed for the scholarly literature of either
traditional or agile project management.
Phenomenology was the specific qualitative approach selected for the study. This
approach is appropriate when there is little information available on a particular topic. It
provides a method to study and understand the phenomenon through first-hand accounts
of individuals who have experienced it in their daily lives (Kostere & Percy, 2006). In
this study, Moustakas’ (1994) transcendental phenomenological approach was used. This
approach was heavily influenced by Edmund Husserl, a mathematician and a
philosopher, who proposed that knowledge is not only gained from observations of the
natural word, but also from first-hand descriptions of lived experiences (Moustakas,
1994). In this particular study, it offered a holistic analysis of the experience of
uncertainty associated with management of software projects that utilize the agile
development methodology.
Target Population and Participant Selection
The target population of the study consisted of project managers that use an agile
software development methodology on their current project. The sample of interest to the
study consisted of project managers that used the Scrum agile software development
methodology on their current project. Nine participants were recruited and interviews
were conducted until data saturation, defined by two consecutive interviews in which no
35
new information was revealed. Participants were selected based on the stipulation that
they served in the role of the project manager or Scrum Master of an agile software
development effort at the time of the interview.
Data Collection
Data was collected through telephonic interviews and post-interview
observational notes. The interview established a “social conversation” (Moustakas, 1994,
p. 114) and the observational notes added a deeper contextual meaning to the recordings
and transcripts. These data collection methods were appropriate to answer the research
question because they tapped into the participant’s first-hand experiences with
uncertainty.
An unstructured interview was an appropriate data collection method for
exploratory research, because it allowed the interviewee to describe their experience
holistically (Creswell, 2007; Lincoln & Guba, 1985). Since the participants were further
than a two-hour drive from the researcher’s home, the interviews were conducted over
the phone. The researcher audio recorded the interviews and then transcribed each into a
text format. An interview guide instrument (Appendix A) was used to assist the
researcher with data collection.
After each interview, observational notes were captured on the details of the
setting, the participant, and the participant’s reactions to the questions. This additional
perspective helped add meaning and context to the interview data (Patton, 2002).
Observational notes included a description of the interview setting, the participant, the
participant’s reaction to the questions. An observational notes instrument was used to
assist the researcher with data collection (see Appendix B).
36
Data Analyses and Presentation
Data Types
The researcher transcribed interview audio data into textual data, and maintained
the data in both the raw form (audio) and the transcribed form (both softcopy and
hardcopy). This data helped describe the participant’s personal experiences with
uncertainty. Observational data was transformed from hand-written to typed form, and
was maintained in both softcopy and hardcopy formats. This data enriched the audio
recording with additional information concerning the interview setting and the
participant’s reactions during the interview.
Data Preparation
Data preparation procedures followed step one of Creswell’s three-step analysis
process: “preparing and organizing the data”, “reducing the data into themes”, and
“representing the data” (2007, p. 148). As such, the data was prepared in the following
manner:
1. Transcripts were prepared, and then the audio recordings were played to
verify that they were transcribed accurately. Once completed, a draft summary
of the interview was sent to the participant and they were asked to verify the
information accuracy.
2. The paper transcripts were reviewed and memos were added in the margins –
so that the data was touched multiple times to get a sense of the participant’s
story (Creswell, 2007).
3. The transcripts, along with notes taken during and after the interview and
transcript memos, were entered into a qualitative software tool for coding.
The following procedures were used to manage and safeguard the data:
1. Multiple copies of all the data – both hardcopy and softcopy as appropriate,
were made and stored in separate secure locations.
2. A master copy was stored in a bank lockbox, another copy was archived
locally on a removable hard drive, and a third copy was used as a working
37
copy. A pre-defined naming convention was used to maintain integrity of all
files.
3. Softcopy files were frequently backed-up and copies were distributed as
described above.
4. Master copies were not modified under any circumstance in order to preserve
the accuracy of the data (Patton, 2002).
5. Participants’ names were masked in the data to protect their identity. The
matrix of actual names and participant code numbers was stored in the bank
lock box along with the master data copies.
6. All study records will be maintained in a secure manner for seven years, and
then will be appropriately destroyed.
Data Analysis
The analysis strategy followed Moustakas’ transcendental phenomenological
model that included epoche, phenomenological reduction, imaginative variation, and
synthesis (1994). The following steps detail the data analysis methodology that was used
to gain an understanding of how project managers experience uncertainty when making
decisions on agile software development teams.
Epoche. Prior to conducting the analysis phase of the study, the researcher
reflected on her own ideas and thoughts on how a project manager may experience
decision uncertainty on agile projects. She journaled these thoughts, as well as practiced
mindful meditation to set aside personal beliefs and see the data in a non-judgmental
manner (Moustakas, 1994).
Phenomenological reduction. As described by Moustakas (1994),
phenomenological reduction is a process that textually describes the object (in this case,
uncertainty), reflects on the participant descriptions of the phenomena, and refines the
descriptions. The objective is to reduce the data down into a meaningful description. This
was accomplished by bracketing the research so that it focused on the research question
38
only, horizonalizing, or giving equal weight to each of the participant’s statements,
removing redundancy and overlap between the horizons, organizing the information into
themes, developing individual descriptions that integrate the horizons and themes, and
finally creating a composite description of the experience (Moustakas, 1994).
Imaginative variation. Moustakas described this process as the application of
imagination to understand the how and why of the experience (1994). This can include
brainstorming different meanings for the experience, trying to define qualities or
structures that may help explain the experience, and analyzing the data at the individual
level, and then at the composite level (Moustakas, 1994). These processes allowed the
researcher to decompose the descriptions and then recombine them to understand the
emerging patterns in the participants’ lived experiences.
Synthesis of composite textural and composite structural descriptions. This
final analysis step integrated the textual and structural descriptions gained from the
previous steps into a holistic description of the essence of the experience (Moustakas,
1994).
Data Presentation
Data has been presented according to the phenomenological format described in
the Capella Dissertation Guide (2008). The findings and meaning of the data have been
addressed in the following sections defined in the guide: (a) the study, (b) description of
the sample, (c) research methodology applied to data analysis, (d) presentation of data
and results of analysis, and (e) summary.
39
Research Procedures
Sampling Procedures
Participants were recruited through Internet requests in several project
management and agile software development professional organizations’ websites and
discussion websites. The researcher’s contact information was provided so that interested
project managers could call or e-mail her to learn more about the study. Participant
selection was limited to those who were currently project managers of agile software
development teams. The sampling strategy was based on continuous adjustment, meaning
that the actual sample was refined as additional insight was gained about what
information was the most pertinent to the research problem (Lincoln & Guba, 1985;
Patton, 2002). This strategy was also influenced by the researcher’s ability to gain access
to project managers willing to be interviewed.
The specific sampling procedures were as follows:
1. The researcher sent invitations to the following project management
professional organizations in the order listed. After the invitation was sent to
the first organization, the researcher waited about a week to determine the
response before moving to the next organization. The recruitment order was as
follows:
a. The Hampton Roads Project Management Institute chapter newsletter,
b. The Project Management Institute Agile Community of Practice
website (http://agile.community.pmi.org/Pages/Default.aspx),
c. The Yahoo Agile Project Management Group
(http://finance.groups.yahoo.com/group/agileprojectmanagement/),
d. The Yahoo PMI Agile Group
(http://finance.groups.yahoo.com/group/pmiagile/).
2. The invitation described the study and its intended benefit to the project
management profession, and that participants would receive a $10 Starbucks
gift certificate. The researcher’s contact information was provided.
3. Interested individuals were requested to send an email to the researcher
indicating their desire to participate. The researcher responded back via e-mail
40
confirming that they were interested in participating and that they currently
serve as a project manager on an agile software development team. The e-mail
also requested information on the individual’s location.
4. Once it was verified that the participant met the study criteria, the researcher
coordinated a date and time to conduct the interview. Since all participants
were further than a two-hour drive from the researcher’s home, all interviews
were conducted over the phone.
5. Upon agreement of an interview date and time, the researcher e-mailed an
informed consent form and requested that it be signed and returned to the
researcher prior to the interview.
6. Once received, an interview invitation was e-mailed to the participant, which
included a toll free number and participant code.
The target population, defined as project managers of teams using an agile
software development methodology, was directly related to the research problem. Since
the study topic has not yet been addressed in the scholarly research, the strategy was to
select typical project managers. However, a typical participant is difficult to quantify or
measure, so there is some variance among the participants’ experience levels.
The study sampling design focused on project managers of teams that use an agile
software development methodology. This population was not considered vulnerable, as
detailed in the 45 CRF 46 (United States Department of Health and Human Services,
2005), so there was minimal risk with the sampling strategy. Ethical guidelines were
followed to ensure that participants were provided with documented informed consent,
that they voluntarily decided to participate, and that they had the option to withdraw at
any point in the study and request that their data be destroyed (Barrett, 2006). Also, since
the interviews were audio recorded, this was clearly stated in the informed consent
document, as defined in APA Standard 8.03, Informed Consent for Recording Voices and
Images in Research (American Psychological Association, 2002).
41
Data Collection Methods
The interview was unstructured, and took approximately 60 minutes. Prior to the
interview, the researcher initiated the following steps:
1. In a conversational manner, the researcher described the study, explained the
interview process, and explained that the participant would receive a summary
of the transcript to ensure that it represented their experiences accurately.
2. The researcher explained that the participant’s name and identifying
information would be masked in the report.
3. The researcher asked if there were any questions or concerns before the
interview began, and that the interview was being recorded. Once the
participant agreed to start the interview, the researcher reminded them that
they could terminate the interview at any time, and then began the recording
the session.
During the interview, the researcher initiated the following steps:
1. The entire interview session was audio taped using the Olympus VN-6200PC
digital audio recorder with the Olympus TP7 inner ear telephonic pickup
device.
2. The Interview Guide Instrument (Appendix A) was used to identify the
specific interview session and to ensure that the desired information was
gathered.
3. When the interview was nearing completion, the researcher informed the
participant and asked if they felt that they had provided sufficient detail on
their experiences, or if they needed additional time to expand on them.
4. Once the interview was ready to come to completion, the researcher asked if
there were any questions, and informed the participant that they were free to
e-mail or call the researcher if they have anything to add. The participant was
reminded that in about a week, a summary transcript would be provided for
their review and comment, and that the gift certificate would be placed in the
mail immediately.
After the interview, the researcher initiated the following steps:
1. Wrote post-interview observational notes (Appendix B) immediately after the
interview.
2. Mailed the participant a thank you card that included the researcher’s contact
information, along with the Starbucks gift card. If the participant did not want
a gift card, a thank you e-mail was sent in place of the card. Either method
42
requested that they send additional information or questions, and included a
reminder that the transcript summary would be sent for feedback.
3. Transferred the post-observational notes into an MS Word format and loaded
them into Atlas.ti.
4. Transcribed the interview and loaded the audio and textual files into Atlas.ti.
Compiled an interview summary and sent it to the participant for review and
comment.
5. Received the participant’s feedback, annotated the transcripts as needed, and
loaded the data into Atlas.ti. Sent the participant a final thank you e-mail.
Prior to and during the interview, the researcher followed the practice of epoche,
that is she set aside her own biases and opinions about the topic, and was mindful of the
experiences and words of the interviewee (Moustakas, 1994). The unstructured interview
was appropriate to answer the research question, because it provided a flexible
mechanism to gather an in-depth understanding of the participant’s experiences (Patton,
2002). As recommended by Patton (2002), minimal notes were taken during the interview
only to capture significant comments. Instead, the researcher relied on the audio
recordings to capture the interview data, and gathered additional notes and observations
once the interview was completed.
Data Analysis Procedures
The researcher transcribed the audio data. The interview audio files were
transcribed using the following method: The researcher listened to the audio recording
and manually transcribed it into a MS Word format using the Audiotranskription f4
program and a USB foot pedal to control the audio speed. The post-interview
observational notes were converted into MS Word files. The researcher loaded the
interview audio and transcription files, as well as the observational notes into the Atlas.ti
qualitative analysis tool. Once completed, the transcendental phenomenology steps
43
described previously began. The following activities were included (Kostere & Percy,
2006) in these steps:
1. The audio and textual files of each interview, to include observational notes,
were reviewed in their entirety to understand the participant’s experience with
the phenomenon. Post-interview observational notes were reviewed for
additional context.
2. Once completed, each file was reviewed again, and analyzed in greater detail.
Segments of text that were meaningful to the research question were
highlighted. The data segments were reviewed again to remove redundancies.
A list of themes were defined.
3. The meaningful text segments were linked and then clustered into themes. For
each interview, the themes were combined into a composite.
4. The individual interview themes were combined into a composite to explain
the essence of the phenomenon being studied.
Role of the Researcher
Interviews
The researcher was the data-gathering instrument and guided the interviewee
through the session, and when needed, included additional sub-questions. Feedback was
provided to ensure that relevant, valuable information was being gathered, and that the
interviewee felt comfortable and valued. During the telephonic interviews, the researcher
paid great attention to voice inflection and silence to ensure that appropriate feedback
was provided. During the interview, the researcher remained neutral, but engaged.
The researcher had limited experience in phenomenological interviewing, but had
completed organizational benchmarking interviews and job interviews for prospective
employees. Prior to initiating data collection, the researcher gained additional interview
knowledge by reviewing various qualitative interviewing texts such as those by Creswell
(2007), Patton (2002), and Seidman (2006). Qualitative interview experience was gained
44
by conducting role-playing interviews with colleagues. The practice interview sessions
were audio recorded in the same manner that the study interview sessions were to be
recorded. This served two purposes, to develop and refine an audio recording procedural
checklist, and to provide audio information on how to improve the questioning
techniques. Additionally, during data collection, each interview session was analyzed to
improve procedures and techniques for the following session.
Post-Interview Observations
The researcher was the instrument for this data collection method, by capturing
observations and thoughts on how the interview went, to include how the participant
reacted to the questions, as well as a detailed description of the interview setting. The
researcher had adequate experience with capturing detailed observational descriptions, so
no additional research or practice was required.
Ethical Considerations
In complying with the guidance in the Belmont Report (National Commission for
the Protection of Human Subjects of Biomedical and Behavioral Research, 1979), the
researcher respected the participant’s privacy, minimized risk, and gave equal
opportunity for all qualified project managers to participate in the study. The interviews
were conducted in a private room so that the conversation could not be overheard. The
questions asked were respectful and did not make the participant feel that they have to
reveal anything they did not want to. The interviews were audio recorded, transcribed,
summarized, and then provided back to the participant to review and validate. All data
was stored securely and access was limited to the researcher. The identities of the
participants were protected at all times.
45
CHAPTER 4. DATA COLLECTION AND ANALYSIS
The Study
This chapter presents the data collection and analysis conducted for this
exploratory phenomenological study. Data was collected through unstructured interviews
with nine participants who served as the Scrum Master of an agile software development
team. The purpose of the interviews was to answer the study research question,
specifically: “How do project managers experience and describe decision uncertainty
associated with the agile software development methodology?” Data collection for this
exploratory study was built upon the framework described by the literature review
presented in chapter 2, and followed the research methodology process and procedures as
described in chapter 3. This chapter provides additional information on how the
qualitative data was collected, and presents how it was analyzed in accordance with the
phenomenological methodology. This will provide the basis for the data analysis results
and conclusions presented in chapter 5.
This chapter is organized in three main sections. The first section describes the
data collection sample along with demographic information such as gender and project
management experience. The second section describes how the phenomenological
research methodology was applied to the data, and the final section presents the data and
the analysis of the data. The chapter will conclude with a summary of the main points of
46
the analysis and provide the foundation for the research analysis results and conclusions
presented in chapter 5.
Description of the Sample
Recruitment Procedures
The recruitment procedures started with an announcement in the researcher’s
local Project Management Institute (PMI) chapter newsletter. The intent was to find local
agile project managers who were familiar with traditional project management practices.
The announcement was posted in two newsletters, covering a two-month period, but did
not result in any volunteers. The search was then expanded outside of the researcher’s
local area with recruitment announcements posted on two Project Management Institute
related internet sites for agile software practitioners: (a) the Project Management
Institute Agile Community of Practice website, and (b) the Yahoo PMI Agile Group.
While intending to post to the Yahoo PMI Agile Group, the researcher inadvertently
posted the announcement on the Yahoo Agile Project Management Group. This research
plan deviation was provided to the Capella Institutional Review Board (IRB) along with a
request to include the website in the study. Interviews began with volunteers from the
other sites, and once the second Yahoo Group was approved, the researcher began
interviewing participants from that site as well. The researcher gained approval to recruit
on additional websites, but they were not used because data saturation was reached after
nine interviews.
Participant Description
Fifteen individuals volunteered for the study, but only nine agreed to the informed
consent and followed through with the interview. All participant identifying data such as
47
their name and the name of their organization were masked in the transcripts and
observational notes. For the remainder of the study, participants have been identified in
the order they were interviewed and will be referred to as INT1 for Interview 1, INT2 for
Interview 2, and so on. Basic demographic data for each participant is provided in Table
1.
Table 1. Participant Demographics
Participant
Gender
Location
Total PM (yrs)
Agile PM (yrs)
Interview 1
M
MN
15
3
Interview 2
M
AL
17
2
Interview 3
M
CT
20
.5
Interview 4
M
IL
3.5
3.5
Interview 5
F
CO
10
1.5
Interview 6
M
France
6
6
Interview 7
M
CO
15
5
Interview 8
M
New Zealand
17
17
Interview 9
F
NE
10
2
The study sample consisted of nine participants, including seven men and two
women. Seven of the participants resided in the United States, with locations on the east
coast to as far west as Colorado. Two participants resided outside of the United States,
one in France and the other in New Zealand. The average number of years of project
management experience was 12.6, with a range from 3.5years to 20 years. The average
number of years of agile project management experience was 4.5, with a range from a
48
half year to 17 years. Several participants had only agile project management experience,
thus their totals were the same for both project management and agile project
management experience. For example, INT4 did not have previous project management
experience; however, he had worked in a Project Management Office so was very
familiar with traditional project management tools and techniques. INT6 had only agile
project management experience, and INT8 had always worked on projects that followed
agile principles rather than process-driven projects. On the other extreme, INT3 had
extensive traditional project management experience, and had just become an agile
project manager. As a result, their experiences may have differed based on their level of
experience. In addition, all participants with the exception of INT5, had played a key role
in the decision to adopt agile methodologies in their organization. This may also have
influenced their positive experiences.
Data Collection
Because all participants were outside of the researcher’s local area, all interviews
were conducted telephonically. Interview scheduling, preparation, and execution protocol
described in chapter 3 was adhered to, and all interviews were successfully conducted
and recorded. The researcher was concerned there might be difficulties with the audio
quality for the international interviews, but the recordings were as crisp as those for the
participants in the United States. The average interview length was approximately 60
minutes, with the shortest being 26 minutes and the longest at 70 minutes.
The researcher utilized the interview guide listed in Appendix A. This established
a common framework for each interview and kept the researcher on task to ensure the
desired data was gathered. Each interview participant was asked the open-ended question,
49
“As a project manager of an agile software development team, what kind of personal
experiences did you have with decision uncertainty?” This often led to a lengthy
discussion and then if needed, the following guiding questions were asked to gain more
information on a given area of interest:
1. Project management
a. Tell me about your background and experience as a project manager?
b. What about you, such as your personality traits, or your ability to solve
problems, led to your selection for the project manager position?
2. Agile software development
a. What do you think led your organization to adopt agile practices?
b. What is your background and experience leading agile development
teams?
c. When you first learned that you were going to be leading an agile
development project, what were your thoughts and concerns?
3. Decision making processes
a. Once your project got underway, what were the things that kept you up at
night?
b. Tell me about what it was like for you to deal with ______ (pick one of
the concerns mentioned in the previous question) in a typical day, or in a
critical event that happened to you.
c. What was it like for you as the project progressed?
d. What have you learned about yourself, specifically your ability to handle
the ambiguity of leading an agile development project?
The interviews were rich with relevant data, yet several got off-topic and the
researcher had to focus the participant back on answering the research question. This was
expected since the interview was unstructured. Once the interview was transcribed, a
copy was sent to the participant, who was asked to review the transcript and verify that it
accurately captured their comments. All participants validated the data, and several
provided minor edits. Once this task was accomplished, the data was ready for analysis.
50
Research Methodology Applied to Data Analysis
The study data was analyzed using a modified version of the Van Kaam method,
as described by Moustakas (1994). This method consists of the following steps that
helped the researcher understand the participants’ perceptions of decision uncertainty
associated with managing an agile software development project.
1. Steps for each individual transcript:
a. Review each statement and record expressions pertinent to the study’s
phenomenon. Do an initial grouping of these expressions. This step is
called “Horizontalization” (Moustakas, 1994, p. 121).
b. Review each expression identified in the previous step, and test it against
the following two questions: (a) “Does it contain a moment of the
experience that is a necessary and sufficient constituent for understanding
it?” (b) “Is it possible to abstract and label it?” (p. 121). The resulting set
of expressions are considered the core set of expressions for the
experience. These are called “Invariant Constituents” (p. 121).
c. The invariant constituents are then clustered into themes.
d. The themes and associated invariant constituents are validated against the
complete transcription to ensure that they are correct, otherwise they are
removed.
e. The resulting themes of the experience are described using quotes from
the participant. This step is called an “Individual Textural Description” (p.
121).
f. Based on the individual textural description, a description of the
participant’s experience is created that attempts to depict the underlying
reasons for the experience and identifies the thoughts and feelings
associated with the experience. This is called an “Individual Structural
Description” (p. 121).
g. For each participant a composite of the experience themes, invariant
constituents, meanings, and feelings is created. This is called a “Textural-
Structural Description” (p. 121).
2. Then for each transcript, the individual textural-structural descriptions are
combined into a holistic composite for the entire participant group.
The procedural steps were then applied to the study data in the following manner.
Upon validation by the participant, the transcripts were printed out in hardcopy form and
51
each sentence was reviewed individually to determine if it was relevant to the research
question. Relevant sentences were underlined and those that did not directly address the
research question were crossed through. This initial review also provided the researcher
with a high-level understanding of the participant’s experiences. This was accomplished
through initial theme definition and handwritten notes to capture concepts and meaning in
the data.
Once the initial review was completed, the MS Word softcopy version of the
transcript was loaded into Atlas.ti, a qualitative analysis tool, and a more detailed review
was accomplished. This included marking interesting sections of the text as quotes,
creation of more themes, and adding detailed memos to document thoughts and ideas
about the transcript. After the data was analyzed, it was reviewed again in greater detail.
Each sentence was reviewed for relevance, and those that did not directly relate to the
research question were removed. Additionally, redundant themes were merged. As each
transcript was analyzed, previously analyzed transcripts were reviewed again in light of
the themes and memos created for the transcript. Through these continual reviews, high-
level themes began to emerge in the data. This review and re-review process was
followed for each transcript until all core high-level and lower-level themes were defined.
The high-level themes, theme definitions, and associated low-level themes were recorded
in Atlas.ti. The tool tracked the specific themes and theme counts used in each transcript
as well as the overall theme counts across the entire data set. The researcher used this
data to analyze each theme based on the number of times it was used in the entire data
set, as well as the number of times it was used in each transcript. Themes that were
clustered in only a small number of transcripts were reviewed for relevancy to the entire
52
study. This was accomplished by searching for the theme in each transcript and then
reviewing the linked text to ensure that the theme was correctly applied. Then related
themes were reviewed to determine if the theme in question could be merged, or if it
needed to be deleted.
The next step was to develop textual descriptions for each transcript in a MS
Word format that included the words of each participant that related to the core themes.
Once completed, a concept map, or graphical depiction of the concepts, was created for
each transcript using a tool called Mind Manager. This allowed the researcher to depict
the high-level themes and associated lower level theme clusters for each participant
graphically. Data from the textual description was added along with descriptions that
attempted to explain the participant’s thoughts and emotions associated with each of the
themes. This created a textural/structural composite for each participant. These individual
participant descriptions were combined into a composite concept map for the entire
study. The researcher used this composite to review the comprehensive data set and
finalize the overall themes, associated lower-level themes, and selected participant
quotes. This composite map provided a holistic view of the study analysis results.
Presentation of Data and Results of Analysis
This section represents the results of the data analysis methodology and describes
how the data supports the research question: “How do project managers experience and
describe decision uncertainty associated with the agile software development
methodology?” This includes a discussion of the themes, and then concludes with
presentation of the participants’ words describing how they experienced decision
uncertainty as an agile project manager.
53
Final Theme and Code Sets
The final analysis structure for the study is depicted in Figure 1. The results were
categorized into the challenges and benefits that the participants experienced as agile
project managers, and then each category was divided into high-level themes that were
further divided into lower level themes. The agile challenges category consisted of the
following three high-level themes: (a) organizational challenges, (b) personal challenges,
and (c) team challenges. The agile benefits category included the following three high-
level themes: (a) realization of control, (b) personal realization, and (c) team realization.
After the transcripts were first reviewed in Atlas.ti, the initial set of themes was 152. In
Figure 1, the number in the parentheses after each of the six high-level themes indicates
how these codes were initially distributed. Through the detailed analysis process, these
themes were reduced down to a final count of 22, as depicted by the lower-level themes.
Each of the high-level themes and associated lower level themes will be described in the
following sections.
54
Figure 1. Analysis Results
Agile Challenges
At the start of the interview, each participant was asked the following question:
“As a project manager of an agile software development team, what kind of personal
experiences did you have with decision uncertainty?” The majority of the responses
included the challenges that they had experienced when initially adopting the software
development methodology. These experiences were generally divided among the
following three categories: (a) challenges they experienced with getting their
organization to understand and agree to adopt the approach, (b) challenges they
personally experienced over their doubts and concerns about being an agile project
manager, and (c) challenges they had with getting the team to adopt the new
methodology. Each of these will be further described below.
55
Organizational challenges. Most participants described the challenges they
experienced when trying to adopt agile methods in their organization. These were
generally divided among problems dealing with the organization’s corporate culture,
difficulties with getting senior leadership to understand the agile software development
methodology and agreeing to adopt it, and problems associated with bringing about a
change in the way the organization does business.
From an organizational culture perspective, adopting an agile methodology can
result in unexpected difficulties. Five of the participants described the organizational
challenges that they dealt with such as trying to implement a change-tolerant process in a
blame-oriented culture, and trying to convince the organization that co-locating the teams
was beneficial, even though it meant that individuals had to give up their offices, which
were considered as a corporate status symbol. INT2 discussed the challenges he faced
with overlaying a new process onto an existing organizational culture, specifically that it
was a much larger change than what was anticipated:
I am not sure even we realized how much of a culture change it represented when
we started this exercise. We knew change was going to happen, we knew that there
were going to be a lot of issues, but I don’t know that we knew how much culture
we were impacting by this change, by the base thinking processes that were behind
it. But it became pretty obvious quickly. So for example, we identified…we use
Scrum … so we identified these basic roles. The Scrum Master, the Product Owner,
and the team roles, basically. We had an existing functional management structure
in place, we decided not to go and re-vamp our entire organization, but of course
that caused a whole bunch of problems then. We were asking teams to become
responsible for themselves, we were asking Scrum Masters to behave like coaches,
but not like managers. We were asking Product Owners to define purely what they
wanted rather than how it got done, which was a change in our culture. We were
asking for whole different ways of developing, and one of the basics of course, and
this I suppose comes back to your discussion here, is this basic change of suddenly
change is expected - we need to update the plan - rather than the plan is right, we
need to get ourselves back on plan as a result of change.
56
Another organizational challenge was persuading the organization’s senior
management that it was in their best interest to adopt an agile methodology. All but one
of the study participants were involved in the decision to adopt agile, so they were
personally responsible for building a business case to justify why the organization should
let them adopt an agile methodology. Sometimes this was difficult because senior
management, who were used to making decision based on a detailed project plan, were
now being asked to make decisions based on less planning data and on trust that the team
can get the work done. INT7 explained how he dealt with this:
Well, and then again, walking into a traditional management structure where they
are saying “Prove to us that you can deliver this thing by September 1st”. The
answer is, “I can’t prove it to you. I don’t have enough information. But, I have a
team that has a long working history with delivering projects that have said that
they think these are reasonable estimates. We think that we have put together a
plan that is good enough”. Putting the plan together, and convincing management
that it is good enough is a pretty powerful early stressor on an agile project.
Most of the participants were successful on their first try, but one, INT5 was
turned down, so decided to take matters into his own hands. He was so adamant that
adopting an agile methodology would help his team deliver value to their customer that
he decided to adopt it in secret, against the wishes of his senior leadership:
There was a lot of decision uncertainty. In fact, three and a half years ago I
couldn’t use the term agile. I wrote a business case at the firm I work at for
permission to use agile techniques and was turned down. I did not let that thwart
me, so what I did was I started using different terms. I got the team together, the
first team that I worked with, and they were on board. They wanted to try it. A
couple of people had worked on agile efforts before outside of the firm, and
thought it was a great idea. So we used different terminology. Our product
backlog, we nicknamed the MFL - the Master Feature List. [Laughter]. Stories
were now tasks. We came up with essentially a different set of nomenclature or
jargon, so that we could practice agile development almost in a cave, or in secret.
57
Another organizational challenge was that adoption of an agile methodology
requires the organization to change the way they have always done things. This included
a change in how success was defined, that it should be at the team level, and not the
individual level. This means that even though an individual could be successful in their
own tasks, that they must also ensure that the team successfully completes the product.
Another challenge to adopting an agile method is that the traditional corporate processes,
such as the budgeting process, may not support it as INT1 stated:
A challenge is still living with the corporate planning processes. Most places I
have been had a yearly budget, they put a number to a project at the start, but the
initiation of the projects are usually based on the assumption that there would be a
fixed budget assigned to it and a timeframe. Sometimes you want a product by
this date, and so some of those things are there but I think the next evolution is
trying to get agile to that level of portfolio management say.
Personal challenges. As depicted in Figure 1, this agile challenges high-level
theme had the highest number of lower-level themes, both initially at 38 and finally at
five. These included dealing with the anxiety that the change to agile methods might not
work, and concerns of falling back into old behavior. It also included the challenges of
dealing with all of the project unknowns, using a facilitator-style leadership role rather
than command and control, and the challenges of dealing with their new role on the team.
Each will be further defined in the following sections.
A concern shared among six of the nine participants was if the agile methodology
would work for their project. Since the majority of the participants were involved in the
decision to adopt agile methods in their organization, they were responsible for the
outcome. Many stated that it was exciting to get approval to adopt the agile methodology,
but the difficult part was in actually implementing the new processes. This included fear
58
that it might not work, that this would reflect poorly on them, and that it took a while to
see progress. INT7 described the anxiety he felt about putting his job at risk:
I had stuck my neck out saying that I believed this was a better way to deliver
software projects, and that we would be able to ultimately deliver things that were
higher quality in a shorter time frame using these kinds of techniques the way we
would with traditional project management. The reaction from my management
was well, “Let’s take a small project and we’ll just kind of watch and see how it
happens. By the way, you might want to consider your career, not in so many
words, reconsider your career if this doesn’t work.” [Laughter]. Actually, not
quite in so many words, but the implication was, “Don’t screw up. We had a lot
time and money invested in software projects, and you’re talking about doing
something completely different than what we have ever seen. We’re not really as
convinced as you seem to be, so we will be watching you.”
During this stressful transition, four participants discussed their anxiety over the
desire to go back to the old way of doing project management. They wanted to plan the
development in detail, in a way, to take back control. INT1 shared his experience with
this challenge:
When I started, I did Waterfall for many years and followed the PMI [Project
Management Institute] strategy. Then when I got introduced to agile, at first it
was a little scary for me from a project management point of view. I wanted to go
back to the old method of trying to figure out everything in detail.
The participants stressed that they chose an agile methodology because they knew
that there were unknowns about what the customer wanted, and consequently what they
were going to build. However, this element of uncertainty was still a challenge. INT6
explained what this experience was like:
One of the things that we are not sure what to do with is, all of these features are
things have never been looked at by the development team, never been estimated,
or played around with. Nobody even knows what these things are supposed to do.
Our customers don’t really know because we’re in a product where we are
developing a market, so our customers don’t really know. Nobody knows what
these things are.
59
Agile project management changes the role of the project manager from a
command and control leadership style to that of a facilitator. Several of the participants
discussed the personal challenges they experienced with maintaining their new role. This
included being mindful about holding back from telling the team what to do, as they had
done in a traditional project management role, and letting the team make their own
development decisions. INT3 talked about planting an idea as a seed and then being quiet
so the team could come up with their own solution:
The whole language is different. Like for instance, let’s see, if I see something,
instead of saying “Hey, why are you doing this? Can you explain this to me?
…and what was your rationale? …and did you have several options? … and when
you selected the option, what were your criteria?” [Laughter]. I can’t say that
anymore! I have to couch it in different terms. I have to be respectful. So instead,
I say, “Team have you noticed…?” [Laugher] and just leave it at that, “have you
noticed that the approach to the automated testing might be sensitive to this?” and
just leave it at that. I won’t ask why. I just do a unidirectional “Have you noticed
this?” and then go quiet.
A related personal challenge was that the new role was significantly different
from the traditional project manager role. Seven participants discussed their feelings and
experiences with taking on the new role. These included having to unlearn the old ways
of managing a project, figuring out the boundaries of their new role, dealing with the
feeling that they were no longer needed on the team, and learning a new style of
leadership. INT4 talked about the challenges he experienced as a new agile project
manager:
As to my role, I struggled with that for a while, at least a year if not eighteen
months. While reading a lot of books, and being a servant, and trying to become a
servant leader versus the command and control, and deciding exactly what level
of detail I need to get my hands dirty.
60
Team challenges. The final sub-theme of agile challenges was related to the
participants’ difficulties of getting the team to adopt their new role. These challenges
included dealing with their team members’ resistance to change; accepting that some
team members get it and some do not, and what to do about those that are not willing to
make the transition. It also included difficulties of getting the team to self-organize, a
critical factor of the agile software development methodology.
Adopting an agile methodology brings about many changes for a team, and
requires that they develop software in new ways, which can be unsettling at first. INT1
presented his thoughts on why the development team is often resistant to adopting an
agile methodology:
I have worked on agile projects which have been as big as a million dollars and
150 people team, and as small as 3 people. But, one of the major things I found
was people are kinda of scared. This is because they are going into it not knowing
the whole picture and how it is going to flow. So there is a level of fear and
uncertainty, especially among the development team. When I talk about
development, it is around software developers. A lot of anxiety among them
because they are used to having everything defined before they start coding.
Seven of the participants discussed the challenges that they had with team
members who did not want to transition to the new process. Much of the responsibility
that was once the project manager’s, such as estimation, becomes the responsibility of the
team. Some team members are willing to take on these new tasks and seem to accept
them immediately; others are a bit slower and require more coaching from the project
manager; however, some never accept the new role. The challenge is what to do with
these team members because their behavior can hamper the efforts of the entire team.
INT7 described a team member who was not willing to provide estimates, and offered
possible reasons for this reluctance:
61
The other bigger thing that I got involved in later on, was when we had some of
these people that were resistant to the ideas. I wound up spending even more time
doing mentoring and coaching with that team because I wanted to give them a
chance to understand the methodology and where I was coming from, and to
understand that it was probably my head on the chopping block and not theirs
[Laughter]. Once I kind of got them to come around, they mostly seemed to feel
like this was a good thing, except we had one guy that when he was doing
estimations was kind of threatened by the whole agile estimation process. He
started going into this thing when we would ask him for an estimate, that he
would say, “Well, it could be infinite”, and would put infinity down for an
estimate. This was a really unusual thing, but on the other hand, I think it was
partly what I was talking about with accountability earlier. He was worried that if
he didn’t deliver in the short amount of time that he thought was a realistic
estimate, he was worried that he might lose his job, something like that.
Another team challenge was that some of the team members were reluctant to
take on their new role and to self-organize, or that this process took longer than expected.
This initially added more work on the project manager as described by INT1:
You know one other thing was the ownership from the team members. You know,
in agile you really want to have that trust, and you really want to have the team to
self-manage. Maybe I was naïve enough at that time to say that it was going to
happen soon. But, people still kind of relied on me as the project manager for all
of their problems and issues. In reality, they didn’t make decisions and take
ownership of simple things like taking things off the product backlog, or the sprint
backlog. You know initially it really fell upon me to do the productivity. So that
was the other thing that I got concerned about a lot because it was a big project,
and I could not be everywhere at all times. So, I wanted them to get more
ownership.
Agile Benefits
The second major category concerned the benefits that the participants
experienced with being an agile project manager. Even though the leading interview
question did not explicitly request the participants to discuss their positive experiences,
the open-ended nature of the question allowed them to explain their experiences with
decision uncertainty holistically. As a result, the participants began the interview sharing
their thoughts and emotions associated with the challenging aspects of adopting agile
62
methodologies, and then transitioned into the positive aspects that they had realized
because of the experience. These beneficial realizations included what they had
discovered about project control, what they learned about themselves individually and
about being a project manager, and changes they observed in their team.
Realization of control. Control is an important aspect of traditional project
management and is related to detailed planning, and continual management of the project
schedule, cost, and scope. For most, not doing this detailed planning was an initial
challenge area, but over time, it resulted in the realization that they never really were in
control over the project. This high-level theme included the following three lower-level
themes: (a) agile was liberating, (b) myth of control, and (c) view of prediction changes.
Each will be further explained and then an example will be presented in the participants’
own words.
Six of the participants talked about how the agile process was liberating for them.
This included the benefit of giving power to the team so that they can make decisions on
their own and track their own progress. Traditionally, the project manager handled these
tasks. The iterative process utilized in agile methods was also liberating for project
managers because it provided continual feedback so that problems could be dealt with
quickly. INT 7 explains how this helped to reduce stress levels:
So what tends to happen is that after the project starts, on a traditional project, a
lot of times 3 months, 6 months down the road is when you discover that there is a
problem that is going to have to be dealt with. On an agile project, the problems
become visible a lot earlier and you have a chance to deal with them a lot earlier.
In a lot of ways, it is less stressful because you get a chance to deal with the
problems as they occur, rather than waiting until near the end of the project, or a
project milestone. Then you discover there is a problem, and then everyone is in a
panic and in a hurry to deliver something. The stress levels go way up.
63
Four participants talked about their realization that they never really had control
in the first place, and that adopting agile practices helped them to see this. This included
the realization that hiding behind a process, such as the high-control processes used in
traditional project management, can drain the energy out of an organization and prevent
people from realizing their potential. They realized that the thing they were working so
hard to achieve, project control, was really an illusion. INT 7 explained that he realized
he never had control in the first place, and that the highly detailed project plans and
schedules were never realistic:
The thing that I found kind of frustrating about the traditional project management
process is that I felt like I was providing a veneer of predictability around a
process that really was not predictable. So with a traditional project plan you
spend a lot of time putting together Gantt charts and justifications for everything
that you are going to do. You would pass that up to management, and they kind of
nod their heads and say, “Yes, OK that’s good and that looks like it will work
within the existing management structures”. Then as the project progresses, you
discover that no matter how good you thought the planning was, ultimately there
will be things that get in the way that cause problems with the project. I have done
this both as an internal project manager and also working with external entities
that were developing software for me. I felt the same way in both cases. That the
project plans that came together were unrealistic, the typical project management
technique for dealing with unrealistic plans was to put in change orders, and the
change order process is fraught with frustrating, difficult negotiations. A lot of
which have to do with the fact that the project plan was supposed to be
predictable but in reality, it never is. With software, it is very difficult to come up
with something that is really as predictable as management hierarchy would like it
to be.
The illusion of control was realized when the participants gave power away to
their team and when they decided not to do all of the highly detailed planning processes.
INT 2 explained that this was an adjustment, but that things still got accomplished:
A lot of the lack of losing control required a degree or a bit of re-education about
what it meant to be a leader these days, in a modern world. Then the second thing
is that different personalities will have different responses to the apparent lack of
control that you have. It is like all these things, you know, that it was probably a
64
myth when you thought you had control in the first place. Giving that up and then
seeing what the results are as a result of the giving up, requires another two or
three steps to go through that kind of process.
In the third low-level theme, called view of prediction changes, the participants
realized that their perceptions about predicting how things should be done, such as in
detailed project plans and schedules, changed once they became agile project managers.
They realized that agile methods do not predict anything, and that determining how fast a
team can develop functionality is based on past performance. They also realized that you
cannot predict the future with accuracy, even though that is an expected practice in
traditional project management. INT4 explained his realization that you can’t plan
beyond what you can accurately define.
Now essentially I ask the team one question when we talk about iteration length,
it’s, “How long can you plan for it accurately?” If that's a week, maybe we should
start off for a week. Or, what do we need to do to change so we can get the two-
week iterations? Because it does seem like maybe a little too much planning and a
lot of overhead, what needs to change to do that? Normally I have developers
back off because they say, “I only want to plan for every 4 to 6 weeks, you know,
as little as possible”. But of course, I try to tell them or try to explain to them.
What will you be doing six weeks from now at home? “Well, I don't know”. Well
then how can you tell me what you will be doing in six weeks at work then?
Because we don't have those requirements yet, or again based on the project how
volatile are the requirements? You know, how often is the business partner going
to change your mind? I am guessing that it's going to be more than once every six
weeks.
Personal realization. As depicted in Figure 1, the personal realization high-level
theme initially contained more lower-level themes than any other high-level theme
because this discussion area had the most focus among all of the participants. The low-
level themes included realizations about the need to continually learn in order to
continually improve, and that the people aspects of the agile methodologies allowed them
to coach and facilitate the team. They also included realizations about becoming more
65
comfortable with ambiguity, that one project management approach does not fit every
situation, and that taking care of the team is a critical project success factor.
Five participants talked about the need for continual learning, and the realization
that they had an insatiable curiosity to learn more. This included reading and researching
a diverse number of topics related to managing an agile team, and interacting with other
agile project managers and subject matter experts to learn about their experiences. INT6
discussed how he was continually searching for information and knowledge about
managing teams and coaching individuals:
So, when I got to a point I was confident with my programming, I wanted to build
something that was bigger than what I could hold in my own head. I felt like I got
to a point that I wanted to be more alive, I wanted to be more out of control,
because any time that there is more of a challenge, there is more of a reward,
emotionally. So I was looking for bigger teams, when that stopped being as
challenging for me, then I started to pay less attention to programming itself and
paying attention to group dynamics, started paying attention to coaching. I started
to subscribe to a lot of the agile lists, started to participate in conferences, asking
people what they read, what their influences are.
In addition to research, several of the participants talked about their excitement
with learning new things experientially. INT3 enthusiastically talked about learning
things each day on the job:
I think from this process I kind of wake up each day with a different outlook. I
think learning about myself; I like to shape that to, “What have I learned as a
result of this behavior?” When I wake up, this is in the back of my mind, “What
am I going to learn today?” and I am really excited. [Laughter]. So that is really
the fundamental change for me.
Six of the participants talked about the how they loved to coach and facilitate the
team. They talked about how they were captivated with figuring out how to get people to
work together, and how to engage people so that they are willing to achieve their best.
66
INT5 talked about how he loved to help the team, even if he did not get the credit for
doing it:
The only reason I like to get involved is when they ask me, or if I see someone
struggling. Sometimes I may need to say, “Hey, you know you said the same
thing the last two days at stand up”. Usually someone on the team would stand up,
or maybe they did not realize that they said the same thing. I take better notes than
most. I’d say let's get you some help on this. Depending on the person, I may not
say anything in front of the group. You know developers have egos like
everybody else. So, getting them past that obstacle or hurdle, I loved doing that. I
love knocking down obstacles for the team, and the thing is you get little credit
that way, but you love seeing them accomplish what they're going after. That's
where I get my satisfaction from, it is from seeing them succeed and knowing that
you knocked down the wall to make them able to get where they got. It's great.
Participants realized that they were more comfortable with ambiguity and
uncertainty. This was due to gaining frequent feedback and having the ability to adjust
and correct as needed throughout the development process. This realization not only
reduced stress, but also brought about a sense of calm, as described by INT1:
Well, I think I am more calmer, you know I am more comfortable with ambiguity
than before. I can be with people saying, even the sponsor saying, that they don’t
know what they want and I am comfortable with that. The approach could be that
we will figure it out as we go along. I am comfortable with that. From my end, I
think. I have adopted it pretty good to the agile way. I have become more focused
on the team, on the individuals, on the team players. So to say other than process,
I have lost some of the process focus I had before, and am more focused on
getting the team to work together.
Another realization is that there are multiple ways to implement a software
development project, and that the context of the project must be considered before
deciding on how to do the work. The work may not always be best suited for an agile
method; it may require some type of a hybrid between traditional and agile
methodologies. INT4 explained why it is important to be mindful of the given project
context:
67
Every time you get a new chunk of work, whether it is an existing team, or a new
team, you really need to stop and take a look at it and say, “OK, how is the best
way we need to tackle this?” I certainly don’t normally have the answer. I really
have to look at the team. It depends on the team, the talents on the team, the work
at hand, the experience, to identify the gaps in the talent if needed.
The final lower-level theme in personal realization was that taking care of the
team and empowering them was a critical success factor. This not only included enabling
those that did the work, but also making sure to stay out of their way. INT8 offered his
thoughts on why the team is so important and how the project manager must protect them
so that they can do their job:
You have to have a working ecosystem. The team needs to have the right kind of
tools, techniques, and environment to be able to actually succeed at what it is that
they do. Otherwise, if they just spin wheels that’s not going to be good. They
actually need to know what patterns, what tools and techniques that they need to
use to actually do something useful, to deliver something working. That really
matters a lot. Once that is in place, then it becomes a relatively simple job, and the
task of the project manager is much, much diminished, if you like. People self-
organize; the project management things to do are to work the interface with the
organizational reporting requirements and so on. Defend the team from the trivia
of administration.
Team realization. The final high-level theme of agile benefits was focused on the
team, and the realization the participants had about how agile helps the team. This
included having the team challenge the way things are done, and figuring out how to do it
better. It involved allowing the team to have ownership over the product that they are
producing, and that once they got over the initial challenges of adopting the new
processes, they actually liked it better than traditional processes.
The agile method allows the team to be more involved in the decision process,
and it allows them to constantly challenge the process and be responsible for making it
better. In other words, the team is encouraged to challenge the status quo and to seek out
68
and gain feedback on a regular basis. INT4 explained how important it was to him to
have a team that was always trying to figure out how to do things better:
Yeah. It almost gives a green light to go ahead and think, it’s OK. Go ahead and
analyze. Question the process. I love people that question. I have gotten rid of, or
I should say that I have found better areas for people that are yes men. Because to
me if all you can do is say “yes” then one of us is not needed here. And I tell you
what; I’d like to stay [Laughter]. So, I try to put it a little more tactfully,
obviously. But, you know, I need people that question me, that challenge me, that
challenge the work, and find the absolute best solution given the set of constraints
we have to work with. So, that to me is what is so exciting about being a project
manager.
Participants stressed that team self-organization is an important success factor in
agile methods, and that when it worked it was impressive. The team is empowered to
make decisions, not just about how to build the product, but also on how to organize and
manage themselves. INT2 explained how exciting it was when the team started to make
the decisions on their own:
It has been fascinating because the other thing that happened was about ten
months later we had one bay split into two areas so there was one team on one
side of one team and another team on the other side. Each had control of their
own area. But, one of the things that happened was that we needed to slide a new
person into one of the teams, and so one of the Scrum Masters put a floor plan out
that just fundamentally expanded one of the teams bays area slightly. But, in the
whole area everyone said, “No, that is not what we want at all. Let's get rid of all
the walls in the bays”.
The final lower-level theme, called team realization, reflected the experience
participants shared about how agile methodologies benefitted the teams, and that team
members were generally happier than when they were on traditional development
projects. INT7 stressed that even though there were many benefits with adopting an agile
method, it was still hard to get management buy-in:
The majority of the people that worked on these agile teams were happier
personally working on the teams. We were able to deliver software faster. I feel
69
like it is a net win but it is amazing how difficult it is to sell to a company that is
already sold on the traditional project management methodology.
INT2 discussed the positive results of the team satisfaction surveys indicating that
most employees were happy to work on an agile team. He also shared a powerful story
about taking his young son to work, and just through observation, even he understood
that the agile teams were happier:
You know those days where you bring your kids to work? This was about halfway
through the transition; it was one of those days I brought my son to work. I'm
trying to explain to him what I was doing, and it's kind of hard. So I basically
said, “Look, we are doing something a bit different here. We are doing a different
way of doing software development. I want you to go into this bay, and have a
listen, and then go to this other bay and have a listen”. One was the traditional
cubicles, etc. etc. and the other one was one of the Scrum bays. I just said to him,
“Which one would you rather work in?” He said “This one, the noisy one.” I said,
“The noisy one? That's not a good place to work”. He said, “No, no, they seem to
be happy and laughing” and that kind of stuff. It was that obvious, even to a kid,
basically.
Summary
This chapter presented results of the data collection and analysis conducted for
this exploratory phenomenological study. Information was presented on how participants
were recruited as well as their demographic data. The analytical methodology was
described as well as the resulting themes that emerged from the data. Selected quotes
were presented for each of the lower-level themes that described their stories and
experiences in response to the research question: “How do project managers experience
and describe decision uncertainty associated with the agile software development
methodology?” Even though there were challenges, such as getting the organization’s
leadership to agree to adopt agile practices, getting the team on board, and dealing with
personal anxiety over how to perform their new role on the team, these challenges were
70
generally temporary. The participants spent the majority of the interview talking about
their realization of the benefits that they and their team experienced with implementing
agile methodologies.
71
CHAPTER 5. RESULTS, CONCLUSIONS, AND RECOMMENDATIONS
Introduction
This final chapter offers a summary of the study results, an analysis of how well
they answered the research problem, and the relationship between the results and the
research presented in the literature review. It also offers recommendations for future
research based on lessons learned from the study’s analytical methodology and results.
This chapter fits into the overall dissertation document by showing how previous chapters
support the study, and offering direction on how the knowledge gained from this study
can provide a foundation for future research efforts. The chapter will be organized in the
following sections: (a) summary of the results, (b) discussion of the results, (c) discussion
of the conclusions in relation to the literature, (d) limitations, (e) recommendations for
future research, and (f) conclusion.
The summary of the results will include a review of information presented in each
of the previous chapters. It will restate the research problem and explain the study’s
significance as described in chapter 1, provide highlights of the topics from the chapter 2
literature review, describe the research methodology presented in chapter 3, and recap the
study findings depicted in chapter 4. In the discussion of the results section, the findings
of chapter 4 will be interpreted in relation to the study research problem. These findings
will then be compared against the literature review results. A review and evaluation of
potential limitations with the research design, and data collection and analysis procedures
72
will be discussed, as well as how these limitations might have influenced the research
results. Recommendations will be offered on how these limitations might be addressed or
improved upon in future studies, as well as potential areas for follow-up research based
on the results of this study. The final section will sum up the entire dissertation and
highlight the major findings of the research.
Summary of the Results
The purpose of this phenomenological study was to describe and understand the
experiences of decision uncertainty for project managers of agile software development
teams. This software development methodology is different from the traditional, plan-
driven approach, in that it allows software requirements and design to emerge during the
project rather than be defined at the start. Agile methodologies acknowledge ambiguity
and uncertainty by accommodating and encouraging change. Transition to an agile
development methodology can be difficult for a project manager accustomed to a highly
structured plan-driven process. This study is significant because it addresses a gap in the
scholarly literature on how project managers experience and describe decision
uncertainty. Industrial/organizational psychologists can use the results of this study to
help ease project managers’ transition into agile projects. The results of this exploratory
study can also be used as a foundation to establish future qualitative and quantitative
research into this area of project management.
The literature review provided a thematic framework for understanding the
experiences of agile software development project managers. Topics relevant to
managing projects under uncertainty included complex adaptive systems, new product
development, traditional project management, agile project management, and decision
73
uncertainty. Literature on these topics was gathered from domains such as manufacturing,
software development, mathematics, business management, and psychology.
The research method selected for the study was qualitative because of the
exploratory nature of the research problem. A phenomenological approach was chosen
because it provided a method to understand the phenomenon through the stories of
multiple individuals who experienced the phenomenon first-hand. Moustakas’ (1994)
transcendental phenomenology methodology was used to analyze data from nine
participant interviews. The analysis methodology provided a means to identify topic-
related statements, defined meaning from these statements, grouped the meaning units
into themes, and created textual and structural descriptions of the experience of
uncertainty. These descriptions were grouped into two main categories, specifically, agile
challenges and agile benefits, and then each of these categories was reduced into multiple
high-level themes, which were further broken down into lower-level themes.
For the agile challenges category, the high-level themes related to problems
participants experienced in the following three areas: (a) with their organization, (b)
personally, and (d) with their team. Organizationally, they experienced several challenges
adopting agile. These included dealing with the disparity between the organization’s
traditional culture and the principles of the agile development methodology, persuading
senior leadership to adopt agile practices, and that implementing agile was difficult
because the organization’s traditional processes did not support it. Participants dealt with
several personal challenges related to adopting agile. These included experiencing
anxiety during the early stages of implementation, wanting to go back to the old way of
managing a project, dealing with the unknowns of evolving project requirements, and
74
unlearning their old role and learning their new role on the team. The participants also
experienced challenges with the project team to include dealing with their resistance to
change, determining how to handle those that did not want to change, and getting the
team to self-organize and take ownership of product development rather than relying on
the project manager for direction.
The second category was defined as agile benefits. Even though the research
question did not explicitly ask participants about their positive experiences, the majority
of the interview was focused on stories about their beneficial experiences as an agile
project manager. These included the following three high-level themes: Realization of
control, personal realization, and team realization. Participants discussed that their
experience as an agile project manager helped them to realize that they never had control
in the first place, and that this realization was liberating for them. From a personal
standpoint, they expressed the satisfaction of continually learning new things, that they
enjoyed coaching and facilitating the team, and that they had become more comfortable
with ambiguity. The participants also discussed how adoption of agile practices helped
the team. These included observations of an increase in the team’s willingness to
challenge the status quo and improve the team processes, the sense of empowerment
associated with acceptance of product ownership and making decisions on their own, and
that agile teams were generally happier than those on traditional projects.
Discussion of the Results
The results described in chapter 4 provided a holistic view of what it was like for
a project manager to experience decision uncertainty on an agile software development
team. These included experiences associated with the challenging aspects of decision
75
uncertainty, as well as the beneficial or positive experiences. Since the study was
exploratory, a phenomenological methodology was appropriate to discover these
seemingly contradictory experiences. On the surface, it would appear that the experience
might be very stressful for a project manager, especially those trained or experienced in
the traditional project management approach. The findings indicate that there were
challenging aspects of adopting a new way of managing a project, but that these were
only temporary. Descriptions of experiences by the study participants reveal that the
benefits were significant, and that they not only learned about their capability to handle
ambiguity and uncertainty, but also gained new awareness and understanding of how to
manage projects that exhibit high levels of ambiguity and uncertainty.
Discussion of the Conclusions in Relation to the Literature
This section will compare the research findings presented in chapter 4 with the
literature described in chapter 2. The literature review was used as a framework to assist
in understanding the experiences of decision uncertainty of the nine agile project
managers interviewed in the study. The framework consisted of the following five topic
areas: (a) complex adaptive systems, (b) new product development, (c) traditional project
management, (d) agile project management, and (e) decision uncertainty. The following
discussion presents how each of the five topic areas related to the research analysis.
Complex Adaptive Systems
The findings support the relationship between agile project management and
complex adaptive systems as described by Augustine et al. (2005), Benbya and
McKelvey (2006), and Meso and Jain (2006). Participants discussed the challenges of
trying to control a project that was continually changing, and the need to gain feedback so
76
that the team could learn and improve. They also discussed the change in their traditional
command and control role, to that of a facilitator and coach, enabling the team to achieve
the product vision. As suggested by Benbya and McKelvey (2006), an understanding of
complex adaptive systems might help project managers deal with uncertainty. It can offer
a mental schema to help members of agile teams understand the emergent, or non-linear,
nature of agile project management. For individuals who have a traditional mechanistic
mental map of how to build software, in that everything must be defined at the start and
then this plan must be executed as written, the thought of moving away from the high
control processes may initially seem to be contradictory. This would help the
development team understand the need and benefits associated with self-organization, a
characteristic of complex adaptive systems (Holland, 1998), the need for continual
learning (Meyer & Stensaker, 2006), and the need to continually challenge the status quo
in order to improve.
From a project manager perspective, the awareness of complex adaptive system
concepts can offer an understanding of how their role changes from the traditional
command and control leadership style that tries to remove ambiguity (Plowman et al.,
2007) to one that unites the team and influences their behaviors to achieve the project
vision (Marion & Uhl-Bien, 2007). This changes the traditional project manager role
from one focused primarily on managing the process to one focused on enabling and
leading the team to achieve the project vision.
New Product Development
Participant experiences related to many of the same realizations as those already
expressed in the new product development literature, such as the benefits of a co-located
77
team and the need for cross-functional teams to work closely together to solve problems
as described in the new product development processes called communications web and
disciplined problem solving (Cunha & Gomes, 2003). Additionally, the majority of the
participants discussed the need for constant feedback and the need to make the iterations
as small as possible so that decisions could be made when problems arise, and not wait
until a stage gate or project milestone. This introduced changes in how the teams handled
project estimation, adding initial anxiety for the project managers because they no longer
had the process to define the end-state from the start and then manage to it. It also added
stress for some of the team members, especially those described as being very resistant to
the new process, because they lost the ability to add a large buffer to their estimates. As
INT7 described, one team member was so uncomfortable with the need to provide an
accurate short term estimate that he gave infinity as the estimate for the tasks he was
assigned. Understanding how other business areas have adopted processes to manage
uncertainty and ambiguity, such as new product development, may help project managers
have a better understanding of what to expect and how to handle situations such as
resistance to new processes.
Traditional Project Management
Many of the anxieties and challenges that participants experienced at the
beginning of the transition to agile dealt with the change from a high control process, as
in traditional project management described by the Project Management Institute Body of
Knowledge (Project Management Institute, 2008), to an emergent process. Participants
expressed the desire to go back to the traditional way of managing a project, such as
planning things out in detail, in order to gain a sense of control. However, after
78
implementing the new processes they came to realize that this perception of control was
an illusion and that the project manager never had control over the project. This does not
mean that traditional project management is no longer appropriate for all projects, just
that it may not be best suited for those that include a high rate of change or uncertainty.
This emerging change in how project managers are beginning to view their work aligns
with Thomas Kuhn’s (1970) definition of a paradigm shift, yet in this case, it may not
require that the older paradigm be completely rejected.
Agile Project Management
Participants realized the benefits of having an alternative process methodology for
managing projects that experienced high uncertainty. One suggested that agile methods
offered an alternative to a death march, or a project doomed to failure from the start, as
described by INT8:
Well, it…funnily enough, was very satisfying because rather than having a death
march, what I proposed was a credible alternative path that might just work.
Fortunately, I had enough pull, if you like, and trust built into the trust bank.
People kinda gave me a chance to make it happen, and yeah, I did not disappoint.
Several participants also mentioned that they enjoyed the people-first aspect of
the agile processes, and INT7, in particular, said that it gave him the opportunity that he
needed to facilitate and coach the team: “I like the coaching and mentoring role, and the
agile process has given me an excuse to do that.” Even though the participants shared
many positive comments and stories, several cautioned that agile software development is
not a silver bullet, and that great caution should be taken to select the most appropriate
process, or hybrid of processes, based on the project context.
79
Decision Uncertainty
Participants expressed decision uncertainty and anxiety during the initial phase of
the transition from a traditional to agile methodology. From descriptions of the
participants, this change from a high control to high change environment also appeared to
have a similar effect on the team. Participants expressed the challenges associated with
the role change, that it made them feel like they had nothing to do at first (INT5), that it
took a while for them to figure out what they were supposed to be doing and how much
detail was acceptable to plan against (INT4), and worse yet, that the old role
“disappeared” (INT3). This initial uncertainty may be associated with some of the role
related stress issues defined by Ortqvist and Wincent (2006), specifically that there might
be conflict with role expectations, and ambiguity over what actions or behaviors the
participant needed to do to be successful in the new role. However, the loss of control,
which was expected to result in stress and a sense of helplessness (Bordia, Hunt et al.,
2004), was considered to be one of the positive realizations about being an agile project
manager.
Limitations
Several potential limitations may have had some effect on the study results. The
first is associated with the qualitative analysis approach. Due to the small sample size and
subjective nature of the data analysis, the results of this study cannot be generalized to a
larger population. However, generalization was not the intent of this exploratory study,
instead, the purpose was to discover how project managers of agile software development
teams experience and describe decision uncertainty. Other potential limitations are
associated with the data collection method and the study sample. For example, even
80
though the intent was to conduct face-to-face interviews, this was not possible because
the participants all lived a great distance from the researcher. It is possible that
observation of non-verbal communication such as body language and facial expressions
could have provided richer data to interpret the interview transcripts. In addition, eight of
the nine participants were involved in the decision to adopt agile in their organization. It
is possible that this influenced the positive experiences they shared, and that the
experiences may be different for project managers who were not part of the decision
making process. Another participant consideration is prior experience as a traditional
project manager. Six of the nine participants had traditional project management
experience, which may have resulted in higher initial anxiety concerning a perceived lack
of project control, as well as the challenges of learning a new role. Experiences may be
significantly different for project managers who are not familiar with traditional
approaches. These limitations will be incorporated into recommendations for future
research.
Recommendations for Further Research
It is recommended that future research make changes to the study sample, and
include a focused look into specific areas of the research findings. Because participant
involvement in the organization’s decision to adopt agile methods may have influenced
their positive experiences, it is recommended that a similar study be conducted on agile
project managers who specifically were not involved in the decision to adopt agile
practices in their organization. Their experiences may include more anxiety and
challenges, and fewer positive benefits. In addition, this study may identify various
81
coping strategies the participants rely on to manage their stress, to include avoidance
behaviors such as drinking or drug use (Kammeyer-Mueller et al., 2009).
Participants’ descriptions concerning their realization about control would lend
themselves to further research. Control over the project and team is a guiding principle of
traditional project management practices, yet when participants became comfortable in
their role as an agile project manager, they realized that it was an illusion or myth. It
would be interesting to determine if participants who had positive experiences with agile
methods also had an internal locus of control. An internal locus of control can help ease
stress associated with uncertain environments because the individual feels they have the
power to control the outcome (Kammeyer-Mueller et al., 2009). This might imply that
they feel that they can control their reaction to ambiguity and uncertainty. Studies could
also be conducted to determine if personality factors, specifically ambiguity tolerance
(Endres, Chowdhury, & Milner, 2009) may play a role in how comfortable an individual
is dealing with the complexity of an agile project manager role. The results of these
studies could be used to develop assessment tools to hire managers best suited for
uncertain environments, and to develop training programs to help ease project managers’
transition into uncertain environments.
Conclusion
The major conclusions derived from this qualitative study to explore how project
managers of agile development teams experience decision uncertainty revealed that there
was an initial period of decision uncertainty and anxiety, but that this was only
temporary. Even though the research question was about discovering how agile project
managers dealt with decision uncertainty, most of the interviews were devoted to positive
82
experiences. Adopting an alternative to the traditional plan-driven project management
methodology helped the nine participants of this study deal with the uncertainty and
ambiguity. In addition, it offered them insight into their perceptions of project control;
specifically that thinking you were in command of a highly dynamic project was an
illusion.
Agile methodologies also allowed project managers the opportunity to focus their
efforts on coaching and facilitating the team rather than directing them. As a result, the
project managers’ role changed from command and control of the overall project to
enabling the team to focus on product development by removing obstacles in their way,
protecting them from outside influences, and maintaining the project vision. This
research offered a positive perspective of how project managers manage uncertainty and
ambiguity on an agile software development project. It also offers an initial step toward
filling the current gap in the scholarly body of knowledge on this subject, and providing a
foundation from which to launch future qualitative and quantitative research.
