- Email: [email protected]
Two sides of the same coin – how agile software development teams approach uncertainty as threats and opportunities
Accepted Manuscript
Two Sides of The Same Coin – How Agile Software Development Teams Approach Uncertainty as Threats and Opportunities Denniz Donmez , Gudela Grote ¨ PII: DOI: Reference:
S0950-5849(17)30465-2 10.1016/j.infsof.2017.08.015 INFSOF 5873
To appear in:
Information and Software Technology
Received date: Revised date: Accepted date:
29 October 2015 15 July 2017 31 August 2017
Please cite this article as: Denniz Donmez , Gudela Grote , Two Sides of The Same Coin – How Agile ¨ Software Development Teams Approach Uncertainty as Threats and Opportunities , Information and Software Technology (2017), doi: 10.1016/j.infsof.2017.08.015
This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.
ACCEPTED MANUSCRIPT Highlights Uncertainty (impactful, incomplete information) is inherent in product development. Mostly regarded as threat, uncertainty also carries potential opportunities. Successfully managing uncertainty requires collaborative team practices. To distinguish opportunities from threats, teams combine different practices.
AC
CE
PT
ED
M
AN US
CR IP T
Our analysis of agile dev. teams details ten practices and four general principles.
ACCEPTED MANUSCRIPT TITLE Two Sides of The Same Coin – How Agile Software Development
AUTHORS Denniz Dönmez (corresponding author), [email protected] Gudela Grote, [email protected]
AN US
AFFILIATION ETH Zurich
Chair of Work and Organizational Psychology
ADDRESS
AC
CE
Switzerland
PT
Weinbergstrasse 56-58
ED
M
Department of Management, Technology and Economics
CH-8092 Zurich
CR IP T
Teams Approach Uncertainty as Threats and Opportunities
ACCEPTED MANUSCRIPT
ABSTRACT Context: Uncertainty affects software development projects in many ways. Capabilities to manage uncertainty can determine the success or failure of entire projects and even companies. Against failure rates of software development projects, uncertainty is often
CR IP T
viewed in a negative light. Its relevance as enabler of learning and innovation tends to be disregarded by scholars and practitioners.
Objective: This study extends research that empirically investigates approaches to dealing with different types of uncertainties. Acknowledging both the possibility for negative and
AN US
positive consequences of uncertainty, we aim to expand existing knowledge and contribute to improving the practices to handle uncertainty in software development. Method: A multiple-case study including field observations and in-depth interviews with 42
M
professional software developers was performed with a sample of 11 agile software development teams from different Swiss companies.
ED
Results: We detail practices employed to mitigate threats while simultaneously allowing teams to remain open to opportunities. We establish a taxonomical classification of
PT
uncertainty in software development, which extends beyond often-addressed requirements
CE
uncertainty and additionally includes uncertainty related to resource availability and task specifications. Against the background of different uncertainty types, we discuss distinct
AC
practices and four overarching principles to approach uncertainty using strategies for threat avoidance versus opportunity realization. Specifically, we find that employed practices are guided by 1) uncertainty anticipation, 2) information accrual, 3) solution inspection, and 4) role-based coordination. Conclusion: We argue that approaches to dealing efficiently and effectively with uncertainty can be improved when teams distinguish between different types of uncertainty and treat
ACCEPTED MANUSCRIPT them explicitly as threats versus opportunities. Whereas potential to seize opportunities is under-used, agile methods could evolve into better frameworks supporting the systematic search for innovation. We discuss the implications of our findings for agile development teams in particular and product developing organizations in general.
CR IP T
KEYWORDS: Uncertainty; Risk; Threat;
AN US
Opportunity; New Product Development; Agile Software Development;
AC
CE
PT
ED
M
Multi-case study;
ACCEPTED MANUSCRIPT 1. INTRODUCTION Uncertainty is one of the fundamental facts of life. It is as ineradicable from business decisions as from those in any other field. F. H. Knight [1, p. 347]
Uncertainty pervades the work of software development teams. It affects many
CR IP T
decisions and is highly critical for project performance [2-4]. Software development teams cannot afford to ignore uncertainty, because it can lead to increased development costs, low product quality, delayed product delivery and dissatisfied customers [5]. The criticality for software development projects is increased by the fact that uncertainty can stem from
AN US
different sources and affect many different aspects of software development, which makes it difficult to ‗manage‘ [6]. It is not possible to effectively manage uncertainty in a way that achieves full control over it. We adopt the perspective that uncertainty management should
M
rather be viewed as the approach that is taken in order to deal with uncertainty. Given a specific situation, when managing uncertainty, teams may choose between different
ED
approaches, including to investigate uncertain issues (and thereby reducing uncertainty or
uncertainty [7].
PT
shifting it to another issue), to deliberately ignore uncertainty, or even to increase
CE
Different approaches are important because uncertainty is not inherently good or bad. Whereas uncertainty affects decisions that can cause projects and even entire companies to
AC
fail, uncertainty is also a vital predecessor of innovation [8]. No economic profit exists without uncertainty [9]. Hence, uncertainty management occupies a critical role in software and other product innovation projects, where levels of uncertainty are high [10, 11]. Yet, few acknowledge the ―dual nature‖ of uncertainty that bears the possibility for negative as well as positive effects [12].
ACCEPTED MANUSCRIPT Much of the literature on uncertainty has ignored beneficial aspects and has instead argued for the reduction of uncertainty [13]. For example, authors have discussed the need to reduce uncertainty arising as a consequence of changing requirements because of their potentially large impacts on development projects [14, 15]. Thorough planning is often advised to avoid negative impacts on product quality, as well as on project schedule and cost,
CR IP T
which are known as the triple constraint or ‗iron triangle‘ [16]. Recently, however, cautioning voices increase, which criticize a focus on planning for its ignorance of potential opportunities [17, 18]. Innovation research points to the benefits of developing capabilities to incorporate design changes even at late stages in the project [19, 20]. While the reduction of
AN US
negative consequences from uncertainty is increasingly addressed in the literature [21], there is scant guidance and insufficient insight for product development teams regarding the question of how to reap positive effects of uncertainty through appropriately suited
M
approaches. Specifically, little is known about if and how the same approaches employed by teams can bring about positive and negative consequences of uncertainty.
ED
Highly collaborative approaches to software development, such as Agile Software Development [22], aim to enable teams in responding to uncertainty and the unforeseeable
PT
changes caused by it [23]. Uncertainty has tremendous impacts on projects, and its
CE
management remains one of the largest unresolved challenges for teams and the organizations they belong to [24, 25]. Several scholars point out that the current trend to
AC
increasingly employ agile software development techniques acknowledges the need to manage – as opposed to reduce or control – uncertainty by undergoing cycles of inspection and adaption to changes [23, 26, 27]. Agile development methods provide some important guidance that affects how teams approach uncertainty, however, often only implicitly so. As a result, there is room for improvement regarding their capacity to innovate which is connected to the systematic search for opportunity [28]. In particular, we study agile software
ACCEPTED MANUSCRIPT development methods to shed light on the potential provided by different, complementary agile practices to consider different types of uncertainty and view uncertainty not only as potential threat but also as potential opportunity. The main research question underlying our study is: How do agile software development teams approach different types of uncertainty as threats and opportunities? In
CR IP T
the context of this question, several other aspects are important: How are software development projects influenced by different types of uncertainty and how can teams deal with these different types of uncertainty? How is information collected, analyzed and used in
teams as threats and/or as opportunities?
AN US
order to handle uncertainties? Are uncertainties viewed and approached by development
To answer these questions and to investigate strategies and practices for the management of uncertainty, we conducted an empirical study that explicitly acknowledges
M
both threats and opportunities (i.e., the potential to create innovation) embedded in uncertainty. We draw on the uncertainty management literature to derive different types of
ED
uncertainty and to subsequently investigate the practices teams use for their management. While agile software development methods seem especially well suited to handle (especially
PT
the negative consequences of) uncertainty, an important contribution of our study lies in the
CE
differentiation between positive and negative uncertainties. We derive implications for researchers and practitioners based on the premise of fully acknowledging these two
AC
contrasting qualities of uncertainty. In the following sections, we first explain how uncertainty has been conceptualized and
distinguished from risk or threat. We delineate different perspectives on uncertainty and present an investigation of how distinct types of uncertainty are approached in agile software development projects. Based on the empirical investigation of strategies for uncertainty management, we solidify the understanding of uncertainty management as a team-based
ACCEPTED MANUSCRIPT endeavor of addressing both threat and opportunity embedded in uncertainty. Our findings are structured along a taxonomy of uncertainty that we link to different strategies for approaching uncertainty. While our results detail the efficacy of different agile software development practices to address uncertainty, they also permit conclusions regarding overarching principles that may guide product development teams in settings beyond agile
CR IP T
software development.
2. THEORETICAL BACKGROUND
AN US
2.1 DEFINING UNCERTAINTY
The concept of uncertainty centers on missing information [13]. However, as Argote notes, ―there are almost as many definitions of uncertainty as there are treatments of the subject‖
M
[29, p. 420]. Their commonality is incomplete information, or ―not knowing for sure‖ [30]. Yet, the ―manifold nature of uncertainty‖ [31] covers a range of aspects including risk,
ED
ambiguity, and equivocality. Hence, we need to ascertain further qualities of these concepts in order to grasp uncertainty empirically.
PT
While it may be difficult to determine exactly what uncertainty can be manifested in,
CE
we can move the attempt of a definition forward by contrasting it with similar concepts. For example, uncertainty entails ambiguity, which is associated with confusion over several
AC
possible interpretations [32]. Furthermore, uncertainty is often associated with risk [33]. Scholars acknowledge a fundamental difference between risk and uncertainty, however, that can be traced back to Knight [1], who put forward the idea that risk can be assigned a probability, whereas uncertainty refers to something that is immeasurable. This essential difference has since permeated the literature to this day and is reflected in the works of many authors such as Aven and Renn [34] and Paté-Cornell [35]. Hillson [36] nicely summarizes
ACCEPTED MANUSCRIPT the difference as follows: ―Risk can be said to be aleatoric [from the Latin word alea, meaning dice], whereas uncertainty is described as epistemic [which is derived from the Greek word episteme, meaning knowledge].‖ This indicates that risk refers to an unknown event that leads to one outcome from a set of known outcomes, each of which can be assigned a probability (however estimated). Uncertainty, in contrast, relates to a lack of
CR IP T
knowledge about which outcomes are possible, including both ―their nature and associated probabilities. An ‗uncertainty‘ is thus an unknown event from an unknown set of possible outcomes‖ [36, p. 27]. Another way Hillson [36] offers to distinguish the relationship
―Risk is measurable uncertainty; Uncertainty is unmeasurable risk.”
AN US
between risk and uncertainty is captured in the following couplet:
As a result, it may not be able to approach uncertainty by the same means as risk [37].
M
Holt summarizes that ―uncertainty pertains where probability has no grip‖ [38, p. 253]. Following product development researchers, we rely on a conceptualization of uncertainty
ED
that encompasses the impact of ―anything that matters‖ [33, p. 98], defining it as the lack of certainty that leads to a situation in which ―potential outcomes and causal forces are not fully
PT
understood‖ [39, p. 438]. Specifically, in line with Hillson [15, 40] we define uncertainty as
CE
incomplete information that bears the potential for positive or negative consequences of high impact on project objectives. In other words, uncertainty is the discrepancy between the
AC
information that is available and the information that is required (but not yet available) toward reaching a goal [41]. It is important to note that, in divorcing risk from uncertainty, Knight has also
established uncertainty as the underlying reason for corporate profit (based on the argument that risk can be assigned expected values, therefore inviting the possibility for insurance), and he warned that the consequences of uncertainty can also be negative [1]. An organization‘s
ACCEPTED MANUSCRIPT welfare, therefore, results from exploiting the potential of uncertainty without exposing itself overly to its negative effects [38]. Over the course of a project, diverse situations arise in which teams must distinguish between threats and opportunities. Enabling them to do so, therefore, is a prerequisite for the successful management of uncertainty. A focus on uncertainty rather than risk has been suggested to enhance project
CR IP T
management by ―providing an important difference in perspective, including, but not limited to, an enhanced focus on opportunity management― [33, p. 97]. Although neither risk nor uncertainty are necessarily harmful, both are usually associated with negative rather than positive aspects [33]. Although we have not excluded the literature on ‗positive risk‘ for this
AN US
study [13, 36, 42], we refrain from using the term ‗risk‘ in this study in order to avoid confusion. Instead, we use the terms ‗threat‘ and ‗opportunity‘ when we refer to any negative or positive associations of uncertainty, respectively. By definition, opportunity refers to ―a set
M
of circumstances that makes it possible to do something‖ (New Oxford American Dictionary) and creates or adds value for the customer or end user [43]. Following Hillson [40], we use
ED
the term opportunity for any positive influence toward the benefit of a project that is not necessarily envisioned at its outset but rather recognized during the course of the project. An
PT
Example is an unexpectedly discovered business opportunity. In contrast, we use the term
CE
threat to refer to any potential negative association, such as the threat to delay the project or
AC
increase the budget that is necessary.
2.2 TYPES OF UNCERTAINTY
Studies of uncertainty usually do not consider different types of uncertainty. They either treat the concept as a singleton, or narrow their focus on one specific type, such as requirement uncertainty, while ignoring others [8]. Recognizing differences within the conceptualization of uncertainty is important for successfully approaching them [44], because various strategies
ACCEPTED MANUSCRIPT may exist to cope with several types of uncertainty [31] and different approaches can hold distinct implications for development projects [45]. However, defining different categories to study uncertainty can be achieved in many ways. Krane and colleagues note that an abundance of categories can be—and have been— constructed by scholars, and advice that categorization schemes should be generic in order to
CR IP T
be unbiased by the way in which one organizes one‘s world [46, p. 83]. Constructing two categories, such as to distinguish uncertainties that result from internal versus external sources [13], may, however, yield insufficient potential to derive meaningful implications for teams. On the other hand, defining a scheme with many types of uncertainty may introduce
uncertainty
(technology,
market,
AN US
unnecessary complexity to a study. For example, Jalonen‘s [8] eight different types of regulation,
social/political,
acceptance/legitimacy,
managerial, timing, and consequence uncertainty) are not suited to our study of software
M
development teams because they are ill-defined with regard to the exclusivity of each category; when studying uncertainty, we need to be able to attribute our findings
ED
unequivocally to one type with confidence. A scheme that contains a number of uncertainty types that are mutually exclusive
PT
while they are also exhaustive is presented by Moran [28]. It explicitly addresses three
CE
aspects, including requirements (which is the most covered aspect across all studies), as well as project, supplier and schedule (which are related to the availability of resources), and
AC
technical and people aspects (which are concerned with work or task related issues). We rely on these three different, overarching aspects to inform our study, which explicitly spans a set of different uncertainty types to investigate positive versus negative aspects. We adopt the categories of a) requirement related uncertainty; b) resource related uncertainty; and c) task related uncertainty, as we find these overarching types to be prevalent in the software development literature [45, 47-50].
ACCEPTED MANUSCRIPT Requirement uncertainty is the projection of distinct external sources of uncertainty stemming from changes in the market, as well as from regulatory, social, or political changes [8]. Requirements uncertainty is conceptualized as incomplete information regarding product functionality [2], and includes different aspects, such as volatility (environmental turbulence) and ambiguity about the correct interpretation of environmental signals [51]. Requirements
CR IP T
uncertainty is central in software development and is often addressed in the literature [52], [53].
Resource uncertainty refers to incalculable means of production that are necessary to complete the work [50]. The resources that are necessary to accomplish software
AN US
development projects, which are subject to uncertainty, include the fundamental production factors of human [54] and financial capital [55]. They span the unpredictable or unreliable availability of software development capabilities and necessary infrastructure, such as
M
software licenses, test user accounts, and other means of production.
Task uncertainty refers to the lack of knowledge regarding the best way to approach
ED
a work related problem. This can, for example, stem from inexperience or insufficient knowledge concerning the employed technologies [45]. In the IS literature, task uncertainty
PT
often refers to either inexperience concerning the employed technology or to an insufficient
CE
understanding of a problem in order to complete a task [56]. Software developers commonly experience task uncertainty with regard to optimal solutions to novel problems, or incomplete
AC
information regarding the capabilities and knowledge needed to accomplish a task. The distinction of types of uncertainty in the software development literature
introduces the possibility of threats and opportunities arising in different ways for each type. Therefore, software development teams need to be wary of differences and develop a portfolio of adequate approaches for their exploitation versus mitigation.
ACCEPTED MANUSCRIPT
2.3 DEALING WITH UNCERTAINTY There is a long history of recommendations for the reduction of uncertainty, which is accompanied by attempts to increase control over development processes [48]. While uncertainty is ―inherent to every aspect of software development‖ [5], no widely accepted
CR IP T
general framework has emerged for the management of uncertainty.
More recently, scholars started to emphasize the importance of flexibility in order to manage uncertainty [57]. Arguing for the need to react quickly to unforeseen events, this stream of literature acknowledges levels of complexity that deem any attempt for control
AN US
utopian and, hence, favors agile development approaches.
These two different practices can be attributed to two general approaches to manage uncertainty; coping with uncertainty versus minimizing uncertainty [30]. Minimization is
M
aimed at the increase of control and based on strategies to eliminate as much uncertainty as possible. While this seems desirable at first sight, it may be neither possible (e.g., when the
ED
source of uncertainty lies beyond the influence of the uncertainty manager), nor most beneficial in important situations (e.g., when an uncertainty turns into an opportunity).
PT
Coping strategies, in contrast, do not aim to eliminate uncertainty, but manage it flexibly.
CE
This, however, requires increased effort and follows no standardizable procedure. For example, coping mechanisms may require deferring problems [17] while additional
AC
information is collected, or decision makers might rely on assumptions or intuition [31]. Choosing not to eliminate but rather to cope with uncertainty implies acknowledging that some uncertainties cannot be eliminated, and furthermore, to recognize that the elimination of certain uncertainties would lead to a deprivation of opportunities for innovation [20, 58]. Successful approaches to uncertainty reach beyond preempting the consequences of threats. It is the attempt to exploit the benefits of uncertainty while avoiding exposure to its
ACCEPTED MANUSCRIPT negative aspects. Thus, software developers are charged with managing uncertainty in a way that aims at controlling threats while simultaneously remaining receptive for opportunities that may arise from the same sources.
2.4 AGILE SOFTWARE DEVELOPMENT APPROACHES TO UNCERTAINTY
CR IP T
In software development, the perception of uncertainty is dominated by requirements uncertainty [47, 50]. Diverse measures for requirements uncertainty have been proposed in order to mitigate resulting threats to product performance [59, 60]. For example, the improvement of communication and planning practices are prominent among the
AN US
propositions for improved robustness of requirements [61]. However, unsuccessful attempts to protect requirements from changing have spawned alternative approaches that structure development around cyclical phases of step-by-step refinement [59], which allow
M
development teams to meet unforeseen situations with the possibility to react flexibly when changes occur. This development reflects the critique on up-front planning in complex
ED
projects. Accordingly, endeavors to meet the triple constraint (cost, time, quality) are increasingly replaced by iterations of re-planning [62]. Different agile methods have been
PT
adopted by large numbers of software development teams in the last decade [63]. By
CE
introducing flexible techniques to react to changes, they offer an approach that differs starkly from traditional plan-driven project management [64, 65]. In particular, they supply teams
AC
with practices that support uncertainty management by equipping developers with considerable flexibility [66]. Importantly, uncertainty management is not equated with the minimization or elimination of uncertainty per se, but part of the strategy to inspect and adapt to unexpected events. However, the potential of agile software development methods for a proactive approach to carefully observing and possibly even fostering (as opposed to categorically eliminating) uncertainty to facilitate its management is not explicitly discussed
ACCEPTED MANUSCRIPT in a straightforward manner, and different agile methods need to be combined to address several types of uncertainty. Agile methods explicitly suggest practices for team coordination such as frequent planning and empowering developers to self-organize in support of coping with uncertainty [23, 25, 48]. Of these methods, especially Extreme Programming (XP) [67] and Scrum [66]
CR IP T
are most widely adopted by agile software developers and have been studied predominantly [68]. Scrum, for example, suggests a managerial (as opposed to engineering practices) approach to development projects in its emphasis on collaboration structures and team autonomy. Investigating relationships among project control, team autonomy, and project
AN US
performance Maruping and colleagues found that the use of agile methods is most effective in environments with high levels of uncertainty [48]. Scrum does not provide explicit suggestions using the language of uncertainty management. Still, it addresses the concept
M
especially in the form of minimizing requirements uncertainty. Development teams often complement it by borrowing from XP, which offers complementary computer programming
ED
practices, which in part support teams in addressing uncertainty. For example, prototyping and incremental task planning inform and starkly impact the potential of teams to deal with
PT
different types of uncertainty without being based on their elimination. XP practices,
CE
however, do not cover overall project level requirements. Therefore, teams need to develop agility based on combinations of different agile methods.
AC
Agile practitioners use of short development iterations of two to four weeks that are
interrupted by customer feedback loops primarily to support teams in minimizing threats from volatile or ambiguous requirements through the frequent and regular validation of their work by stakeholders. Scrum also advocates team retrospective meetings for reviewing work processes after each iteration, and suggests a number of meetings to plan iterations and carry out daily meetings to mutually update team members. Supported by visualization tools, these
ACCEPTED MANUSCRIPT meetings facilitate the monitoring of projects with regard to several aspects including requirements changes and the forecasting of short term productivity. Emphasis is laid on empirically testing solutions, for example, by rapid prototyping and incremental improvement. These activities foster collecting information incrementally and thereby support the quality of decision making [54]. Different agile methods suggest a number of
CR IP T
practices that extend well beyond the use of iterations. However, there is a lack of guidance for practitioners with regard to the management of uncertainty (as opposed to their reduction). This is not only lamentable but also incomprehensible given the wide acknowledgement of the need for uncertainty management in the agile software development
AN US
literature [27, 69].
Agile software development methods attend to the need for uncertainty management more than classical approaches to software development [70], yet, as Moran [28] concludes,
M
they do so only passively and implicitly, which can lead to misdirected and misunderstood activities. More importantly, their potential for systematically addressing opportunities that
ED
arise from uncertainty has largely remained under-studied. On the one hand, reaping this potential requires increased understanding for how decision makers distinguish threat from
PT
opportunity. On the other hand, it is important to investigate if and how threat and
CE
opportunity can be managed using the same mechanisms for addressing uncertainty. These questions are important as they affect the core activities of development projects. Therefore,
AC
we seek to explore practices, i.e. activities commonly employed by agile software developers, as well as overarching guiding principles that stretch beyond the suggestions provided by agile methods. To better understand the practices employed and principles followed to handle uncertainty both in terms of avoiding threats and capitalizing on opportunities, we designed a qualitative study of agile software development teams outlined in the following section.
ACCEPTED MANUSCRIPT 3. RESEARCH APPROACH In order to capture how teams deal with different types of uncertainty, we performed a multiple-case study [71] based on observations and semi-structured interviews with professional software developers across different research sites. Multiple-case studies allow to identify patterns in organizational practices [72]. They are suited to examine contemporary
CR IP T
corporate phenomena, such as agile development techniques, triangulate information gathered in their natural context [73] based on multiple data sources [71].
3.1 SAMPLE AND DATA COLLECTION
AN US
Data collection included field observations and 42 face-to-face interviews with professionals from 11 agile software development teams. Our sampling strategy focused on teams employed in settings with considerable levels of uncertainty, where agile development
M
methods are often employed. All teams followed the Scrum method, while some teams complemented it with development techniques from Kanban and XP, such as work-flow
ED
limitation (to constrain focus on a small number of tasks), pair programming (where two programmers collaborate by simultaneously sharing one computer), test-driven development
PT
(where quality criteria for the software code are defined prior to writing the code), and other
CE
complementary techniques not originally included in the Scrum framework. The teams also modified the framework to fit their specific needs. For example, some teams altered the
AC
iteration lengths when needed, and none of the teams had a full-time Scrum Master. The teams in our sample belonged to five software-developing companies from
different industries that are located in Switzerland and operate globally. While we strove for depth by capturing situations in agile teams with similar features (e. g., team tenure, team size), we deliberately selected teams that might face various types of uncertainties (e. g., because of differences in product and customer structures, or being situated in different
ACCEPTED MANUSCRIPT industries.) Details regarding the teams‘ project characteristics are summarized in Table 1. Interviews ranged from 20 to 90 minutes (43 minutes on average). All interviews were audiorecorded and transcribed verbatim as soon as possible after they had been conducted. During data collection, we visited each team at several points in time over the course of their projects, and had the opportunity to meet most of the team members informally. We also had
CR IP T
the possibility to talk with different internal and external stakeholders of the software development projects to discuss the research progress, verify insights and clarify our understanding where necessary. When the answers to our questions ceased to provide new information and started to become similar of previously collected responses, i.e. no additional
AN US
insights were gained from further interviews, and the situations and practices described to us were repeated across participants in a congruent way, we concluded that we had reached theoretical saturation [74] and stopped collecting more data.
M
-----------------------------------Insert Table 1 about here
ED
------------------------------------
We conducted interviews with individuals holding as many different functions as
PT
possible within their team, following a self-imposed policy to always include at least one
CE
team member outside of the development team, i.e. the Scrum Master or Product Owner, and two team members with distinct software development tasks. In each team, the first author
AC
conducted formal interviews with software developers and team leaders. The multiple sources in each team allowed to us triangulate situations from the perspectives of different team members, which increased the quality of our data [75]. To guide our interview questions, we adopted a theoretical framework consistent with the literature on uncertainty management that suggests that multiple uncertainty types govern project work. Based on different types of uncertainty, we produced a semi-structured
ACCEPTED MANUSCRIPT interview guideline to cover different uncertainties; however, during the interviews the first author also followed interesting clues and probed for details whenever he felt this would contribute to a more thorough understanding. Interview partners were asked how their teams had dealt with uncertainty in different situations in the past and during ongoing projects. They were encouraged to share examples for incidents that had either positive or negative
CR IP T
associations. This approach was based on probing for critical incidents [76], but allowed for flexibility when we felt this was appropriate. We encouraged participants to talk openly about situations, which they had experienced in their teams. The teams were informed about our research objective to investigate the management of various types of uncertainties that are
AN US
faced in software development projects, and were subsequently asked about a number of situations in which they or their teams experienced resolved or unresolved problems or difficulties of any kind. We also asked for specific examples of experiences that had occurred
M
a) recently and b) during the course of the entire current project. In each case, we probed for further information in order to obtain a better understanding of the situation, including
ED
descriptions of relevant information such as preceding events or reactions by stakeholders. In some cases, we were able to exploit this knowledge in subsequent interviews in order to
PT
capture different views of issues that the teams had experienced. This allowed us to construct
CE
and analyze situations based on descriptions from different perspectives. Our data collection was guided by the exploration of how the teams dealt with
AC
different uncertainties, namely regarding requirements, tasks and resources. Interviews commenced with a set of general questions (e.g., regarding the status and progress of the project), subsequent to which we would ask specific uncertainty-related questions such as, ―Has there ever been a situation in which your team was unsure about the best way to complete a task?‖ or ―Do you remember a situation in which the availability of team members was uncertain?‖ In most cases, we had to clarify the concepts we wanted to study
ACCEPTED MANUSCRIPT by examples or, otherwise, use vocabulary from a software development context in order to correctly comprehend our questions. We further inquired about the consequences and subsequent actions taken. As we commenced to systematically analyze the data, we increasingly let clues that we developed influence subsequent data collection by extending our interview guideline and
CR IP T
including further interesting aspects as far as this did not compromise the time to cover our initial set of questions regarding the management of uncertainty. This allowed us to understand the teamwork context more fully and helped us to develop interesting insight
AN US
regarding the potential and boundary of uncertainty management.
3.2 DATA ANALYSIS
We performed data analysis in an iterative fashion, oscillating between data collection and
M
analysis as we repeatedly returned to the field for additional observations and interviews.
teams for clarification.
ED
Especially whenever we felt a lack of understanding of our data, we strove to revisit the
In order to make sense of our data, we began by reading through the field notes and
PT
interview transcripts that were produced after the field visits. This allowed us to establish an
CE
overview of the data according to our initial questions regarding the way in which teams manage positive and negative aspects of uncertainty and their possible different impacts for
AC
different teams, which may face different uncertainty types at certain stages in their projects and consequently employ different approaches. To systematically analyze the data, we began coding the interview transcripts by
assigning codes for different team based activities. Our initial coding scheme was influenced by our reading of the agile software development literature (e.g., it contained codes for prototyping, stakeholder integration, etc.). We extended the coding scheme whenever we
ACCEPTED MANUSCRIPT found practices that are not explicitly covered by agile methods (e.g., some practices for knowledge management, recruiting and onboarding of team members, etc.). To support the coding process, we used HyperResearch, a computer software for qualitative data analysis. We also relied on spreadsheets in order to record interim results and systematically organize emerging insights. To increase the reliability of the coding process, a
CR IP T
student researcher with experience in agile software development was involved in part of the data collection and data analysis. He was familiar with the research questions but not with our coding scheme, and coded part of the interview data independently from the authors. Comparing our results, we were able to validate our coding scheme to capture the practices
AN US
employed for managing different uncertainty types in the development teams. Differences between the student assistant‘s codes and our coding scheme were resolved in clarifying discussions with the first author until a common coding scheme displayed high congruity.
M
During this process, we were able to further refine our codes in order to capture more specific practices in the context of uncertainty management. For example, stakeholder
ED
integration was further detailed and split with regard to a) the content of communication (e.g., information exchange and clarification of issues) and b) temporal aspects (e.g., allowing
PT
change requests only at certain points in time). A list of our codes and practices, as well as
CE
principles derived from them is provided in Appendix B. While our coding scheme evolved to reflect different practices during our data
AC
analysis, we were not able to uniquely map practices to uncertainty types (some practices targeted more than one type of uncertainty). However, we created characteristics for each type to capture further details (e.g., requirements uncertainty carried sub-categories, or characteristics, for a) lack of information about demanded functionality, b) ambiguity, and c) unexpected changes.) We decided to proceed with the attempt to derive commonalities regarding uncertainty management practices, i.e. distinguishable strategies that address
ACCEPTED MANUSCRIPT different types of uncertainty. We were able to establish ten distinguishable practices, and grouped them according to their overarching objectives detailed below. What emerged were four principles, which span the ten practices.
4. STRATEGIES FOR THE MANAGEMENT OF UNCERTAINTY
CR IP T
We identified different uncertainty management practices applied by agile software development teams, and grouped them according to four general principles, which reflect the shared characteristics and the common focus that several practices share (e.g., the inspection and evaluation of feasible solutions). The principles were developed to structure the observed
AN US
practices based on their similarities in terms of objectives or involved activities. An overview is provided in Table 2. Some of the practices reflected the fact that teams organized their work in line with agile software development methods, which center on iterative and
M
incremental development. Teams combined different agile techniques to carry out different practices in order to meet specific demands of uncertainty management. All teams in our
ED
study faced several situations in which uncertainty emerged with regard to requirements, tasks, or resources. Sometimes these turned into opportunities, and sometimes they produced
AC
CE
detail below.
PT
threats. Teams employed different practices depending on the specific situation, which we
-----------------------------------Insert Table 2 about here ------------------------------------
ACCEPTED MANUSCRIPT
4.1 UNCERTAINTY ANTICIPATION 4.1.1 Planning with uncertainty The teams we studied engaged in frequent planning activities to produce just enough shortterm clarity and guidance regarding necessary steps toward a development goal, and tried to
CR IP T
accommodate for events that require a change of the produced plans as much as this was possible. Whereas such events could develop into impediments or opportunities, both cases require re-planning. Re-planning was, thus, a default option over which no team seemed surprised; they almost anticipated the possibility for produced plans to be short-lived: “[We
AN US
don’t] specify everything from the beginning and […] sometimes that business idea translates into something at the end that you wouldn't expect in the beginning, and it's often for the better,” (Product Owner, Team I).
M
In our data, the discovery of opportunities was most often related to newly arising business possibilities based on added functionality that was not included in the initial list of
ED
product features. For example, some teams realized opportunities based on change requests that became profitable only when cross-sold to other customers, which would not have been
PT
worth pursuing otherwise. Teams had to rely on their assessment of the market value for
CE
requested product features. This happened in Team G, which extended their product‘s functionality against specifications for the given software release after receiving a request for
AC
additional functionality by one of many customers. This altered the features initially intended for the subsequent product version, which were allocated to development iterations on an annual basis. In this case, betting on the change proved profitable. Yet it incorporated large uncertainties because the accuracy of effort and market value estimations was not known. In other words, it was unknown in the beginning if any potentially developed product feature,
ACCEPTED MANUSCRIPT including one discovered to provide new a business opportunity, turned out to be a threat to available resources, requiring more time or delivering less market value than expected. Without exception, teams often faced the pressure to react flexibly and adapt continuously. While team leaders emphasized adaptation more in business terms, team members tended to regard the need for adaptation regarding technical issues. Despite their
CR IP T
different perspectives, both stances caused them to remain open to alternatives that could either become necessary or more attractive. In one reported incident, a new customer approached the team manager of Team C with a feature request, which changed the market values of the planned features and reshuffled the priorities of the requirements list. Although
AN US
unexpected, the customer‘s demand increased the value of a feature that was low on the list of priorities and not expected to be completed within the year‘s software release. Developing of this feature was discovered to add value for other existing customers, and caused an
M
increase in the project‘s budget that the team or project leader had not expected initially. This example elucidates that it is important and desirable to be able to suspend decisions until
ED
more information becomes available. The pursuit of this emerging opportunity would not have existed if the scope of the product functionality had been specified unchangeably at the
CE
PT
outset of the development.
4.1.2 Developing vigilance
AC
Vigilance, a state of alertness to potential scenarios, emerged in our data as one of the most valuable assets in turning uncertainties into opportunities. Development teams need to remain alert to all types of potential uncertainties and their implications, as it is not clear in early stages of a project what a specific uncertainty may develop into. Teams summarized this as follows: “…throughout the year, there are, I would say, incidents, for example licensing
ACCEPTED MANUSCRIPT problems […] or positive events, they also occur. Like a project that has a change request, an add-on […which] also means, they bring money,” (Product Owner, Team G). In developing a mindset that is alert to technical and business opportunities, team members were vigilant to any shortcuts to the project goal. Sometimes, this required that the project goal be modified into a more profitable one. Oftentimes, this included substituting
CR IP T
originally planned product functionality by similar functionality. For example, one team decided to make changes to the design of the project setup; the original product was split in two parts upon realizing that it would be easier to work separately on different parts. Tasks were distributed between two sub-teams, who then realized that the separate product parts
AN US
they worked on needed some communication interface. While the separation of the project brought a number of uncertainties regarding requirements and resources, the team estimated it produced less task uncertainty. More importantly, this was turned into a business
M
opportunity that was discovered by the developers in the team: “when we split our projects up into different projects internally in the company, and we had to have an API [application
ED
programming interface] from one to the other, and so we found 'Well if we do it like this, we can sell the API, just the bare bones technical thing as a second product.' The developers
PT
thought of something and it turned into a product right away and we fond a customer [for
CE
it]” (developer, Team J). Here, an opportunity was realized when the separation of tasks led to the idea to offer added functionality not only internally, but also to offer it as added
AC
product value to existing and new customers. The vigilance developed by teams is important for the pursuit of opportunities, but it
is also important because it helped teams to manage threats proactively. For example, one developer described how she remained vigilant for threats when dealing with customer service requests: ―When someone sais: The server is down, then I can have a look myself and check if the server is really down and […] see if I can find out why it is down. Because this
ACCEPTED MANUSCRIPT shouldn’t be the case. Theses sort of things. But then it could be a user comes and sais he doesn’t have permission for something, but according to security I see all necessary rights, then this sounds rather like a bug to me, so I would take a look at that, what could cause that. But before I spend more than half an hour on that I say: OK, I can’t fix it myself, so I pass it on‖ (developer, Team M). Based on her experience, the developer gauged the possibility for
CR IP T
an error to be caused by a software bug that requires further attention. Her statement describes the importance to remain vigilant in order to distinguish minor problems from threats that will draw further resources.
AN US
4.2 INFORMATION ACCRUAL 4.2.1 Incremental feedback
Strongly influenced by the project management framework Scrum [66], teams followed a
M
number of principles that are geared toward dealing with requirements uncertainty. Frequent feedback from within the team, as well as from external project stakeholders on incremental
ED
development outcomes, was seen as very important. Teams developed specific communication practices for the giving and receiving of feedback, many of which relied on
PT
informal and ad-hoc conversations. In addition, teams structured much of their product
CE
specific feedback with the help of project tracking tools such as Jira, where progress was documented. A few teams invited their clients to access this documentation in an attempt to
AC
involve them closely in team-internal communication. Clients were linked to the team either through team leaders, or connected directly with developers who needed clients‘ input. Clients were mostly absent from team areas where developers worked, but were required to be present at meetings several times per month, and development teams demanded their daily availability via email and telephone. Developers sought feedback from their team members on a daily basis. They clarified technical details with co-workers and discussed requirements
ACCEPTED MANUSCRIPT with team leaders. One developer commented: ―you get a lot [of] earlier feedback [so] that you can react and […] adapt and discuss and change‖ (developer, Team K). Development iterations served as larger time frames within which developers of all teams could collect feedback on incremental improvements of the software product from external project stakeholders. As more information regarding requirements specifications and
CR IP T
possible solutions accumulated over time, uncertainty remained latent as either threat or opportunity, and was subsequently subjected to strategic action: “...we stop time and again and look together with the client: what did we do? What else do we need to do? Are we on the right track? Then we continue, step by step‖ (developer, Team A).
AN US
Most of the teams seemed to invite rather than disapprove of customer change requests, which were explicitly encouraged as long as they were brought forward in the time between two development iterations, or otherwise buffered through product backlogs, which
M
were maintained to permit work without interruptions during development iterations. Using short development iterations was viewed as beneficial as it allowed team members to collect
ED
feedback more frequently, and thus enabled them to accrue additional information to reduce uncertainty: “At some point we had like a change in the requirements, which was pretty
PT
disruptive and we had to recalculate our requirements, [and repeat] the Sprint [iteration].
CE
This shouldn't happen of course. [...] having the shorter iterations helps you with doing that“
AC
(developer, Team J).
4.2.2 Team based task analysis
Software developers often faced situations in which they were not sure about how to solve a technical problem due to, for example, ill-defined problems or a developer lacking experience with regard to the used technology. We found that teams faced many situations in which it was unclear whether a particular envisioned solution would be feasible. Teams
ACCEPTED MANUSCRIPT performed collective meetings to further investigate the task at hand, in order to acquire the required insight for a meaningful decision-making process about how to proceed. Oftentimes two or more team members were delegated to these task investigations, depending on their knowledge and experience. They jointly investigated for a fixed duration of time, ―[…] to create more knowledge, so that we can estimate [the task size] more comfortably. It’s
CR IP T
important that it is time-boxed. For example, that we take four hours, and then we stop. Because with these investigations you can burn days. But that doesn’t get you anywhere. You have to time-box them; that’s an important point.‖ (Scrum coach, Team F).
This pooling of resources in order to investigate possible solutions had the effect that
AN US
the teams would eventually come to know not only how to proceed, but also how much effort a certain task might require. Estimations of task sizes, which were almost always performed collectively by the entire teams, were mentioned as the single most important practice
M
regarding the reduction of task uncertainty. Some teams held special meetings dedicated to the estimation of batches of tasks, and usually pooled knowledge from several developers in
ED
an attempt to reach more accurate estimates. All of the teams performed estimation meetings not only at the start of each iteration, but they also spent much time on corrections of task
PT
size estimations whenever they acquired new information. This accrual of information in an
basis.
CE
iterative fashion enabled teams to apply changes to the development project on a continuous
AC
While the accuracy of estimations benefitted from the involvement of several team
members, the downside was that more time needed to be spent on estimations. Although teams tried to limit the duration of estimation meetings, developers were troubled when regularly exceeding these limits: “[the estimation meeting] should take one hour [but] everything is so unclear, it's gonna take two hours, two and a half hours, and that always annoys me‖ (developer, Team J).
ACCEPTED MANUSCRIPT Some teams sided with conservative estimates to buffer uncertainty, as it became clear that task sizes could turn out to differ starkly from original estimations. One developer explained: “most of the time we try to be a bit more generous in terms of how much time we estimate so that we are sure that we’re not going to need more time” (developer, Team C). Sometimes the actually required effort dropped by magnitudes when developers found
CR IP T
elegant solutions to problems that were initially expected to be much more complex. In these cases, conservative estimations yielded unexpected benefits in the form of saved resources. However, the opposite can occur as well when the complexity of a task is underestimated. In one incident, a team experienced a case where the initial task size estimation had to be
AN US
tremendously corrected upwards repeatedly as unexpected dependencies were discovered. Eventually the task size grew three times larger than its original estimate, requiring the attention of a sub-team of four developers instead of a single person. In this case, task
M
uncertainty developed into a real threat that imposed vast unexpected costs. To manage task uncertainty, teams learned to keep task sizes as small as possible in attempts to contain
ED
negative consequences. In addition, splitting up tasks to smaller ones increased the precision
4.2.3 Knowledge sharing
CE
PT
of estimations and reduced the necessity for revising them.
Structures for knowledge sharing were employed in all teams. They supported the
AC
management of resource uncertainty and made workflows more robust. Teams with broad ranges of tasks and high degrees of specialization felt that their diversely distributed expertise hampered collaboration practices such as task analysis and effort estimation. To counteract this, they strove to foster the systematic sharing of knowledge regarding different aspects such as employed technologies or decisions about solutions to problems. On the one hand, this included knowledge about task specifications: “we discussed [the tasks] and tried to
ACCEPTED MANUSCRIPT formulate them as precisely as possible so that everybody had the same understanding” (developer, Team F). On the other hand, most teams reported to strive for the maintenance of shared capabilities to enable the continuation of work based on developers‘ independence: “what if, when I am sick, for example or I leave the company or I change roles. [We wanted to]
CR IP T
separate the task from the person in order to create a pool with all the knowledge” (developer, Team H).
A number of teams conducted regular knowledge exchange meetings, for instance in the form of mini seminars on current technology use. Pair programming techniques, i.e. the
AN US
employment of two developers per computer who work in collaboration on a single task in order to learn from each other and increase code quality, was used extensively in one team. After the completion of a task, pairs were regularly broken up and recomposed with different
M
team members so that task specific knowledge would spread through the entire team.
ED
4.3 SOLUTION INSPECTION 4.3.1 Prototyping
PT
Prototyping was much valued in all teams, because it helped to focus on important product
CE
features and reassures developers. Addressing the threat of inefficient resource deployment toward features deviating from the customers‘ vision, the use of early prototyping supported
AC
the exploration of options while focusing discussions with customers on functionality. At the same time, prototyping was described to us as an important instrument for the exploration of opportunities, because it stimulates meaningful customer feedback. One team manager explained: “So from this meeting we were able to somehow come up with a prototype, just because we wanted to test the feasibility of some solutions [...] we wanted to actually test and see if some ideas might be realized or not. So this was the intent of the prototype, then we
ACCEPTED MANUSCRIPT used it also to convince the sponsor. [...]people start to imagine how they can do business with that and then they'll give you much more input, and much more concrete" (Product Owner, Team C). Prototyping, thus, is an important information device for team members as well as stakeholders other than developers. However, there are also drawbacks of early prototyping, which are linked to the
CR IP T
communication of functionality. A prototype is by definition a preliminary version that is inferior to the envisioned product feature. While prototypes provide customers with a better understanding for the development in progress, they trigger early feedback and facilitate decision-making. This worked well when the development team and its customers had a
AN US
shared vision of the final product. When the developers envisioned a technical solution that could not be fully expressed and represented in a prototype, the benefits of early feedback broke down. In one situation, team A experienced a situation in which developers saw future
M
product flexibility threatened by implementing features they had discussed with their customer. They argued for changes in the product architecture, which were costly, but would
ED
allow – in their view – improved opportunities for future development. They were not able to convince the customer, who did not see the benefit and did not approve of the extra cost. The
PT
developers then decided to push ahead their solution at their own cost, risking that the extra
CE
hours would not be paid eventually. After implementing a prototype of the suggested solution, the team was eventually able to convince the customer of the benefit, which had
AC
previously been impossible. A developer noted that one needs to have more time to experiment on one‘s own, an activity which was not provided for during the short development iterations. Eventually, the team was successful in convincing the customer to cover their extra cost, which they had been prepared to accept at their own risk. Prototyping, in this example, favored short-term customer orientation that was detrimental to product quality in the long run.
ACCEPTED MANUSCRIPT 4.3.2 Creating alternatives The deliberate pursuit of solutions that are later abandoned can lead to significant advantage. Pursuing multiple solutions simultaneously served software developers to increase flexibility and offered possibilities to defer decisions regarding which option to exclude and which one to keep developing to later points in time: “we had in fact two strategies or two options in
CR IP T
mind from a technical point of view, which we were able to go and the one we decided for was so far the right solution. […] It's ... you're more flexible, you can be more innovative” (developer, Team K). In this case, an opportunity could be realized when the option that turned out as inferior was abandoned at the cost of having started development of both in
AN US
order to keep options open. However, this strategy, as well as the reliance on task backlogs to avoid developer idleness required redundancies of skills within the team to some extent. It also required the ability to transfer available tasks to the next free developer, which must be
M
preceded by adequate knowledge of production and product details despite high levels of complexity.
ED
Developers, therefore, need high levels of freedom to explore as well as adequate tools allowing them to convince customers of deviations from original plans. This can be
PT
beneficial when different technical solutions are more feasible to realize or more readily
CE
accessible. Developers from Team A explained their frustration after failing to agree with a customer representative to a deviation from a technical solution. Several members of the
AC
team had grown convinced that an alternative solution would be superior, but they failed to convince their customer until they produced a prototype at their own cost and concluded “sometimes it’s difficult to convince the customer if you can’t show them something” (developer, Team A). The example highlights the importance of trust in ones abilities and the development of intuition in order to spot opportunities. Risk taking and failure tolerance, thus, play an important role for the exploration that permits opportunities. Teams not only
ACCEPTED MANUSCRIPT need to tolerate uncertainty and its potential drawbacks, but also operate in environments that provide the psychological safety and team support necessary for effective uncertainty management. This becomes clear from the statement of a developer describing his trust in the team‘s ability to solve any type of problem without necessarily knowing how in the beginning: “I've never been involved in something that failed so drastically that we didn't
CR IP T
find a solution to it […] there has never been a problem that has actually amounted to become something. It's quite funny, because when I think about it there's always, we always somehow find [a solution], you know, whether it's a workaround, or it may just be fixing the symptom, but not the real root cause. We've still somehow always managed” (developer,
AN US
team I).
4.4 ROLE-BASED COORDINATION
M
4.4.1 Creating functional roles
In processes that draw on consensus-based decision-making, agile software development
ED
teams create their tasks as well as their roles in a self-organizing manner. Although advised by agile methods to abandon functional roles, the teams we studied created roles upon
PT
realizing the need for them. For example, when recurring customer calls regularly interrupted
CE
the development work, a role-based solution implemented by a team included the handling of all calls through a new customer service role, the occupants of which rotated on a bi-weekly
AC
basis. Other roles were temporally limited, such as when an emergency task required the formation of a sub-team with an explicit leadership role, which was retired upon returning to non-emergency development work. Yet other roles were created not in reaction to events, but in anticipation of problems or aspiration of uninterrupted development work, e.g., through a rotating but permanent role for specific aspects of project documentation.
ACCEPTED MANUSCRIPT Some teams used practices to concentrate tasks of a similar uncertain nature to dedicated functional roles within the project. For example, Team G faced regular service requests from a large number of customers, which could mean anything between 20 minutes and several days of work depending on the reported issue. After observing the insufficient coordination with which the team was dealing with incoming customer requests, it was
CR IP T
decided that one person would be responsible for all requests on a bi-weekly rotation scheme. As a consequence, participants reported that everybody else on the team could follow their work plan without interruptions, thus, not facing the uncertainty of having emergencies require the complete reorganization of their daily tasks.
AN US
As much as the freedom to design and re-design roles can increase efficiency, it also bears the potential for conflict. For example, development teams in larger companies were challenged to adopt team role structures inherent in agile development methods. The
M
guidelines of agile methods instruct teams to abandon job titles in an attempt to facilitate shared responsibility and flat hierarchies that support collaboration. However, bureaucratic
ED
structures in large companies preserved pre-existing job titles (such as ‗solution architect‘ or ‗requirements engineer‘) based on unique specializations of team members. Role creation
PT
became an exercise in combining both structures. As a result, many of the created roles were
CE
either tailored to specific types of team members or designed to exclude team members from taking a role in order to preserve scarce team capacities for critical development work.
AC
In the face of uncertainties that required decision-making, teams referred to informal
leadership structures based on the roles they had created. The occupation of leadership roles depended strongly on a team member‘s tenure, as well as their expertise related to the project. In shared decision-making processes, the opinions of team members with specific knowledge, for example regarding specific market environments, customers, or technologies, received more weight than the opinions of less experienced team members. Senior team members
ACCEPTED MANUSCRIPT were assigned leadership roles sometimes without seeking or even accepting them. One developer complained: “I have been with the team for a long time now. For me now the pressure increased, because I should take the role, even though I don’t know everything. I am not the same person [as the senior colleague who had just left]. So for me the pressure has increased, because many questions come to me, and I am expected to make more decisions,
CR IP T
you know” (developer, Team B).
While the establishment of roles aims at enabling agility through decoupling work tasks from individuals, change can be undermined when the system becomes inert and roles do not lend themselves to temporality. This means that some roles, once created, are sticky,
AN US
i. e. difficult to retire and decouple from individuals who have acquired specialized knowledge through filling them. Our data show that individuals regularly had difficulties resigning from a role for various reasons such as specialization, trust, or conscientiousness.
M
For example, one developer from team G who was no longer occupying the rotating customer service role explained that customers still approached her even months later in the role she no
ED
longer occupied, because she used to be most familiar with their issues and customers refused to approach the current role occupant: “[they] often come to me because they know me, but
PT
they could as well write to the mailbox. […] I was just the one who happened to know them
CE
best and who also knew the problem best, so I still end up doing it even it’s not part of my job any longer” (developer, Team G).
AC
High degrees of specialization and expert knowledge did impede team members in all
teams from switching roles under certain circumstances, for example when the familiarization with a new technology or business context created barriers. In several cases, team members reported that they continued performing the tasks of a role they formerly occupied for reasons of team and external stakeholder convenience. Personal bonds also
ACCEPTED MANUSCRIPT made it difficult to discard a role, especially when trust was formed between external stakeholders, such as suppliers and customers and the contact persons within the team. Another reason for the stickiness of roles was that team members felt responsible for their work and tended to maintain caring for its proper execution out of conscientiousness. For example, team members who had been formerly responsible for the facilitation of a
officially handed over responsibility to their successors.
CR IP T
project planning meeting kept attending subsequent planning meetings after they had
Given the implicit and sometimes uninvited assignment of roles, as well as the stickiness of roles, developers faced challenges regarding role related coordination activities.
AN US
While role structures were created to support uncertainty management, these challenges threatened to inhibit flexibility and thus impede uncertainty management.
M
4.4.2 Stakeholder integration
Project teams tried to manage requirements uncertainty especially with regard to changes or
ED
ambiguities threatening to cause more work through integrating diverse stakeholders closely into the software development process. All teams engaged in frequent communication with
PT
stakeholders, which was perceived to significantly improve decision-making. To some extent,
CE
this shifted responsibility, e.g. for product design decisions, away from the development team and toward clients. For instance, a developer noted: “in the old [non-agile development] style
AC
waterfall system, you get a screenshot, you implement it, you don't understand it directly, you just do what's on the screenshot, and afterwards the customer says 'Well, that's not what I like'” (developer, Team K). In contrast to this practice, some of the teams integrated clients to a degree where work would not continue as long as no decision was made to resolve requirements uncertainties, thus eliminating the threat of investing effort in the development of unapproved details: “we have a lot of external dependencies. There are many [tasks] we
ACCEPTED MANUSCRIPT cannot continue because we just need to clarify. So I have to ask: is that correct that way? Or how is the status? And inquire a bit and […] communication, a lot of communication, that’s what I mean” (developer, Team B). Most teams desired direct contact between developers and external stakeholders, especially customers. At the same time, this created tensions that were described as
CR IP T
unwelcome dependencies. Acknowledging the necessity for frequent contact with stakeholders, these dependencies were seen as necessary on the one hand, but detrimental to efficiency on the other, which tended to trouble teams. Attempts to resolve them resulted in a negotiation between adopting external parties‘ schedules and working styles, and imposing
AN US
the team‘s schedules and working styles on stakeholders. One team, for example, persuaded several of their clients to adopt the planning board that plays a central role in their work in order to synchronize and discuss future tasks. Others shared access to online collaboration
M
tools with their clients. In our data, there was a lot of complaint that suppliers that were not ‗agile‘ did not understand the timing of events and the role of iteration cycles, which
ED
prescribed frequent deadlines. The importance of adhering to them could not always be communicated clearly and was ignored by suppliers, threatening to disrupt project schedules
PT
and the pace of development work. As a remedy, teams strove to establish very close
AC
CE
integration of project stakeholders.
4.4.3 Task switching
Switching from a current task to another, or taking over a task from a colleague let teams uphold development work when interruptions occurred. Technical difficulties and workflow disruptions were frequently experienced when input was not available from external project stakeholders, e.g., when deliveries of work from contractors or suppliers were late or were not of sufficient quality so that they needed clarification or rework. One developer noted the
ACCEPTED MANUSCRIPT importance of a task backlog that holds additional items to be completed during a development iteration to which one can return in order to avoid idleness when waiting: ―I mean that almost always occurs in any project, that you need to wait for something. I mean, otherwise everything is planned, I mean, that doesn't happen that everything is planned out in a way that you don't need to wait […] it happens really all the time in the best projects. In the
CR IP T
worst projects, it's, it just happens a lot more and basically I think the trick for fixing that is just to have ... be open minded enough to work on something else and not get yourself ... be stopped in the process, I mean, ... But of course you need to have a backlog ... that's actionable to some degree and makes sense― (developer, Team I). Another developer
AN US
described how, if switching to another task while awaiting specific information is not possible, inefficiencies and re-work may result: ―we couldn't get information about the error handling, if there was a false input, how to react. So I had the uncertainty that I have to...
M
should I throw an exception and stop everything or should I return null values, I don't know, and I couldn't get the information from the customer. So I had to choose one, one way, and of
ED
course it was the wrong one (laughs) and I had to change it later‖ (developer, Team K). The importance of managing task uncertainty and task interdependencies surfaced
PT
particularly in situations, when task switching was difficult. One team reported experiencing
CE
the threat that developers became idle because of the team‘s dependency on database specialists within their company. The specialists repeatedly failed to deliver what the team
AC
ordered. In particular, lack of requested infrastructure threatened to delay the project several times. The problem was linked to the fact that there was not one individual in the database team responsible, but each time the next available employee processed incoming requests. The team leader negotiated a proposal with the database department according to which one database administrator would be integrated in his project team. This had the effect of creating of a novel business model; henceforth database specialists could be hired individually by
ACCEPTED MANUSCRIPT development teams to process their entire requests. This supported more effective communication and the elimination of misunderstood requests, as one specialist processed all requests. It also allowed turning a threat into the opportunity of improving the production
5. DISCUSSION
CR IP T
process by a newly created customized service.
In this study, we emphasize that two important and desirable outcomes of uncertainty management are mitigating threats and fostering opportunities. Detailing different approaches available toward these ends, we investigate software development team practices. In our
AN US
study, we deliberately focus on agile software development teams, which are increasingly employed in settings characterized by environmental turbulence. The underlying rationale is the organizational attempt to provide the necessary flexibility to react quickly and adequately
M
to diverse sources of change. Agile teams employ practices that are starkly inspired or directly derived from different software development methods. Yet, not all agile software
ED
development methods support addressing uncertainties equally well, and many only do implicitly so [28]. Teams must approach uncertainties using practices that are simultaneously
PT
informed by several, complementary agile software development methods. This is
CE
problematic especially with regard to supporting the management of opportunities, which is not explicitly addressed. For example, while agile methods provide structures that support the
AC
ability to respond to potential threats by fostering capabilities for collaborating with customers,
iterative
work,
team
learning,
and
software
development
process
improvement[77], agile methods do not equip teams with regard to cultivating and reaping beneficial outcomes [28]. In line with Fitzgerald et al. [78], we find that agile methods are individually incomplete in their support of product innovation, which depends on the systematic pursuit of opportunities. Practitioners have to rely on the combination of practices
ACCEPTED MANUSCRIPT from different methods such as Scrum, Kanban and XP, which invites confusion. Hence, it would be advisable for teams to draw upon the very possibilities embedded in iteration-based process inspection and adaptation, which is core to agile methods, to integrate further techniques in a self-directed way to respond to team and project needs. While it is arguably difficult to establish systematic practices to foster innovation, agile teams command qualities
CR IP T
that may be well suited to inform strategic project decisions, which we will detail below. Presenting examples for approaching uncertainties that assume both the possibilities for positive and negative implications, we document the benefits and challenges of practices employed by software development teams. Our results include ten practices (see Table 2) that
AN US
span four overarching principles; 1) uncertainty anticipation, which relates to the attempt to prepare for different possible scenarios regarding the future development of uncertainties and remain vigilant to profit from opportunities; 2) information accrual, which is strongly
M
influenced by the incremental working style of agile methodology, and speaks directly to uncertainty management, as uncertainty can only gradually be developed into opportunity or
ED
become unmasked as threat; 3) the frequent evaluation and inspection of solutions, which in our data increased the efficiency of discussions on multiple possible solutions and provided a
PT
basis for discussions among developers and customers, and 4) role-based coordination, which
CE
integrates team members and external project stakeholders on the basis of practices for establishing temporary, dynamic, and de-individualized roles to accomplish tasks. Many of
AC
the practices used by teams to manage uncertainty are directly influenced by suggestions that stem from different agile development methods, most prominently Scrum (on the project level) and XP (regarding programming techniques). We have included an overview of these influences in Table 2. Our findings show how some of these practices need to be established by development teams in order to complement agile development methods.
ACCEPTED MANUSCRIPT 5.1 PROACTIVELY MANAGING DIFFERENT TYPES OF UNCERTAINTY The four principles that our study identifies and details govern practices that function conjointly to provide teams with guidance in terms of effectively managing different types of uncertainty. In particular, the iterative development approach that agile methods entail is especially suited to address requirements uncertainty [48, 59]. Similarly, the step-wise
CR IP T
information accrual of development iterations is supportive for determining mismatches between required and available resources, hence, to mitigate resource uncertainty. For example, estimations of resource availability are an important input for the planning of development increments in Scrum. Further, solution inspection that entails the option to delay
AN US
decisions carries potential for the management of task uncertainty, which pertains to aspects of technologies employed. The underlying practices for estimating required effort are derived from a technique called Planning Poker, as well as from the practices of prototyping and
M
customer integration that are suggested by different agile methods [79, 80]. Striving to accomplish small tasks in an iterative fashion and integrating customer feedback on
ED
prototypes supported the management of requirement uncertainty, while distributing tasks across several roles often resulted in opportunities to create supplementary product features
PT
with better insight into technologies and market environments.
CE
Opportunity recognition is, unfortunately, left to the initiative of individual developers. While this is common in innovation settings [81], we argue that agile
AC
development teams command practices which could permit them to explore opportunities much more systematically by seizing their team-based approaches similarly to the way in which they manage threats. One important step in this direction could be the establishment of a backlog for opportunities in which options are recorded based on input from all team members in a regular fashion based on the discussion of possible strategies. Their potential market value could be estimated making use of cross-functionality, i.e. drawing upon
ACCEPTED MANUSCRIPT technological and business expertise of the teams. In this process, all developers should participate in order to reap their cumulated expertise regarding the product and systematically explore potential opportunities. While agile development teams have excellent decisionmaking capacity, Drury and colleagues argue that this capacity is, however, usually not employed to arrive at better strategic decisions, but rather to mitigate requirement uncertainty
CR IP T
[54]. Employing similar techniques for the search of novelty might provide companies strongly enhanced innovative capacity by addressing opportunities.
Toward this goal, considering different types of uncertainty and their potential positive versus negative development is vital. We would like to stress that differences in the
AN US
types of uncertainty can exist with regard to many aspects. Teams are likely to encounter further nuances in the different types we have investigated. For example, requirement uncertainty can stem from volatility of product features, or from a lack of information about
M
the truly required feature a customer needs, both of which may demand different approaches and different combinations of practices for their management, such as prototyping or the
ED
delay of decisions through the creation of alternative solutions. Teams are required to examine uncertainties closely with regard to the project context and situation they are in
PT
before deciding on adequate reactions.
CE
Ignoring the difference between uncertainties leading to threat versus uncertainties leading to opportunity decreases innovative potential and gives rise to a fixation on threat.
AC
While we do not intend to say that threats should be accepted or ignored, we extend a warning regarding the premature elimination of related uncertainties. Threat mitigation, for example, in the form of avoiding costly investments into later changing product requirements, is very important. Yet, there are situations in which design changes even at late stages in the development cycle can carry benefits [82]. Potential benefits of accepting uncertainty or even increasing uncertainty may carry important aspects for teams [7, 83].
ACCEPTED MANUSCRIPT According to the decision-making literature, team members tend to value uncertainty more than their superiors who often fail to see the benefits of remaining open to alternative solutions [54]. In line with these findings, we warn that decreasing flexibility in favor of a focus on control (minimizing uncertainty) implies the cost of forgone opportunities. Our analysis suggests that skepticism toward uncertainty dominates even in agile software
CR IP T
development settings, where we would expect to see teams rely on the exploitation of opportunities to innovate. We find that some developers are alert to opportunities, but most are more alert to threats – above all the threat of failing to meet rapidly changing market demands.
AN US
Given that most developers we interviewed associated uncertainty with threats, while team and project leaders were generally more open to associate opportunities with uncertainty, our concern is that much potential for opportunity realization remains unrealized.
M
This finding is in line with observations by Austin and colleagues [20], which illustrate the skew toward cost-driven, as opposed to opportunity-seeking, behavior of product developers.
ED
Whereas the types of behavior we have witnessed may be influenced by individual preferences regarding uncertainty avoidance versus uncertainty tolerance, we see a need for
PT
teams to create structures that incentivize exploratory activities while shielding opportunity
CE
explorers from detrimental outcomes. Leadership researchers point to the effectiveness of rewards for opportunity seeking behavior [84], although this may be challenging in the face
AC
of hierarchical structures (or rather, their absence) observed in agile teams.
5.2 THREATS AND OPPORTUNITIES IN SELF-MANAGING TEAMS
Agile software development teams rely on high levels of autonomy [85]. This has implications for the way in which they approach uncertainty. When left without clear guiding structures, their choice regarding how to deal with uncertainty becomes an uncertainty itself.
ACCEPTED MANUSCRIPT Extending earlier accounts in which teams establish structures in the form of role-based coordination [86], our findings document a dynamic system of de-individualized roles in software development. Agile software developers create role-based team structures to support their development work. Dynamic functional roles (i. e., changing informal within-team job descriptions) were used by scrutinizing the creation, modification and maintenance of team
CR IP T
member roles in support of adaptation to varying and unstable project goals. There are several ways in which dynamic role allocation influences how teams approach uncertainty. In contrast to work environments with standardized output, the goals of agile software development projects are neither known at the outset, nor stable; they emerge slowly and are
AN US
subject to frequent variation. As a result, development teams continuously aim to forge their supportive organizational structures by tailoring functional roles to match the development project‘s dynamic requirements. The dynamism of organizational structures results directly
M
from the creation and retirement of roles for specific work tasks, which are fundamentally different from each other, for example, in terms of managerial stint or temporal nature.
ED
When teams are able to employ dynamic roles, they can increase team efficiency by intelligently allocating individual capacities. Our results contain several examples for
PT
situations in which teams reap the benefits of dynamic role-based team structures, however,
CE
we also note some of the drawbacks. Specifically, the stickiness of roles (i.e., the difficulty that occurs when switching or retiring a role) holds potentially detrimental implications for
AC
teams in situations where roles are intended to be dynamic, but this is undermined by established team structures. When roles are intended to be dynamic and flexible by design, but do not conform to this characteristic in practice, teams will be hindered in their productivity and use their resources inefficiently. Recognizing specific characteristics of such inefficiencies may equip teams with the potential to act upon them. For example, it seems that role-based coordination issues can go unnoticed because individuals are not aware of
ACCEPTED MANUSCRIPT their systematic occurrence, while their mere discussion within teams would initiate possible solution strategies.
5.3 LIMITATIONS OF THE STUDY
CR IP T
While seizing the opportunities that qualitative methods offer, our research approach carries limitations that are connected to sample size and difficulties regarding the generalizability of findings. In particular, we draw on observations and interviews with a limited number of agile software development teams in the Swiss software industry. Differences in the lengths
AN US
of interviews that were conducted result in part from our aim to include more team members in larger teams, and allocate more interview time to participants in smaller teams so as to collect all relevant perspectives and validate experiences across team participants where
M
possible. An important limitation refers to the fact that agile software development teams operate under special conditions; for example with regard to decision latitude and team
ED
autonomy. Although agile practices are gaining increasing popularity far beyond softwaredeveloping teams, the conditions in which these teams operate carry implications for the
PT
generalizability of our findings to different contexts. We strove to mitigate limitations by
CE
methodologically triangulating data from several diverse companies that operate globally. This increases our confidence that our sample is representative for research and development
AC
contexts spanning the wider software industry. To our support, Smith [80] notes that software development projects in general share important characteristics with agile projects, such as low prototyping costs and opportunities to modularize products. In addition, the management of uncertainty plays a vital role in projects across a variety of industries and organizational settings [12, 87, 88], and the implications of our results may be applicable beyond agile software development projects.
ACCEPTED MANUSCRIPT
5.4 IMPLICATIONS FOR INDUSTRY The importance of risk and uncertainty in software development projects is undeniable and reflected by the large number of risk management frameworks that have been proposed. Yet, critics note that no framework has become a generally accepted standard [89], nor been
CR IP T
integrated well into development projects [4]. For example, the most widely adopted methods for agile software development, Scrum and XP, do not explicitly mention the management of risk or uncertainty [28]. The result is a lack of formal guidance for practitioners, which needs to be compensated by experience based practices [90].
AN US
In this study, we investigate principles and practices that may mitigate the guidance gap, first, by broadening the notion of risk management and shifting the focus toward uncertainty, and second, by introducing a language that permits the connection of practices
M
from different agile methods using the universally applicable concept of uncertainty. We highlight several distinct types of uncertainty. Based on our empirical results, we suggest that
ED
practitioners should not only acknowledge these differences but also consider diverse options to approach them. Systematic and continuous attention to uncertainties should best be
PT
structured along the different categories of uncertainty in order to support teams in
CE
determining adequate responses. This does not mean the early elimination of uncertainty, as we have repeatedly stressed. Opportunity management depends on being open to unexpected
AC
events [20], therefore a project‘s diverse sources of uncertainty should be iteratively and systematically analyzed and evaluated. Developing vigilance in spotting opportunities supports this. To derive innovation
regarding technical solutions as well as their commercialization, companies should seize the creative capital of each individual software development team member. Incentivizing and rewarding vigilance and opportunity-seeking practices could increase awareness among
ACCEPTED MANUSCRIPT developers and produce and sustain team performance. Our results highlight the necessary cross-disciplinary knowledge to foster individual team members to pursue opportunities. Companies should aim to cultivate vigilance and include it in their formulation of ‗agile values‘ such as autonomy. On a similar note, companies should aim to seize the collective capacity of agile teams not only with regard to solving technical problems, but also with
CR IP T
regard to informing strategic project decisions aimed at opportunity management. While Surowiecki [91] notes that under certain circumstances teams will make better decisions than individuals, their potential for strategically relevant project decisions in agile teams seems to remain largely untapped.
AN US
As the concept of uncertainty carries a negative connotation among practitioners, teams are at risk to dismiss hidden opportunities by attempts to eliminating uncertainties instead of coping with them. At the same time, existing approaches to uncertainty or risk
M
management may fail to uncover opportunities for similar reasons; many risk management frameworks are designed with the mitigation of negative events in mind. In order to profit
ED
from unexpected events, a change in perceptions that extends uncertainty to include opportunity is strongly advised. We propose that communication practices in agile
PT
development be extended to include the presented notion of uncertainty management, which
CE
can be structured along the types of uncertainty we identified. Team members should aim to integrate the sharing of incrementally collected information in existing communication
AC
structures to uncover uncertainty‘s positive or negative developments. A structured approach, as opposed to practices left to be carried out only by mindful team members, is more likely to improve uncertainty management practices and help practitioners in identifying threats and opportunities earlier. Learning and information sharing, which are crucial for this, are already fostered by agile development methods. These need to be extended by a shift to exploratory activities beyond technological solutions, and complemented by the systematic search for
ACCEPTED MANUSCRIPT opportunities. Whereas the literature documents failures to systematically approach risk and uncertainty management [92], our analysis stresses the importance of collecting information systematically and in combination with further practices that enable teams to reap benefits while preventing potentially detrimental developments.
CR IP T
5.5 IMPLICATIONS FOR RESEARCH
Different implications for scholars of uncertainty can be derived. Researchers should not only follow calls to look beyond risk and consider uncertainty management as important source of insight [33], as well as acknowledge the existence of different types of uncertainty to increase
AN US
investigations of beneficial uncertainties, which have often been ignored in the risk management literature. Considering that uncertainty affects projects in different ways [93], it is advisable that future work addresses the conditions under which different types of
M
uncertainty become manageable for development teams. For example, it is not clearly understood if the possibility for opportunities can be categorically excluded for some cases,
ED
which would allow different conditions for the mitigation of threats. While the focus of our study was on agile software development teams, practices for handling threats and
PT
opportunities may be affected by different challenges in other settings, such as traditional
CE
development projects or different types of product development. While our aim was to point to the consideration of distinct uncertainty types and their potentially different consequences,
AC
continuing this line of research in further settings will certainly yield important insight for the product development literature. Another important aspect to extend our understanding is the consideration of
individual differences such as risk attitudes that influence the behavior of actors. These aspects should be addressed in future studies. Grote [30, p. 48] suggests that the potential for uncertainty management in organizations is related to the ―belief systems held by
ACCEPTED MANUSCRIPT occupational groups and the belief systems developed in the companies themselves, that is, company culture.‖ While the complexity of the uncertainty concept has the potential to deter researchers and practitioners, it is a powerful lever of beneficial impacts on development
6. CONCLUSION
CR IP T
projects and deserves increased attention.
Like the ancient Roman god Janus, uncertainty has two faces. One is beneficial whereas the other is malign. In this paper, we empirically explore how agile software development teams deal with uncertainty, i. e. in situations in which they have incomplete information, in order
AN US
to reap opportunities and avoid threats resulting from it. We present work that explicitly continues to move the study of risk beyond the focus on threats by including potential benefits from uncertainty.
M
Our findings detail practices to approach different types of uncertainty (regarding resources, task, and requirements), which allow teams to mitigate threats while remaining
ED
alert to unanticipated opportunities. Many of these practices are informed or directly derived from agile software development methods, yet by delineating their effects through the lens of
PT
uncertainty our description takes a conceptual approach that extends beyond the scope of
CE
individual established methods such as Scrum and XP. Importantly, while most of the software development literature has viewed uncertainty in a negative light [94], we
AC
emphasize that uncertainties may develop into beneficial opportunities. For example, development teams complemented agile methods by practices for role-based coordination and opportunity management. While agile practices are helpful in supporting software developers to address uncertainty, their emphasis on opportunity and, ultimately, innovation is not as pronounced as their capabilities for the mitigation of threats. This provides a
ACCEPTED MANUSCRIPT promising avenue for the improvement of agile methods, which is even actively encouraged by their very values. Many of the practices we detail were performed simultaneously or in a periodically recurring fashion following four overarching principles for addressing uncertainty. Incorporating the possibility for unexpected events led development teams to reckon with
CR IP T
changes especially with regard to requirements and availabilities of resources. Through frequent probing and re-planning, teams were able to elaborate most adequate tasks and mitigate many negative consequences, for example, with regard to avoiding ineffective work. At the same time, some developers displayed the vigilance to remain alert to potential
AN US
opportunities stemming from the same sources of change, which often resulted in benefits for their teams.
We hope that these findings will guide teams in software development projects and in
M
new product development projects in general, which face difficulty in the discernment of
ED
uncertainty as threat and opportunity.
ACKNOWLEDGEMENTS
PT
The authors declare no conflict of interest. We wish to thank the participants of our study for
CE
their time and effort, and are extremely grateful for their support and valuable comments. An early version of this paper was presented as a short paper at the 16th International Conference
AC
on Agile Software Development (XP2015), which reports on preliminary work at a previous stage in the research process. We are grateful to the conference participants and in particular to Torgeir Dingsoyr, Alan Moran and Nancy Van Schooenderwoert for their valuable feedback and suggestions for revisions. We wish to express our sincere gratitude to our anonymous reviewers for their extremely helpful, supportive and constructive suggestions.
ACCEPTED MANUSCRIPT REFERENCES
[7] [8] [9] [10] [11] [12] [13] [14]
AC
[15] [16]
CR IP T
[6]
AN US
[5]
M
[4]
ED
[3]
PT
[2]
F. H. Knight, Risk, Uncertainty and Profit. Chicago: University of Chicago Press, 1921. S. Nidumolu, ―A comparison of the structural contingency and risk-based perspectives on coordination in software-development projects,‖ Journal of Management Information Systems, vol. 13, no. 2, pp. 77–113, 1996. K. S. Na, X. Li, J. T. Simpson, and K. Y. Kim, ―Uncertainty profile and software project performance: A cross-national comparison,‖ Journal of Systems and Software, 2004. S. Islam, H. Mouratidis, and E. R. Weippl, ―An empirical study on the implementation and evaluation of a goal-driven software development risk management model,‖ Information and Software Technology, vol. 56, no. 2, pp. 117– 133, Feb. 2014. H. Ibrahim, B. H. Far, A. Eberlein, and Y. Daradkeh, ―Uncertainty management in software engineering: Past, present, and future,‖ presented at the 2009 Canadian Conference on Electrical and Computer Engineering (CCECE), 2009, pp. 7–12. I. Stamelos and L. Angelis, ―Managing uncertainty in project portfolio cost estimation,‖ Information and Software Technology, vol. 43, no. 13, pp. 759–768, 2001. G. Grote, ―Promoting safety by increasing uncertainty - Implications for risk management,‖ Safety science, vol. 71, pp. 71–79, Jan. 2015. H. Jalonen, ―The uncertainty of innovation: a systematic review of the literature,‖ jmr, vol. 4, no. 1, pp. 1–47, Aug. 2011. E. T. Penrose, The Theory of the Growth of the Firm. Oxford: Blackwell, 1959. S. Jeschke, I. Isenhardt, F. Hees, and S. Trantow, Enabling Innovation. Berlin, Heidelberg: Springer Science & Business Media, 2011. M. Paixao and J. Souza, ―A robust optimization approach to the next release problem in the presence of uncertainties,‖ Journal of Systems and Software, vol. 103, no. C, pp. 281–295, May 2015. O. Perminova, M. Gustafsson, and K. Wikström, ―Defining uncertainty in projects – a new perspective,‖ International Journal of Project Management, vol. 26, pp. 73– 79, 2008. B. J. Kolltveit, J. T. Karlsen, and K. Gronhaug, ―Exploiting opportunities in uncertainty during the early project phase,‖ Journal of Management in Engineering, vol. 20, no. 4, pp. 134–140, Oct. 2004. J. Turner, ―A Comparison of the Process of Knowledge Elicitation with that of Information Requirements Determination,‖ 1990. D. Hillson, Managing Risk in Projects. Gower Publishing, Ltd., 2009. R. Atkinson, ―Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria,‖ International Journal of Project Management, vol. 17, no. 6, pp. 337–342, Dec. 1999. P. L. Bannerman, ―Risk and risk management in software projects: A reassessment,‖ Journal of Systems and Software, 2008. C. Barclay, ―Towards an integrated measurement of IS project performance: The project performance scorecard,‖ Inf Syst Front, vol. 10, no. 3, pp. 331–345, May 2008. A. MacCormack, R. Verganti, and M. Iansiti, ―Developing Products on ‗Internet Time‘: The Anatomy of a Flexible Development Process,‖ Management Science, vol. 47, no. 1, pp. 133–150, Jan. 2001.
CE
[1]
[17] [18] [19]
ACCEPTED MANUSCRIPT
[26] [27] [28] [29] [30] [31] [32]
AC
[33]
CR IP T
[25]
AN US
[24]
M
[23]
ED
[22]
PT
[21]
R. D. Austin, L. Devin, and E. E. Sullivan, ―Accidental Innovation: Supporting Valuable Unpredictability in the Creative Process,‖ Organization Science, vol. 23, no. 5, pp. 1505–1522, 2012. S. V. Shrivastava and U. Rathod, ―Categorization of risk factors for distributed agile projects,‖ Information and Software Technology, vol. 58, no. C, pp. 373–387, Feb. 2015. H. T. Barney, N. B. Moe, T. Dybå, A. Aurum, and M. Winata, ―Balancing Individual and Collaborative Work in Agile Teams,‖ presented at the Proceedings of the 10th Agile Processes in Software Engineering and Extreme Programming Conference (XP2009), Sardinia, Italy., 2009, pp. 1–10. N. B. Moe, A. Aurum, and T. Dybå, ―Challenges of shared decision-making: A multiple case study of agile software development,‖ Information and Software Technology, vol. 54, no. 8, pp. 853–865, Aug. 2012. P. Gregory, L. Barroca, K. Taylor, D. Salah, and H. Sharp, ―Agile challenges in practice: a thematic analysis,‖ presented at the 16th International Conference on Agile Software Development (XP2015), Helsinki, 2015, pp. 1–13. G. van Valkenhoef, T. Tervonen, B. de Brock, and D. Postmus, ―Quantitative release planning in extreme programming,‖ Information and Software Technology, vol. 53, no. 11, pp. 1227–1235, Nov. 2011. C. Andriopoulos and M. W. Lewis, ―Exploitation-Exploration Tensions and Organizational Ambidexterity: Managing Paradoxes of Innovation,‖ Organization Science, 2009. R. M. Fontana, V. Meyer Jr, S. Reinehr, and A. Malucelli, ―Progressive Outcomes: A framework for maturing in agile software development,‖ Journal of Systems and Software, vol. 102, no. C, pp. 88–108, Apr. 2015. A. Moran, Agile Risk Management. Cham: Springer Science & Business Media, 2014. L. Argote, ―Input Uncertainty and Organizational Coordination in Hospital Emergency Units,‖ Administrative Science Quarterly, vol. 27, no. 3, pp. 420–434, 1982. G. Grote, Management of Uncertainty - Theory and Application in the Design of Systems. Springer, 2009. R. Lipshitz and O. Strauss, ―Coping with Uncertainty: A Naturalistic DecisionMaking Analysis,‖ Organizational Behavior and Human Decision Processes, 1997. S. Madsen and J. Pries-Heje, ―Conceptualizing Perceived Uncertainty in Project Work. In J. Pries-Heje (Ed.), Project Management Multiplicity: CurrentTrends,‖ no. 7, Frederiksberg: Samfundslitteratur, 2012, pp. 127–148. S. Ward and C. Chapman, ―Transforming project risk management into project uncertainty management,‖ International Journal of Project Management, 2003. T. Aven and O. Renn, ―On risk defined as an event where the outcome is uncertain,‖ Journal of Risk Research, vol. 12, no. 1, pp. 1–11, Jan. 2009. E. Paté-Cornell, ―On ―Black Swans‖ and ―Perfect Storms‖: Risk Analysis and Management When Statistics Are Not Enough,‖ Risk Analysis, vol. 32, no. 11, pp. 1823–1833, Mar. 2012. D. Hillson, Effective Opportunity Management for Projects. CRC Press, 2003. K. De Bakker, A. Boonstra, and H. Wortmann, ―Does risk management contribute to IT project success? A meta-analysis of empirical evidence,‖ International Journal of Project Management, vol. 28, pp. 493–503, 2010. R. Holt, ―Risk management: The talking cure,‖ Organization, vol. 11, no. 2, pp. 251– 270, Mar. 2004.
CE
[20]
[34] [35] [36] [37] [38]
ACCEPTED MANUSCRIPT
[45]
[46] [47] [48] [49] [50] [51] [52]
AC
[53]
CR IP T
[44]
AN US
[43]
M
[42]
ED
[41]
PT
[40]
R. Miller and D. Lessard, ―Understanding and managing risks in large engineering projects,‖ International Journal of Project Management, no. 19, pp. 437–443, Sep. 2001. D. Hillson, ―Extending the risk process to manage opportunities,‖ International Journal of Project Management, vol. 20, no. 3, pp. 235–240, 2002. J. Galbraith, Designing Complex Organizations. Reading, MA: Addison Wesley, 1973. R. Olsson, ―Risk management in a multi‐ project environment,‖ Int J Qual & Reliability Mgmt, vol. 25, no. 1, pp. 60–71, Jan. 2008. R. P. Singh, ―A Comment on Developing the Field of Entrepreneurship through the Study of Opportunity Recognition and Exploitation,‖ The Academy of Management Review, vol. 26, no. 1, pp. 10–12, Jan. 2001. M. Marinho, S. Sampaio, and H. Moura, ―Uncertainties in software projects management,‖ presented at the 2014 XL Latin American Computing Conference (CLEI), 2014, pp. 1–10. M. V. Tatikonda and M. M. Montoya-Weiss, ―Integrating operations and marketing perspectives of product innovation: The influence of organizational process factors and capabilities on development performance,‖ Management Science, vol. 47, no. 1, pp. 151–172, Jan. 2001. H. P. Krane, A. Rolstadås, and N. O. E. Olsson, ―Categorizing risks in seven large projects-Which risks do the projects focus on?,‖ Proj Mgmt Jrnl, vol. 20, no. 3, pp. n/a–n/a, 2010. S. Nidumolu, ―Standardization, requirements uncertainty and software project performance,‖ Information & Management, vol. 31, pp. 135–150, 1996. L. M. Maruping, V. Venkatesh, and R. Agarwal, ―A Control Theory Perspective on Agile Methodology Use and Changing User Requirements,‖ Information Systems Research, vol. 20, no. 3, pp. 377–399, Sep. 2009. S. Faraj and A. Yan, ―Boundary work in knowledge teams.,‖ Journal of Applied Psychology, vol. 94, no. 3, pp. 604–617, May 2009. J. Ropponen and K. Lyytinen, ―Components of software development risk: How to address them? A project manager survey,‖ IEEE Transactions on Software Engineering, vol. 26, no. 2, pp. 98–112, Feb. 2000. S. J. Carson, T. Wu, and W. L. Moore, ―Managing the Trade-off between Ambiguity and Volatility in New Product Development,‖ Journal of Product Innovation Management, vol. 29, no. 6, pp. 1061–1081, Jun. 2012. T. Moynihan, ―Coping with ‗requirements-uncertainty‘: the theories-of-action of experienced IS/software project managers,‖ Journal of Systems and Software, vol. 53, no. 2, pp. 99–109, Aug. 2000. H. F. Hofmann and F. Lehner, ―Requirements engineering as a success factor in software projects,‖ IEEE Software, vol. 18, no. 4, pp. 58–+, 2001. M. Drury, K. Conboy, and K. Power, ―Obstacles to decision making in Agile software development teams,‖ Journal of Systems and Software, vol. 85, pp. 1239– 1254, Aug. 2012. W. Souder and R. Moenaert, ―Integrating market and R&D project personnel within innovation projects,‖ Journal of Management Studies, vol. 29, no. 4, pp. 487–512, Oct. 1992. L. McLeod and D. Smith, Managing IT Projects. Massachusetts: Boyd and Fraser Publishing, 1996. T. McBride, ―The mechanisms of project management of software development,‖ Journal of Systems and Software, vol. 81, pp. 2386–2395, Feb. 2008.
CE
[39]
[54] [55] [56] [57]
ACCEPTED MANUSCRIPT
[64] [65] [66] [67] [68] [69] [70] [71] [72]
AC
[73]
CR IP T
[63]
AN US
[62]
M
[61]
ED
[60]
PT
[59]
S. V. Sgourev, ―How Paris Gave Rise to Cubism (and Picasso): Ambiguity and Fragmentation in Radical Innovation,‖ Organization Science, vol. 24, no. 6, pp. 1601–1617, 2013. C. Larman and V. Basili, ―Iterative and incremental developments: A brief history,‖ IEEE Computer, vol. 2006, no. June, pp. 47–56, 2003. L. Jun, W. Qiuzhen, and M. Qingguo, ―The effects of project uncertainty and risk management on IS development project performance: A vendor perspective,‖ International Journal of Project Management, vol. 29, no. 7, pp. 923–933, Oct. 2011. A. M. Maier, D. Doenmez, and C. Hepperle, ―Improving Communication in Design: Recommendations from the Literature,‖ presented at the International Conference on Engineering Design, ICED11, 15 - 18 August 2011, Denmark, 2011. A. J. Shenhar and D. Dvir, Reinventing Project Management. Harvard Business Press, 2013. A. Marchenko and P. Abrahamsson, ―Scrum in a multiproject environment: An ethnographically-inspired case study on the adoption challenges,‖ Agile, 2008. AGILE '08. Conference, no. 4, pp. 15–26, 2008. N. Moe, T. Dingsoyr, and T. Dyba, ―A teamwork model for understanding an agile team: A case study of a Scrum project,‖ Information and Software Technology, 2010. A. M. Magdaleno, C. M. Lima Werner, and R. M. de Araujo, ―Reconciling software development models: A quasi-systematic review,‖ Journal of Systems and Software, vol. 85, no. 2, pp. 351–369, Feb. 2012. K. Schwaber and M. Beedle, Agile Software Development with Scrum. Upper Saddle River, NJ: Prentice-Hall, 2002. K. Beck, eXtreme Programming explained. San Francisco: Addison-Wesley, 2000. T. Dingsoyr, S. Nerur, V. G. Balijepally, and N. B. Moe, ―A decade of agile methodologies: Towards explaining agile software development,‖ Journal of Systems and Software, pp. 1213–1221, 2012. B. Schatz and I. Abdelshafi, ―Primavera gets Agile: A successful transition to Agile development,‖ IEEE Software, vol. 22, no. 3, pp. 36–42, May 2005. M. Golfarelli, S. Rizzi, and E. Turricchia, ―Multi-sprint planning and smooth replanning: An optimization model,‖ Journal of Systems and Software, vol. 86, no. 9, pp. 2357–2370, Sep. 2013. R. K. Yin, Case Study Research: Design and Methods. SAGE Publications, 2013. K. M. Eisenhardt and M. E. Graebner, ―Theory Building from Cases: Opportunities and Challenges,‖ The Academy of Management Journal, vol. 50, no. 1, pp. 25–32, Feb. 2007. P. Runeson and M. Hoest, ―Guidelines for conducting and reporting case study research in software engineering,‖ Empirical Software Engineering, vol. 14, no. 2, pp. 131–164, Apr. 2009. M. B. Miles, A. M. Huberman, and J. Saldaña, Qualitative data analysis. Thousand Oaks: Sage Publications, 2013. S. B. Merriam, Qualitative Research. John Wiley & Sons, 2014. J. C. Flanagan, ―The critical incident technique,‖ Psychological bulletin, vol. 51, no. 4, pp. 327–358, 1954. R. Vidgen and X. Wang, ―Coevolving Systems and the Organization of Agile Software Development,‖ Information Systems Research, vol. 20, no. 3, pp. 355–376, Sep. 2009. B. Fitzgerald, G. Hartnett, and K. Conboy, ―Customising agile methods to software practices at Intel Shannon,‖ Eur J Inform Syst, vol. 15, no. 2, pp. 200–213, Apr.
CE
[58]
[74] [75] [76] [77] [78]
ACCEPTED MANUSCRIPT
[86] [87] [88] [89] [90] [91] [92] [93]
AC
[94]
CR IP T
[85]
AN US
[84]
M
[83]
ED
[82]
PT
[80] [81]
2006. V. Mahnič and T. Hovelja, ―On using planning poker for estimating user stories,‖ Journal of Systems and Software, 2012. P. G. Smith, Flexible Product Development. John Wiley & Sons, 2007. R. Leifer, C. M. McDermott, G. C. OConnor, L. S. Peters, M. P. Rice, and R. W. Veryzer, Radical Innovation. Boston: Harvard Business Press, 2000. R. D. Austin and L. Devin, ―Research Commentary—Weighing the Benefits and Costs of Flexibility in Making Software: Toward a Contingency Theory of the Determinants of Development Process Design,‖ Information Systems Research, vol. 20, no. 3, pp. 462–477, Sep. 2009. S. Madsen, ―Conceptualising the causes and consequences of uncertainty in is development organisations and projects,‖ presented at the Proceedings of the 15th European Conference on Information Systems, ECIS 2007, 2007, pp. 855–864. A. Oke, N. Munshi, and F. O. Walumbwa, ―The influence of leadership on innovation processes and activities,‖ Organizational Dynamics, 2009. R. Hoda, J. Noble, and S. Marshall, ―The impact of inadequate customer collaboration on self-organizing Agile teams,‖ Information and Software Technology, vol. 53, no. 5, pp. 521–534, May 2011. M. A. Valentine and A. C. Edmondson, ―Team Scaffolds: How Mesolevel Structures Enable Role-Based Coordination in Temporary Groups,‖ Organization Science, vol. 26, no. 2, pp. 405–422, Apr. 2015. M. Song and M. M. Montoya-Weiss, ―The Effect of Perceived Technological Uncertainty on Japanese New Product Development,‖ The Academy of Management Journal, vol. 44, no. 1, pp. 61–80, Feb. 2001. E. Bonabeau, N. Bodick, and R. W. Armstrong, ―A more rational approach to newproduct development,‖ Harvard Business Review, 2008. R. Jiang, ―An Information-Entropy-based Risk Measurement Method of Software Development Project,‖ Journal of Information Science and Engineering, vol. 30, no. 5, pp. 1279–1301, Sep. 2014. S. Coyle and K. Conboy, A case study of risk management in agile systems development. Berlin: Springer, 2009. J. Surowiecki, The Wisdom of Crowds. Anchor, 2005. E. Kutsch, D. Denyer, and M. Hall, ―Does risk matter? Disengagement from risk management practices in information systems projects,‖ European Journal of Information Systems, 2012. R. Bradley and M. Drechsler, ―Types of Uncertainty,‖ Erkenntnis, vol. 79, no. 6, pp. 1225–1248, Aug. 2013. K.-S. Na, J. T. Simpson, X. Li, T. Singh, and K.-Y. Kim, ―Software development risk and project performance measurement: Evidence in Korea,‖ Journal of Systems and Software, vol. 80, no. 4, pp. 596–605, Apr. 2007. A. Moran, Managing Agile. Cham: Springer, 2015.
CE
[79]
[95]
ACCEPTED MANUSCRIPT Table 1. Overview of teams and project profiles
D
Finance
E
Insurance
F
Insurance
G
Finance
H
Finance
I
Software Dev. and IT Consulting Software Development
AC
J
K
Automotive
Interview participants 3 interviews: 1 team manager (Scrum Master) and 2 developer.
19 team members
5 interviews: 1 team manager (Scrum Master) and 4 developers, one of which later became a second Scrum Master. 4 interviews: 1 team manager (Product Owner) and 3 developers
CR IP T
Finance
Team size 7 team members
12 team members 12 team
AN US
C
The project was started 1.5 years prior to data collection with the aim to develop a software application that consolidates information from several customer relationship management products for internal company use. This project had two objectives. One was the development of a mobile application for end users, and the second was the creation of knowledge about new technologies that the company aims to exploit in the future. The project was started less than one year before data collection. For the previous five years, this project annually released improved versions of a software that is used by other software products of the bank to test their compliance with business rules. Team members regularly work in close collaboration with their clients from different departments of the company. The project has the objective of implementing enhancements to existing financial tools in the bank. It had been ongoing for only 3 months at the time of interviewing, and the team was still in the process of setting up agile development practices.
M
Telecommunications
ED
B
Project The project is run in close collaboration with a client in the ventilating and air-conditioning industry for whom an embedded system of smart devices is constantly enhanced. The project is one of company A‘s most stable collaboration and has been ongoing for more than 5 years with different team members working on it. The project had been set up two years before data collection in order to develop an application for customer order management of future product offerings. The team consists of several external developers who are contractors with special knowledge about functionality provided by suppliers. The client is internal to the company. This project was started two years before data collection with the objective to develop an archiving system for documents that need to be stored and retrieved digitally across the company‘s various locations. The client is internal to the company. The project serves the development and continuous improvement of new company communication technologies. It started seven years prior to data collection, with two product release cycles per year.
PT
Industry Software Development
This project was set up two years prior to data collection to develop an application as ordered by the client, which integrates control over 54 different hardware products via a mobile interface. This project involves the development, deployment and operation of a server back-end for a web and mobile consumer application, which integrates several services. It has been ongoing for two years. The development team works closely together with a larger team of the company that develops a specialized service for the back-end system. The objective of this project is to create smartphone applications and end-user software for integrated systems. The focus of the interviewed team was on navigation and routing software.
CE
Team A
12 team members 5 team members and 1 Scrum coach 10 team members
12 team members
6 team members
5 interviews: 2 team managers (Scrum Master and Product Owner) and 3 developers 4 interviews: 1 team manager (Product Owner) and 3 developers. 4 interviews: 1 team manager (Product Owner), 2 developers and the Scrum coach 4 interviews: 2 team managers (Scrum Master and Product Owner) and 2 developers 3 interviews: 1 team manager (Scrum Master), 1 external stakeholder (acting as Scrum coach) and 1 developer. 4 interviews: 1 team manager (Product Owner) and 3 developers
3 team members
3 interviews: 1 team manager (Scrum Master) and 2 developers.
4 team members
3 interviews: 1 team manager (Scrum Master) and 2 developers.
ACCEPTED MANUSCRIPT
Table 2. Practices for approaching uncertainty
Uncertainty anticipation
1. Incorporating uncertainty in plans 2. Developing vigilance 3. Incremental feedback
Information accrual
4. Team based task analysis 5. Knowledge sharing Solution inspection
6. Prototyping
7. Creating alternatives Role-based 8. Creating coordination functional roles
Related agile techniques* Increment planning (Not explicitly advised) Product review (for customer feedback) Planning Poker & Increment planning Pair programming & information radiators Prototyping (Not explicitly advised) (Not advised; Scrum even discourages this practice) Product review
Description of practice Acknowledging that changes will occur, teams try to anticipate and focus on product requirements least expected to change, yet remain flexible to adapt their plans. Team members strive to remain alert to opportunities that present themselves. Team members frequently collect feedback from colleagues and external project stakeholders.
CR IP T
Practice
Team members collectively analyze requirements before they create and plan tasks. Knowledge management structures are established to manage resource uncertainty. Preliminary versions of the final product foster discussions on functionality and indicate the quality of different possible solutions. Developers strive to explore several solutions in parallel to determine which best fits customer expectations. Team member roles are created temporally in order to handle unexpected events efficiently.
AN US
Principle
AC
CE
PT
ED
M
9. Stakeholder Teams value close collaboration with suppliers and clients integration and design decision structures accordingly. 10. Task Pair programTeams aim to create structures that permit developers to switching ming flexibly distribute tasks to freed resources. *The mentioned agile techniques are related to, but do not entirely cover the practices detailed on the left (with the exception of prototyping). A list of technical and non-technical agile techniques can be found in [95].
ACCEPTED MANUSCRIPT
Appendix A. Interview questions Guiding questions Purpose [Provide information about the purpose of the Explanation of the research context and interview, which is to study uncertainty questions, as well as the interview method. management in teams. Guarantee anonymity.] Explain critical incidents approach: ―I would like to go through different situations with you that are related to the team having to deal with uncertainty. There are different types of uncertainty, related to resources, tasks and requirements. I would like you to try and recall any situation in as much detail as you can and explain it to me step by step.‖ Project Please tell me about the project. Collect background information of the Background Please tell me about your role and tasks in the project, including its history, current focus, team. number of team members, stakeholders and what is expected from them, and the specific role of the interview partner. Uncertainties Can you remember a situation in your team in Collect incidents related to different types of (negative) which you have experienced negative uncertainty and their positive/negative consequences of uncertainty? consequences. Clarify understanding for What led to this situation? different uncertainty types: How did this affect the project? Resource uncertainty How did this affect your work? - (Un)availability of developers, software What was the team‘s reaction? tools, technical infrastructure, incl. How often does a situation like this happen? technical failures (e.g., licenses, servers) [Repeat for specific types of uncertainties: Requirement uncertainty 1) resource, 2) task, 3) requirement] - Changes to the product / features - Shared understanding of the requirements Task uncertainty - How clear is it what needs to be done? - How many features can be implemented in the given time frame? - How precise are estimations (how often are they changed?) Uncertainties Can you remember a situation in your team in (positive) which you have experienced positive consequences of uncertainty? What led to this situation? How did this affect the project? How did this affect your work? What was the team‘s reaction? How often does a situation like this happen? [Repeat for specific types of uncertainties: 1) resource, 2) task, 3) requirement] Conclusion [Announce the end of the interview, thank Provide opportunity to add comments / of the interviewee for their time and transition to remarks / additional relevant information. interview concluding remarks] Is there anything you would like to add? Thank you for your time.
AC
CE
PT
ED
M
AN US
CR IP T
Topic Introduction
ACCEPTED MANUSCRIPT Appendix B. Coding scheme Uncertainty Characteristic Achievable amount of work Availability of process artifacts Quality of input
Code
Explanation
Practice
Updating task estimations
4. Team based task analysis — (4.)
Availability of human resources
Working with redundant roles / skills
Task sizes are estimated in the planning game as a team-based activity Specific problems and possible solutions are shared with all team members To avoid lack of quality regarding supplied products, suppliers are closely integrated, e.g. in daily team meetings Several team members are required to be able to perform a specific task Important project information is centrally documented
Discussing workarounds with the whole team Increasing collaboration with suppliers
Maintaining a projectwide knowledge base
M
Lack of details about demanded functionality
Matching task dependencies to developer availabilities Integrating stakeholders‘ feedback
ED
Requirement
PT
Direct communication with customers Early prototyping
AC
CE
Ambiguous information
Visual planning (e.g., using charts, workflows, calendars posted to the wall) based on available and non-available information (represented by wildcard or scenarios) is used to clarify where uncertainty remains Developers are dynamically assigned tasks / roles to minimize task dependencies (idle times) Frequently integrating feedback from customers, managers, and other stakeholders supports the clarification of requirements and mitigate ambiguity Engaging in direct communication mitigates ambiguity Discussions with customers are based on prototypes from the start of a project Development of multiple solutions can be beneficial to get better feedback (internal and external) In searching for the best way to solve a problem, possible future constraints and then available or then no longer available options are considered Phases of stable development are interrupted by openness to change (e.g., after an iteration or a release cycle) to establish a rhythm of certain/uncertain development Testing early and frequently provides incremental feedback Integrating stakeholders, e.g. through direct communication, provides feedback Using knowledge management to
AN US
Enhancing transparency
Creating alternative solutions Anticipative search for technical solution
Unexpected changes
Allowing change requests only at certain points in time
Demanded quality of the product
Testing solutions
Quality of a
Improve discussions
Involve external stakeholders
9. Stakeholder integration
CR IP T
Uncertainty Type Resource
10. Task switching 5. Knowledge sharing 1. Incorporate uncertainty in plans
8. Creating functional roles 3. Incremental feedback — (9.) 6. Prototyping 7. Creating alternatives 2. Developing vigilance — (1.)
— (3.) — (3.) — (5.)
ACCEPTED MANUSCRIPT solution to a problem
Unexpected difficulties
Pooling team members into task forces Pair programming Using signaling devices
Mutual team member support Task sequence or process uncertainty
Using ad hoc meetings
Team reflections
AN US
Minimizing task sizes and dependencies
AC
CE
PT
ED
M
Time required to accomplish a task
improve discussions Creating temporal roles directed at specific problems Working in pairs increases the spread of knowledge within teams Visual tools are used, e.g., for blocked tasks (on the planning board) or within computer aided collaboration tools Abilities to support team members is cultivated, which enables task switching Frequent, small, ad hoc / informal meetings are used to discuss progress, solve minor problems, clarify tasks Team reflections are used to improve processes, for example to establish roles for specific tasks Small tasks allow more flexibility
— (8.) — (5.) — (5.)
— (10.) — (5.)
CR IP T
Task
— (8.)
— (10.)
Two Sides of The Same Coin – How Agile Software Development Teams Approach Uncertainty as Threats and Opportunities Denniz Donmez , Gudela Grote ¨ PII: DOI: Reference:
S0950-5849(17)30465-2 10.1016/j.infsof.2017.08.015 INFSOF 5873
To appear in:
Information and Software Technology
Received date: Revised date: Accepted date:
29 October 2015 15 July 2017 31 August 2017
Please cite this article as: Denniz Donmez , Gudela Grote , Two Sides of The Same Coin – How Agile ¨ Software Development Teams Approach Uncertainty as Threats and Opportunities , Information and Software Technology (2017), doi: 10.1016/j.infsof.2017.08.015
This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.
ACCEPTED MANUSCRIPT Highlights Uncertainty (impactful, incomplete information) is inherent in product development. Mostly regarded as threat, uncertainty also carries potential opportunities. Successfully managing uncertainty requires collaborative team practices. To distinguish opportunities from threats, teams combine different practices.
AC
CE
PT
ED
M
AN US
CR IP T
Our analysis of agile dev. teams details ten practices and four general principles.
ACCEPTED MANUSCRIPT TITLE Two Sides of The Same Coin – How Agile Software Development
AUTHORS Denniz Dönmez (corresponding author), [email protected] Gudela Grote, [email protected]
AN US
AFFILIATION ETH Zurich
Chair of Work and Organizational Psychology
ADDRESS
AC
CE
Switzerland
PT
Weinbergstrasse 56-58
ED
M
Department of Management, Technology and Economics
CH-8092 Zurich
CR IP T
Teams Approach Uncertainty as Threats and Opportunities
ACCEPTED MANUSCRIPT
ABSTRACT Context: Uncertainty affects software development projects in many ways. Capabilities to manage uncertainty can determine the success or failure of entire projects and even companies. Against failure rates of software development projects, uncertainty is often
CR IP T
viewed in a negative light. Its relevance as enabler of learning and innovation tends to be disregarded by scholars and practitioners.
Objective: This study extends research that empirically investigates approaches to dealing with different types of uncertainties. Acknowledging both the possibility for negative and
AN US
positive consequences of uncertainty, we aim to expand existing knowledge and contribute to improving the practices to handle uncertainty in software development. Method: A multiple-case study including field observations and in-depth interviews with 42
M
professional software developers was performed with a sample of 11 agile software development teams from different Swiss companies.
ED
Results: We detail practices employed to mitigate threats while simultaneously allowing teams to remain open to opportunities. We establish a taxonomical classification of
PT
uncertainty in software development, which extends beyond often-addressed requirements
CE
uncertainty and additionally includes uncertainty related to resource availability and task specifications. Against the background of different uncertainty types, we discuss distinct
AC
practices and four overarching principles to approach uncertainty using strategies for threat avoidance versus opportunity realization. Specifically, we find that employed practices are guided by 1) uncertainty anticipation, 2) information accrual, 3) solution inspection, and 4) role-based coordination. Conclusion: We argue that approaches to dealing efficiently and effectively with uncertainty can be improved when teams distinguish between different types of uncertainty and treat
ACCEPTED MANUSCRIPT them explicitly as threats versus opportunities. Whereas potential to seize opportunities is under-used, agile methods could evolve into better frameworks supporting the systematic search for innovation. We discuss the implications of our findings for agile development teams in particular and product developing organizations in general.
CR IP T
KEYWORDS: Uncertainty; Risk; Threat;
AN US
Opportunity; New Product Development; Agile Software Development;
AC
CE
PT
ED
M
Multi-case study;
ACCEPTED MANUSCRIPT 1. INTRODUCTION Uncertainty is one of the fundamental facts of life. It is as ineradicable from business decisions as from those in any other field. F. H. Knight [1, p. 347]
Uncertainty pervades the work of software development teams. It affects many
CR IP T
decisions and is highly critical for project performance [2-4]. Software development teams cannot afford to ignore uncertainty, because it can lead to increased development costs, low product quality, delayed product delivery and dissatisfied customers [5]. The criticality for software development projects is increased by the fact that uncertainty can stem from
AN US
different sources and affect many different aspects of software development, which makes it difficult to ‗manage‘ [6]. It is not possible to effectively manage uncertainty in a way that achieves full control over it. We adopt the perspective that uncertainty management should
M
rather be viewed as the approach that is taken in order to deal with uncertainty. Given a specific situation, when managing uncertainty, teams may choose between different
ED
approaches, including to investigate uncertain issues (and thereby reducing uncertainty or
uncertainty [7].
PT
shifting it to another issue), to deliberately ignore uncertainty, or even to increase
CE
Different approaches are important because uncertainty is not inherently good or bad. Whereas uncertainty affects decisions that can cause projects and even entire companies to
AC
fail, uncertainty is also a vital predecessor of innovation [8]. No economic profit exists without uncertainty [9]. Hence, uncertainty management occupies a critical role in software and other product innovation projects, where levels of uncertainty are high [10, 11]. Yet, few acknowledge the ―dual nature‖ of uncertainty that bears the possibility for negative as well as positive effects [12].
ACCEPTED MANUSCRIPT Much of the literature on uncertainty has ignored beneficial aspects and has instead argued for the reduction of uncertainty [13]. For example, authors have discussed the need to reduce uncertainty arising as a consequence of changing requirements because of their potentially large impacts on development projects [14, 15]. Thorough planning is often advised to avoid negative impacts on product quality, as well as on project schedule and cost,
CR IP T
which are known as the triple constraint or ‗iron triangle‘ [16]. Recently, however, cautioning voices increase, which criticize a focus on planning for its ignorance of potential opportunities [17, 18]. Innovation research points to the benefits of developing capabilities to incorporate design changes even at late stages in the project [19, 20]. While the reduction of
AN US
negative consequences from uncertainty is increasingly addressed in the literature [21], there is scant guidance and insufficient insight for product development teams regarding the question of how to reap positive effects of uncertainty through appropriately suited
M
approaches. Specifically, little is known about if and how the same approaches employed by teams can bring about positive and negative consequences of uncertainty.
ED
Highly collaborative approaches to software development, such as Agile Software Development [22], aim to enable teams in responding to uncertainty and the unforeseeable
PT
changes caused by it [23]. Uncertainty has tremendous impacts on projects, and its
CE
management remains one of the largest unresolved challenges for teams and the organizations they belong to [24, 25]. Several scholars point out that the current trend to
AC
increasingly employ agile software development techniques acknowledges the need to manage – as opposed to reduce or control – uncertainty by undergoing cycles of inspection and adaption to changes [23, 26, 27]. Agile development methods provide some important guidance that affects how teams approach uncertainty, however, often only implicitly so. As a result, there is room for improvement regarding their capacity to innovate which is connected to the systematic search for opportunity [28]. In particular, we study agile software
ACCEPTED MANUSCRIPT development methods to shed light on the potential provided by different, complementary agile practices to consider different types of uncertainty and view uncertainty not only as potential threat but also as potential opportunity. The main research question underlying our study is: How do agile software development teams approach different types of uncertainty as threats and opportunities? In
CR IP T
the context of this question, several other aspects are important: How are software development projects influenced by different types of uncertainty and how can teams deal with these different types of uncertainty? How is information collected, analyzed and used in
teams as threats and/or as opportunities?
AN US
order to handle uncertainties? Are uncertainties viewed and approached by development
To answer these questions and to investigate strategies and practices for the management of uncertainty, we conducted an empirical study that explicitly acknowledges
M
both threats and opportunities (i.e., the potential to create innovation) embedded in uncertainty. We draw on the uncertainty management literature to derive different types of
ED
uncertainty and to subsequently investigate the practices teams use for their management. While agile software development methods seem especially well suited to handle (especially
PT
the negative consequences of) uncertainty, an important contribution of our study lies in the
CE
differentiation between positive and negative uncertainties. We derive implications for researchers and practitioners based on the premise of fully acknowledging these two
AC
contrasting qualities of uncertainty. In the following sections, we first explain how uncertainty has been conceptualized and
distinguished from risk or threat. We delineate different perspectives on uncertainty and present an investigation of how distinct types of uncertainty are approached in agile software development projects. Based on the empirical investigation of strategies for uncertainty management, we solidify the understanding of uncertainty management as a team-based
ACCEPTED MANUSCRIPT endeavor of addressing both threat and opportunity embedded in uncertainty. Our findings are structured along a taxonomy of uncertainty that we link to different strategies for approaching uncertainty. While our results detail the efficacy of different agile software development practices to address uncertainty, they also permit conclusions regarding overarching principles that may guide product development teams in settings beyond agile
CR IP T
software development.
2. THEORETICAL BACKGROUND
AN US
2.1 DEFINING UNCERTAINTY
The concept of uncertainty centers on missing information [13]. However, as Argote notes, ―there are almost as many definitions of uncertainty as there are treatments of the subject‖
M
[29, p. 420]. Their commonality is incomplete information, or ―not knowing for sure‖ [30]. Yet, the ―manifold nature of uncertainty‖ [31] covers a range of aspects including risk,
ED
ambiguity, and equivocality. Hence, we need to ascertain further qualities of these concepts in order to grasp uncertainty empirically.
PT
While it may be difficult to determine exactly what uncertainty can be manifested in,
CE
we can move the attempt of a definition forward by contrasting it with similar concepts. For example, uncertainty entails ambiguity, which is associated with confusion over several
AC
possible interpretations [32]. Furthermore, uncertainty is often associated with risk [33]. Scholars acknowledge a fundamental difference between risk and uncertainty, however, that can be traced back to Knight [1], who put forward the idea that risk can be assigned a probability, whereas uncertainty refers to something that is immeasurable. This essential difference has since permeated the literature to this day and is reflected in the works of many authors such as Aven and Renn [34] and Paté-Cornell [35]. Hillson [36] nicely summarizes
ACCEPTED MANUSCRIPT the difference as follows: ―Risk can be said to be aleatoric [from the Latin word alea, meaning dice], whereas uncertainty is described as epistemic [which is derived from the Greek word episteme, meaning knowledge].‖ This indicates that risk refers to an unknown event that leads to one outcome from a set of known outcomes, each of which can be assigned a probability (however estimated). Uncertainty, in contrast, relates to a lack of
CR IP T
knowledge about which outcomes are possible, including both ―their nature and associated probabilities. An ‗uncertainty‘ is thus an unknown event from an unknown set of possible outcomes‖ [36, p. 27]. Another way Hillson [36] offers to distinguish the relationship
―Risk is measurable uncertainty; Uncertainty is unmeasurable risk.”
AN US
between risk and uncertainty is captured in the following couplet:
As a result, it may not be able to approach uncertainty by the same means as risk [37].
M
Holt summarizes that ―uncertainty pertains where probability has no grip‖ [38, p. 253]. Following product development researchers, we rely on a conceptualization of uncertainty
ED
that encompasses the impact of ―anything that matters‖ [33, p. 98], defining it as the lack of certainty that leads to a situation in which ―potential outcomes and causal forces are not fully
PT
understood‖ [39, p. 438]. Specifically, in line with Hillson [15, 40] we define uncertainty as
CE
incomplete information that bears the potential for positive or negative consequences of high impact on project objectives. In other words, uncertainty is the discrepancy between the
AC
information that is available and the information that is required (but not yet available) toward reaching a goal [41]. It is important to note that, in divorcing risk from uncertainty, Knight has also
established uncertainty as the underlying reason for corporate profit (based on the argument that risk can be assigned expected values, therefore inviting the possibility for insurance), and he warned that the consequences of uncertainty can also be negative [1]. An organization‘s
ACCEPTED MANUSCRIPT welfare, therefore, results from exploiting the potential of uncertainty without exposing itself overly to its negative effects [38]. Over the course of a project, diverse situations arise in which teams must distinguish between threats and opportunities. Enabling them to do so, therefore, is a prerequisite for the successful management of uncertainty. A focus on uncertainty rather than risk has been suggested to enhance project
CR IP T
management by ―providing an important difference in perspective, including, but not limited to, an enhanced focus on opportunity management― [33, p. 97]. Although neither risk nor uncertainty are necessarily harmful, both are usually associated with negative rather than positive aspects [33]. Although we have not excluded the literature on ‗positive risk‘ for this
AN US
study [13, 36, 42], we refrain from using the term ‗risk‘ in this study in order to avoid confusion. Instead, we use the terms ‗threat‘ and ‗opportunity‘ when we refer to any negative or positive associations of uncertainty, respectively. By definition, opportunity refers to ―a set
M
of circumstances that makes it possible to do something‖ (New Oxford American Dictionary) and creates or adds value for the customer or end user [43]. Following Hillson [40], we use
ED
the term opportunity for any positive influence toward the benefit of a project that is not necessarily envisioned at its outset but rather recognized during the course of the project. An
PT
Example is an unexpectedly discovered business opportunity. In contrast, we use the term
CE
threat to refer to any potential negative association, such as the threat to delay the project or
AC
increase the budget that is necessary.
2.2 TYPES OF UNCERTAINTY
Studies of uncertainty usually do not consider different types of uncertainty. They either treat the concept as a singleton, or narrow their focus on one specific type, such as requirement uncertainty, while ignoring others [8]. Recognizing differences within the conceptualization of uncertainty is important for successfully approaching them [44], because various strategies
ACCEPTED MANUSCRIPT may exist to cope with several types of uncertainty [31] and different approaches can hold distinct implications for development projects [45]. However, defining different categories to study uncertainty can be achieved in many ways. Krane and colleagues note that an abundance of categories can be—and have been— constructed by scholars, and advice that categorization schemes should be generic in order to
CR IP T
be unbiased by the way in which one organizes one‘s world [46, p. 83]. Constructing two categories, such as to distinguish uncertainties that result from internal versus external sources [13], may, however, yield insufficient potential to derive meaningful implications for teams. On the other hand, defining a scheme with many types of uncertainty may introduce
uncertainty
(technology,
market,
AN US
unnecessary complexity to a study. For example, Jalonen‘s [8] eight different types of regulation,
social/political,
acceptance/legitimacy,
managerial, timing, and consequence uncertainty) are not suited to our study of software
M
development teams because they are ill-defined with regard to the exclusivity of each category; when studying uncertainty, we need to be able to attribute our findings
ED
unequivocally to one type with confidence. A scheme that contains a number of uncertainty types that are mutually exclusive
PT
while they are also exhaustive is presented by Moran [28]. It explicitly addresses three
CE
aspects, including requirements (which is the most covered aspect across all studies), as well as project, supplier and schedule (which are related to the availability of resources), and
AC
technical and people aspects (which are concerned with work or task related issues). We rely on these three different, overarching aspects to inform our study, which explicitly spans a set of different uncertainty types to investigate positive versus negative aspects. We adopt the categories of a) requirement related uncertainty; b) resource related uncertainty; and c) task related uncertainty, as we find these overarching types to be prevalent in the software development literature [45, 47-50].
ACCEPTED MANUSCRIPT Requirement uncertainty is the projection of distinct external sources of uncertainty stemming from changes in the market, as well as from regulatory, social, or political changes [8]. Requirements uncertainty is conceptualized as incomplete information regarding product functionality [2], and includes different aspects, such as volatility (environmental turbulence) and ambiguity about the correct interpretation of environmental signals [51]. Requirements
CR IP T
uncertainty is central in software development and is often addressed in the literature [52], [53].
Resource uncertainty refers to incalculable means of production that are necessary to complete the work [50]. The resources that are necessary to accomplish software
AN US
development projects, which are subject to uncertainty, include the fundamental production factors of human [54] and financial capital [55]. They span the unpredictable or unreliable availability of software development capabilities and necessary infrastructure, such as
M
software licenses, test user accounts, and other means of production.
Task uncertainty refers to the lack of knowledge regarding the best way to approach
ED
a work related problem. This can, for example, stem from inexperience or insufficient knowledge concerning the employed technologies [45]. In the IS literature, task uncertainty
PT
often refers to either inexperience concerning the employed technology or to an insufficient
CE
understanding of a problem in order to complete a task [56]. Software developers commonly experience task uncertainty with regard to optimal solutions to novel problems, or incomplete
AC
information regarding the capabilities and knowledge needed to accomplish a task. The distinction of types of uncertainty in the software development literature
introduces the possibility of threats and opportunities arising in different ways for each type. Therefore, software development teams need to be wary of differences and develop a portfolio of adequate approaches for their exploitation versus mitigation.
ACCEPTED MANUSCRIPT
2.3 DEALING WITH UNCERTAINTY There is a long history of recommendations for the reduction of uncertainty, which is accompanied by attempts to increase control over development processes [48]. While uncertainty is ―inherent to every aspect of software development‖ [5], no widely accepted
CR IP T
general framework has emerged for the management of uncertainty.
More recently, scholars started to emphasize the importance of flexibility in order to manage uncertainty [57]. Arguing for the need to react quickly to unforeseen events, this stream of literature acknowledges levels of complexity that deem any attempt for control
AN US
utopian and, hence, favors agile development approaches.
These two different practices can be attributed to two general approaches to manage uncertainty; coping with uncertainty versus minimizing uncertainty [30]. Minimization is
M
aimed at the increase of control and based on strategies to eliminate as much uncertainty as possible. While this seems desirable at first sight, it may be neither possible (e.g., when the
ED
source of uncertainty lies beyond the influence of the uncertainty manager), nor most beneficial in important situations (e.g., when an uncertainty turns into an opportunity).
PT
Coping strategies, in contrast, do not aim to eliminate uncertainty, but manage it flexibly.
CE
This, however, requires increased effort and follows no standardizable procedure. For example, coping mechanisms may require deferring problems [17] while additional
AC
information is collected, or decision makers might rely on assumptions or intuition [31]. Choosing not to eliminate but rather to cope with uncertainty implies acknowledging that some uncertainties cannot be eliminated, and furthermore, to recognize that the elimination of certain uncertainties would lead to a deprivation of opportunities for innovation [20, 58]. Successful approaches to uncertainty reach beyond preempting the consequences of threats. It is the attempt to exploit the benefits of uncertainty while avoiding exposure to its
ACCEPTED MANUSCRIPT negative aspects. Thus, software developers are charged with managing uncertainty in a way that aims at controlling threats while simultaneously remaining receptive for opportunities that may arise from the same sources.
2.4 AGILE SOFTWARE DEVELOPMENT APPROACHES TO UNCERTAINTY
CR IP T
In software development, the perception of uncertainty is dominated by requirements uncertainty [47, 50]. Diverse measures for requirements uncertainty have been proposed in order to mitigate resulting threats to product performance [59, 60]. For example, the improvement of communication and planning practices are prominent among the
AN US
propositions for improved robustness of requirements [61]. However, unsuccessful attempts to protect requirements from changing have spawned alternative approaches that structure development around cyclical phases of step-by-step refinement [59], which allow
M
development teams to meet unforeseen situations with the possibility to react flexibly when changes occur. This development reflects the critique on up-front planning in complex
ED
projects. Accordingly, endeavors to meet the triple constraint (cost, time, quality) are increasingly replaced by iterations of re-planning [62]. Different agile methods have been
PT
adopted by large numbers of software development teams in the last decade [63]. By
CE
introducing flexible techniques to react to changes, they offer an approach that differs starkly from traditional plan-driven project management [64, 65]. In particular, they supply teams
AC
with practices that support uncertainty management by equipping developers with considerable flexibility [66]. Importantly, uncertainty management is not equated with the minimization or elimination of uncertainty per se, but part of the strategy to inspect and adapt to unexpected events. However, the potential of agile software development methods for a proactive approach to carefully observing and possibly even fostering (as opposed to categorically eliminating) uncertainty to facilitate its management is not explicitly discussed
ACCEPTED MANUSCRIPT in a straightforward manner, and different agile methods need to be combined to address several types of uncertainty. Agile methods explicitly suggest practices for team coordination such as frequent planning and empowering developers to self-organize in support of coping with uncertainty [23, 25, 48]. Of these methods, especially Extreme Programming (XP) [67] and Scrum [66]
CR IP T
are most widely adopted by agile software developers and have been studied predominantly [68]. Scrum, for example, suggests a managerial (as opposed to engineering practices) approach to development projects in its emphasis on collaboration structures and team autonomy. Investigating relationships among project control, team autonomy, and project
AN US
performance Maruping and colleagues found that the use of agile methods is most effective in environments with high levels of uncertainty [48]. Scrum does not provide explicit suggestions using the language of uncertainty management. Still, it addresses the concept
M
especially in the form of minimizing requirements uncertainty. Development teams often complement it by borrowing from XP, which offers complementary computer programming
ED
practices, which in part support teams in addressing uncertainty. For example, prototyping and incremental task planning inform and starkly impact the potential of teams to deal with
PT
different types of uncertainty without being based on their elimination. XP practices,
CE
however, do not cover overall project level requirements. Therefore, teams need to develop agility based on combinations of different agile methods.
AC
Agile practitioners use of short development iterations of two to four weeks that are
interrupted by customer feedback loops primarily to support teams in minimizing threats from volatile or ambiguous requirements through the frequent and regular validation of their work by stakeholders. Scrum also advocates team retrospective meetings for reviewing work processes after each iteration, and suggests a number of meetings to plan iterations and carry out daily meetings to mutually update team members. Supported by visualization tools, these
ACCEPTED MANUSCRIPT meetings facilitate the monitoring of projects with regard to several aspects including requirements changes and the forecasting of short term productivity. Emphasis is laid on empirically testing solutions, for example, by rapid prototyping and incremental improvement. These activities foster collecting information incrementally and thereby support the quality of decision making [54]. Different agile methods suggest a number of
CR IP T
practices that extend well beyond the use of iterations. However, there is a lack of guidance for practitioners with regard to the management of uncertainty (as opposed to their reduction). This is not only lamentable but also incomprehensible given the wide acknowledgement of the need for uncertainty management in the agile software development
AN US
literature [27, 69].
Agile software development methods attend to the need for uncertainty management more than classical approaches to software development [70], yet, as Moran [28] concludes,
M
they do so only passively and implicitly, which can lead to misdirected and misunderstood activities. More importantly, their potential for systematically addressing opportunities that
ED
arise from uncertainty has largely remained under-studied. On the one hand, reaping this potential requires increased understanding for how decision makers distinguish threat from
PT
opportunity. On the other hand, it is important to investigate if and how threat and
CE
opportunity can be managed using the same mechanisms for addressing uncertainty. These questions are important as they affect the core activities of development projects. Therefore,
AC
we seek to explore practices, i.e. activities commonly employed by agile software developers, as well as overarching guiding principles that stretch beyond the suggestions provided by agile methods. To better understand the practices employed and principles followed to handle uncertainty both in terms of avoiding threats and capitalizing on opportunities, we designed a qualitative study of agile software development teams outlined in the following section.
ACCEPTED MANUSCRIPT 3. RESEARCH APPROACH In order to capture how teams deal with different types of uncertainty, we performed a multiple-case study [71] based on observations and semi-structured interviews with professional software developers across different research sites. Multiple-case studies allow to identify patterns in organizational practices [72]. They are suited to examine contemporary
CR IP T
corporate phenomena, such as agile development techniques, triangulate information gathered in their natural context [73] based on multiple data sources [71].
3.1 SAMPLE AND DATA COLLECTION
AN US
Data collection included field observations and 42 face-to-face interviews with professionals from 11 agile software development teams. Our sampling strategy focused on teams employed in settings with considerable levels of uncertainty, where agile development
M
methods are often employed. All teams followed the Scrum method, while some teams complemented it with development techniques from Kanban and XP, such as work-flow
ED
limitation (to constrain focus on a small number of tasks), pair programming (where two programmers collaborate by simultaneously sharing one computer), test-driven development
PT
(where quality criteria for the software code are defined prior to writing the code), and other
CE
complementary techniques not originally included in the Scrum framework. The teams also modified the framework to fit their specific needs. For example, some teams altered the
AC
iteration lengths when needed, and none of the teams had a full-time Scrum Master. The teams in our sample belonged to five software-developing companies from
different industries that are located in Switzerland and operate globally. While we strove for depth by capturing situations in agile teams with similar features (e. g., team tenure, team size), we deliberately selected teams that might face various types of uncertainties (e. g., because of differences in product and customer structures, or being situated in different
ACCEPTED MANUSCRIPT industries.) Details regarding the teams‘ project characteristics are summarized in Table 1. Interviews ranged from 20 to 90 minutes (43 minutes on average). All interviews were audiorecorded and transcribed verbatim as soon as possible after they had been conducted. During data collection, we visited each team at several points in time over the course of their projects, and had the opportunity to meet most of the team members informally. We also had
CR IP T
the possibility to talk with different internal and external stakeholders of the software development projects to discuss the research progress, verify insights and clarify our understanding where necessary. When the answers to our questions ceased to provide new information and started to become similar of previously collected responses, i.e. no additional
AN US
insights were gained from further interviews, and the situations and practices described to us were repeated across participants in a congruent way, we concluded that we had reached theoretical saturation [74] and stopped collecting more data.
M
-----------------------------------Insert Table 1 about here
ED
------------------------------------
We conducted interviews with individuals holding as many different functions as
PT
possible within their team, following a self-imposed policy to always include at least one
CE
team member outside of the development team, i.e. the Scrum Master or Product Owner, and two team members with distinct software development tasks. In each team, the first author
AC
conducted formal interviews with software developers and team leaders. The multiple sources in each team allowed to us triangulate situations from the perspectives of different team members, which increased the quality of our data [75]. To guide our interview questions, we adopted a theoretical framework consistent with the literature on uncertainty management that suggests that multiple uncertainty types govern project work. Based on different types of uncertainty, we produced a semi-structured
ACCEPTED MANUSCRIPT interview guideline to cover different uncertainties; however, during the interviews the first author also followed interesting clues and probed for details whenever he felt this would contribute to a more thorough understanding. Interview partners were asked how their teams had dealt with uncertainty in different situations in the past and during ongoing projects. They were encouraged to share examples for incidents that had either positive or negative
CR IP T
associations. This approach was based on probing for critical incidents [76], but allowed for flexibility when we felt this was appropriate. We encouraged participants to talk openly about situations, which they had experienced in their teams. The teams were informed about our research objective to investigate the management of various types of uncertainties that are
AN US
faced in software development projects, and were subsequently asked about a number of situations in which they or their teams experienced resolved or unresolved problems or difficulties of any kind. We also asked for specific examples of experiences that had occurred
M
a) recently and b) during the course of the entire current project. In each case, we probed for further information in order to obtain a better understanding of the situation, including
ED
descriptions of relevant information such as preceding events or reactions by stakeholders. In some cases, we were able to exploit this knowledge in subsequent interviews in order to
PT
capture different views of issues that the teams had experienced. This allowed us to construct
CE
and analyze situations based on descriptions from different perspectives. Our data collection was guided by the exploration of how the teams dealt with
AC
different uncertainties, namely regarding requirements, tasks and resources. Interviews commenced with a set of general questions (e.g., regarding the status and progress of the project), subsequent to which we would ask specific uncertainty-related questions such as, ―Has there ever been a situation in which your team was unsure about the best way to complete a task?‖ or ―Do you remember a situation in which the availability of team members was uncertain?‖ In most cases, we had to clarify the concepts we wanted to study
ACCEPTED MANUSCRIPT by examples or, otherwise, use vocabulary from a software development context in order to correctly comprehend our questions. We further inquired about the consequences and subsequent actions taken. As we commenced to systematically analyze the data, we increasingly let clues that we developed influence subsequent data collection by extending our interview guideline and
CR IP T
including further interesting aspects as far as this did not compromise the time to cover our initial set of questions regarding the management of uncertainty. This allowed us to understand the teamwork context more fully and helped us to develop interesting insight
AN US
regarding the potential and boundary of uncertainty management.
3.2 DATA ANALYSIS
We performed data analysis in an iterative fashion, oscillating between data collection and
M
analysis as we repeatedly returned to the field for additional observations and interviews.
teams for clarification.
ED
Especially whenever we felt a lack of understanding of our data, we strove to revisit the
In order to make sense of our data, we began by reading through the field notes and
PT
interview transcripts that were produced after the field visits. This allowed us to establish an
CE
overview of the data according to our initial questions regarding the way in which teams manage positive and negative aspects of uncertainty and their possible different impacts for
AC
different teams, which may face different uncertainty types at certain stages in their projects and consequently employ different approaches. To systematically analyze the data, we began coding the interview transcripts by
assigning codes for different team based activities. Our initial coding scheme was influenced by our reading of the agile software development literature (e.g., it contained codes for prototyping, stakeholder integration, etc.). We extended the coding scheme whenever we
ACCEPTED MANUSCRIPT found practices that are not explicitly covered by agile methods (e.g., some practices for knowledge management, recruiting and onboarding of team members, etc.). To support the coding process, we used HyperResearch, a computer software for qualitative data analysis. We also relied on spreadsheets in order to record interim results and systematically organize emerging insights. To increase the reliability of the coding process, a
CR IP T
student researcher with experience in agile software development was involved in part of the data collection and data analysis. He was familiar with the research questions but not with our coding scheme, and coded part of the interview data independently from the authors. Comparing our results, we were able to validate our coding scheme to capture the practices
AN US
employed for managing different uncertainty types in the development teams. Differences between the student assistant‘s codes and our coding scheme were resolved in clarifying discussions with the first author until a common coding scheme displayed high congruity.
M
During this process, we were able to further refine our codes in order to capture more specific practices in the context of uncertainty management. For example, stakeholder
ED
integration was further detailed and split with regard to a) the content of communication (e.g., information exchange and clarification of issues) and b) temporal aspects (e.g., allowing
PT
change requests only at certain points in time). A list of our codes and practices, as well as
CE
principles derived from them is provided in Appendix B. While our coding scheme evolved to reflect different practices during our data
AC
analysis, we were not able to uniquely map practices to uncertainty types (some practices targeted more than one type of uncertainty). However, we created characteristics for each type to capture further details (e.g., requirements uncertainty carried sub-categories, or characteristics, for a) lack of information about demanded functionality, b) ambiguity, and c) unexpected changes.) We decided to proceed with the attempt to derive commonalities regarding uncertainty management practices, i.e. distinguishable strategies that address
ACCEPTED MANUSCRIPT different types of uncertainty. We were able to establish ten distinguishable practices, and grouped them according to their overarching objectives detailed below. What emerged were four principles, which span the ten practices.
4. STRATEGIES FOR THE MANAGEMENT OF UNCERTAINTY
CR IP T
We identified different uncertainty management practices applied by agile software development teams, and grouped them according to four general principles, which reflect the shared characteristics and the common focus that several practices share (e.g., the inspection and evaluation of feasible solutions). The principles were developed to structure the observed
AN US
practices based on their similarities in terms of objectives or involved activities. An overview is provided in Table 2. Some of the practices reflected the fact that teams organized their work in line with agile software development methods, which center on iterative and
M
incremental development. Teams combined different agile techniques to carry out different practices in order to meet specific demands of uncertainty management. All teams in our
ED
study faced several situations in which uncertainty emerged with regard to requirements, tasks, or resources. Sometimes these turned into opportunities, and sometimes they produced
AC
CE
detail below.
PT
threats. Teams employed different practices depending on the specific situation, which we
-----------------------------------Insert Table 2 about here ------------------------------------
ACCEPTED MANUSCRIPT
4.1 UNCERTAINTY ANTICIPATION 4.1.1 Planning with uncertainty The teams we studied engaged in frequent planning activities to produce just enough shortterm clarity and guidance regarding necessary steps toward a development goal, and tried to
CR IP T
accommodate for events that require a change of the produced plans as much as this was possible. Whereas such events could develop into impediments or opportunities, both cases require re-planning. Re-planning was, thus, a default option over which no team seemed surprised; they almost anticipated the possibility for produced plans to be short-lived: “[We
AN US
don’t] specify everything from the beginning and […] sometimes that business idea translates into something at the end that you wouldn't expect in the beginning, and it's often for the better,” (Product Owner, Team I).
M
In our data, the discovery of opportunities was most often related to newly arising business possibilities based on added functionality that was not included in the initial list of
ED
product features. For example, some teams realized opportunities based on change requests that became profitable only when cross-sold to other customers, which would not have been
PT
worth pursuing otherwise. Teams had to rely on their assessment of the market value for
CE
requested product features. This happened in Team G, which extended their product‘s functionality against specifications for the given software release after receiving a request for
AC
additional functionality by one of many customers. This altered the features initially intended for the subsequent product version, which were allocated to development iterations on an annual basis. In this case, betting on the change proved profitable. Yet it incorporated large uncertainties because the accuracy of effort and market value estimations was not known. In other words, it was unknown in the beginning if any potentially developed product feature,
ACCEPTED MANUSCRIPT including one discovered to provide new a business opportunity, turned out to be a threat to available resources, requiring more time or delivering less market value than expected. Without exception, teams often faced the pressure to react flexibly and adapt continuously. While team leaders emphasized adaptation more in business terms, team members tended to regard the need for adaptation regarding technical issues. Despite their
CR IP T
different perspectives, both stances caused them to remain open to alternatives that could either become necessary or more attractive. In one reported incident, a new customer approached the team manager of Team C with a feature request, which changed the market values of the planned features and reshuffled the priorities of the requirements list. Although
AN US
unexpected, the customer‘s demand increased the value of a feature that was low on the list of priorities and not expected to be completed within the year‘s software release. Developing of this feature was discovered to add value for other existing customers, and caused an
M
increase in the project‘s budget that the team or project leader had not expected initially. This example elucidates that it is important and desirable to be able to suspend decisions until
ED
more information becomes available. The pursuit of this emerging opportunity would not have existed if the scope of the product functionality had been specified unchangeably at the
CE
PT
outset of the development.
4.1.2 Developing vigilance
AC
Vigilance, a state of alertness to potential scenarios, emerged in our data as one of the most valuable assets in turning uncertainties into opportunities. Development teams need to remain alert to all types of potential uncertainties and their implications, as it is not clear in early stages of a project what a specific uncertainty may develop into. Teams summarized this as follows: “…throughout the year, there are, I would say, incidents, for example licensing
ACCEPTED MANUSCRIPT problems […] or positive events, they also occur. Like a project that has a change request, an add-on […which] also means, they bring money,” (Product Owner, Team G). In developing a mindset that is alert to technical and business opportunities, team members were vigilant to any shortcuts to the project goal. Sometimes, this required that the project goal be modified into a more profitable one. Oftentimes, this included substituting
CR IP T
originally planned product functionality by similar functionality. For example, one team decided to make changes to the design of the project setup; the original product was split in two parts upon realizing that it would be easier to work separately on different parts. Tasks were distributed between two sub-teams, who then realized that the separate product parts
AN US
they worked on needed some communication interface. While the separation of the project brought a number of uncertainties regarding requirements and resources, the team estimated it produced less task uncertainty. More importantly, this was turned into a business
M
opportunity that was discovered by the developers in the team: “when we split our projects up into different projects internally in the company, and we had to have an API [application
ED
programming interface] from one to the other, and so we found 'Well if we do it like this, we can sell the API, just the bare bones technical thing as a second product.' The developers
PT
thought of something and it turned into a product right away and we fond a customer [for
CE
it]” (developer, Team J). Here, an opportunity was realized when the separation of tasks led to the idea to offer added functionality not only internally, but also to offer it as added
AC
product value to existing and new customers. The vigilance developed by teams is important for the pursuit of opportunities, but it
is also important because it helped teams to manage threats proactively. For example, one developer described how she remained vigilant for threats when dealing with customer service requests: ―When someone sais: The server is down, then I can have a look myself and check if the server is really down and […] see if I can find out why it is down. Because this
ACCEPTED MANUSCRIPT shouldn’t be the case. Theses sort of things. But then it could be a user comes and sais he doesn’t have permission for something, but according to security I see all necessary rights, then this sounds rather like a bug to me, so I would take a look at that, what could cause that. But before I spend more than half an hour on that I say: OK, I can’t fix it myself, so I pass it on‖ (developer, Team M). Based on her experience, the developer gauged the possibility for
CR IP T
an error to be caused by a software bug that requires further attention. Her statement describes the importance to remain vigilant in order to distinguish minor problems from threats that will draw further resources.
AN US
4.2 INFORMATION ACCRUAL 4.2.1 Incremental feedback
Strongly influenced by the project management framework Scrum [66], teams followed a
M
number of principles that are geared toward dealing with requirements uncertainty. Frequent feedback from within the team, as well as from external project stakeholders on incremental
ED
development outcomes, was seen as very important. Teams developed specific communication practices for the giving and receiving of feedback, many of which relied on
PT
informal and ad-hoc conversations. In addition, teams structured much of their product
CE
specific feedback with the help of project tracking tools such as Jira, where progress was documented. A few teams invited their clients to access this documentation in an attempt to
AC
involve them closely in team-internal communication. Clients were linked to the team either through team leaders, or connected directly with developers who needed clients‘ input. Clients were mostly absent from team areas where developers worked, but were required to be present at meetings several times per month, and development teams demanded their daily availability via email and telephone. Developers sought feedback from their team members on a daily basis. They clarified technical details with co-workers and discussed requirements
ACCEPTED MANUSCRIPT with team leaders. One developer commented: ―you get a lot [of] earlier feedback [so] that you can react and […] adapt and discuss and change‖ (developer, Team K). Development iterations served as larger time frames within which developers of all teams could collect feedback on incremental improvements of the software product from external project stakeholders. As more information regarding requirements specifications and
CR IP T
possible solutions accumulated over time, uncertainty remained latent as either threat or opportunity, and was subsequently subjected to strategic action: “...we stop time and again and look together with the client: what did we do? What else do we need to do? Are we on the right track? Then we continue, step by step‖ (developer, Team A).
AN US
Most of the teams seemed to invite rather than disapprove of customer change requests, which were explicitly encouraged as long as they were brought forward in the time between two development iterations, or otherwise buffered through product backlogs, which
M
were maintained to permit work without interruptions during development iterations. Using short development iterations was viewed as beneficial as it allowed team members to collect
ED
feedback more frequently, and thus enabled them to accrue additional information to reduce uncertainty: “At some point we had like a change in the requirements, which was pretty
PT
disruptive and we had to recalculate our requirements, [and repeat] the Sprint [iteration].
CE
This shouldn't happen of course. [...] having the shorter iterations helps you with doing that“
AC
(developer, Team J).
4.2.2 Team based task analysis
Software developers often faced situations in which they were not sure about how to solve a technical problem due to, for example, ill-defined problems or a developer lacking experience with regard to the used technology. We found that teams faced many situations in which it was unclear whether a particular envisioned solution would be feasible. Teams
ACCEPTED MANUSCRIPT performed collective meetings to further investigate the task at hand, in order to acquire the required insight for a meaningful decision-making process about how to proceed. Oftentimes two or more team members were delegated to these task investigations, depending on their knowledge and experience. They jointly investigated for a fixed duration of time, ―[…] to create more knowledge, so that we can estimate [the task size] more comfortably. It’s
CR IP T
important that it is time-boxed. For example, that we take four hours, and then we stop. Because with these investigations you can burn days. But that doesn’t get you anywhere. You have to time-box them; that’s an important point.‖ (Scrum coach, Team F).
This pooling of resources in order to investigate possible solutions had the effect that
AN US
the teams would eventually come to know not only how to proceed, but also how much effort a certain task might require. Estimations of task sizes, which were almost always performed collectively by the entire teams, were mentioned as the single most important practice
M
regarding the reduction of task uncertainty. Some teams held special meetings dedicated to the estimation of batches of tasks, and usually pooled knowledge from several developers in
ED
an attempt to reach more accurate estimates. All of the teams performed estimation meetings not only at the start of each iteration, but they also spent much time on corrections of task
PT
size estimations whenever they acquired new information. This accrual of information in an
basis.
CE
iterative fashion enabled teams to apply changes to the development project on a continuous
AC
While the accuracy of estimations benefitted from the involvement of several team
members, the downside was that more time needed to be spent on estimations. Although teams tried to limit the duration of estimation meetings, developers were troubled when regularly exceeding these limits: “[the estimation meeting] should take one hour [but] everything is so unclear, it's gonna take two hours, two and a half hours, and that always annoys me‖ (developer, Team J).
ACCEPTED MANUSCRIPT Some teams sided with conservative estimates to buffer uncertainty, as it became clear that task sizes could turn out to differ starkly from original estimations. One developer explained: “most of the time we try to be a bit more generous in terms of how much time we estimate so that we are sure that we’re not going to need more time” (developer, Team C). Sometimes the actually required effort dropped by magnitudes when developers found
CR IP T
elegant solutions to problems that were initially expected to be much more complex. In these cases, conservative estimations yielded unexpected benefits in the form of saved resources. However, the opposite can occur as well when the complexity of a task is underestimated. In one incident, a team experienced a case where the initial task size estimation had to be
AN US
tremendously corrected upwards repeatedly as unexpected dependencies were discovered. Eventually the task size grew three times larger than its original estimate, requiring the attention of a sub-team of four developers instead of a single person. In this case, task
M
uncertainty developed into a real threat that imposed vast unexpected costs. To manage task uncertainty, teams learned to keep task sizes as small as possible in attempts to contain
ED
negative consequences. In addition, splitting up tasks to smaller ones increased the precision
4.2.3 Knowledge sharing
CE
PT
of estimations and reduced the necessity for revising them.
Structures for knowledge sharing were employed in all teams. They supported the
AC
management of resource uncertainty and made workflows more robust. Teams with broad ranges of tasks and high degrees of specialization felt that their diversely distributed expertise hampered collaboration practices such as task analysis and effort estimation. To counteract this, they strove to foster the systematic sharing of knowledge regarding different aspects such as employed technologies or decisions about solutions to problems. On the one hand, this included knowledge about task specifications: “we discussed [the tasks] and tried to
ACCEPTED MANUSCRIPT formulate them as precisely as possible so that everybody had the same understanding” (developer, Team F). On the other hand, most teams reported to strive for the maintenance of shared capabilities to enable the continuation of work based on developers‘ independence: “what if, when I am sick, for example or I leave the company or I change roles. [We wanted to]
CR IP T
separate the task from the person in order to create a pool with all the knowledge” (developer, Team H).
A number of teams conducted regular knowledge exchange meetings, for instance in the form of mini seminars on current technology use. Pair programming techniques, i.e. the
AN US
employment of two developers per computer who work in collaboration on a single task in order to learn from each other and increase code quality, was used extensively in one team. After the completion of a task, pairs were regularly broken up and recomposed with different
M
team members so that task specific knowledge would spread through the entire team.
ED
4.3 SOLUTION INSPECTION 4.3.1 Prototyping
PT
Prototyping was much valued in all teams, because it helped to focus on important product
CE
features and reassures developers. Addressing the threat of inefficient resource deployment toward features deviating from the customers‘ vision, the use of early prototyping supported
AC
the exploration of options while focusing discussions with customers on functionality. At the same time, prototyping was described to us as an important instrument for the exploration of opportunities, because it stimulates meaningful customer feedback. One team manager explained: “So from this meeting we were able to somehow come up with a prototype, just because we wanted to test the feasibility of some solutions [...] we wanted to actually test and see if some ideas might be realized or not. So this was the intent of the prototype, then we
ACCEPTED MANUSCRIPT used it also to convince the sponsor. [...]people start to imagine how they can do business with that and then they'll give you much more input, and much more concrete" (Product Owner, Team C). Prototyping, thus, is an important information device for team members as well as stakeholders other than developers. However, there are also drawbacks of early prototyping, which are linked to the
CR IP T
communication of functionality. A prototype is by definition a preliminary version that is inferior to the envisioned product feature. While prototypes provide customers with a better understanding for the development in progress, they trigger early feedback and facilitate decision-making. This worked well when the development team and its customers had a
AN US
shared vision of the final product. When the developers envisioned a technical solution that could not be fully expressed and represented in a prototype, the benefits of early feedback broke down. In one situation, team A experienced a situation in which developers saw future
M
product flexibility threatened by implementing features they had discussed with their customer. They argued for changes in the product architecture, which were costly, but would
ED
allow – in their view – improved opportunities for future development. They were not able to convince the customer, who did not see the benefit and did not approve of the extra cost. The
PT
developers then decided to push ahead their solution at their own cost, risking that the extra
CE
hours would not be paid eventually. After implementing a prototype of the suggested solution, the team was eventually able to convince the customer of the benefit, which had
AC
previously been impossible. A developer noted that one needs to have more time to experiment on one‘s own, an activity which was not provided for during the short development iterations. Eventually, the team was successful in convincing the customer to cover their extra cost, which they had been prepared to accept at their own risk. Prototyping, in this example, favored short-term customer orientation that was detrimental to product quality in the long run.
ACCEPTED MANUSCRIPT 4.3.2 Creating alternatives The deliberate pursuit of solutions that are later abandoned can lead to significant advantage. Pursuing multiple solutions simultaneously served software developers to increase flexibility and offered possibilities to defer decisions regarding which option to exclude and which one to keep developing to later points in time: “we had in fact two strategies or two options in
CR IP T
mind from a technical point of view, which we were able to go and the one we decided for was so far the right solution. […] It's ... you're more flexible, you can be more innovative” (developer, Team K). In this case, an opportunity could be realized when the option that turned out as inferior was abandoned at the cost of having started development of both in
AN US
order to keep options open. However, this strategy, as well as the reliance on task backlogs to avoid developer idleness required redundancies of skills within the team to some extent. It also required the ability to transfer available tasks to the next free developer, which must be
M
preceded by adequate knowledge of production and product details despite high levels of complexity.
ED
Developers, therefore, need high levels of freedom to explore as well as adequate tools allowing them to convince customers of deviations from original plans. This can be
PT
beneficial when different technical solutions are more feasible to realize or more readily
CE
accessible. Developers from Team A explained their frustration after failing to agree with a customer representative to a deviation from a technical solution. Several members of the
AC
team had grown convinced that an alternative solution would be superior, but they failed to convince their customer until they produced a prototype at their own cost and concluded “sometimes it’s difficult to convince the customer if you can’t show them something” (developer, Team A). The example highlights the importance of trust in ones abilities and the development of intuition in order to spot opportunities. Risk taking and failure tolerance, thus, play an important role for the exploration that permits opportunities. Teams not only
ACCEPTED MANUSCRIPT need to tolerate uncertainty and its potential drawbacks, but also operate in environments that provide the psychological safety and team support necessary for effective uncertainty management. This becomes clear from the statement of a developer describing his trust in the team‘s ability to solve any type of problem without necessarily knowing how in the beginning: “I've never been involved in something that failed so drastically that we didn't
CR IP T
find a solution to it […] there has never been a problem that has actually amounted to become something. It's quite funny, because when I think about it there's always, we always somehow find [a solution], you know, whether it's a workaround, or it may just be fixing the symptom, but not the real root cause. We've still somehow always managed” (developer,
AN US
team I).
4.4 ROLE-BASED COORDINATION
M
4.4.1 Creating functional roles
In processes that draw on consensus-based decision-making, agile software development
ED
teams create their tasks as well as their roles in a self-organizing manner. Although advised by agile methods to abandon functional roles, the teams we studied created roles upon
PT
realizing the need for them. For example, when recurring customer calls regularly interrupted
CE
the development work, a role-based solution implemented by a team included the handling of all calls through a new customer service role, the occupants of which rotated on a bi-weekly
AC
basis. Other roles were temporally limited, such as when an emergency task required the formation of a sub-team with an explicit leadership role, which was retired upon returning to non-emergency development work. Yet other roles were created not in reaction to events, but in anticipation of problems or aspiration of uninterrupted development work, e.g., through a rotating but permanent role for specific aspects of project documentation.
ACCEPTED MANUSCRIPT Some teams used practices to concentrate tasks of a similar uncertain nature to dedicated functional roles within the project. For example, Team G faced regular service requests from a large number of customers, which could mean anything between 20 minutes and several days of work depending on the reported issue. After observing the insufficient coordination with which the team was dealing with incoming customer requests, it was
CR IP T
decided that one person would be responsible for all requests on a bi-weekly rotation scheme. As a consequence, participants reported that everybody else on the team could follow their work plan without interruptions, thus, not facing the uncertainty of having emergencies require the complete reorganization of their daily tasks.
AN US
As much as the freedom to design and re-design roles can increase efficiency, it also bears the potential for conflict. For example, development teams in larger companies were challenged to adopt team role structures inherent in agile development methods. The
M
guidelines of agile methods instruct teams to abandon job titles in an attempt to facilitate shared responsibility and flat hierarchies that support collaboration. However, bureaucratic
ED
structures in large companies preserved pre-existing job titles (such as ‗solution architect‘ or ‗requirements engineer‘) based on unique specializations of team members. Role creation
PT
became an exercise in combining both structures. As a result, many of the created roles were
CE
either tailored to specific types of team members or designed to exclude team members from taking a role in order to preserve scarce team capacities for critical development work.
AC
In the face of uncertainties that required decision-making, teams referred to informal
leadership structures based on the roles they had created. The occupation of leadership roles depended strongly on a team member‘s tenure, as well as their expertise related to the project. In shared decision-making processes, the opinions of team members with specific knowledge, for example regarding specific market environments, customers, or technologies, received more weight than the opinions of less experienced team members. Senior team members
ACCEPTED MANUSCRIPT were assigned leadership roles sometimes without seeking or even accepting them. One developer complained: “I have been with the team for a long time now. For me now the pressure increased, because I should take the role, even though I don’t know everything. I am not the same person [as the senior colleague who had just left]. So for me the pressure has increased, because many questions come to me, and I am expected to make more decisions,
CR IP T
you know” (developer, Team B).
While the establishment of roles aims at enabling agility through decoupling work tasks from individuals, change can be undermined when the system becomes inert and roles do not lend themselves to temporality. This means that some roles, once created, are sticky,
AN US
i. e. difficult to retire and decouple from individuals who have acquired specialized knowledge through filling them. Our data show that individuals regularly had difficulties resigning from a role for various reasons such as specialization, trust, or conscientiousness.
M
For example, one developer from team G who was no longer occupying the rotating customer service role explained that customers still approached her even months later in the role she no
ED
longer occupied, because she used to be most familiar with their issues and customers refused to approach the current role occupant: “[they] often come to me because they know me, but
PT
they could as well write to the mailbox. […] I was just the one who happened to know them
CE
best and who also knew the problem best, so I still end up doing it even it’s not part of my job any longer” (developer, Team G).
AC
High degrees of specialization and expert knowledge did impede team members in all
teams from switching roles under certain circumstances, for example when the familiarization with a new technology or business context created barriers. In several cases, team members reported that they continued performing the tasks of a role they formerly occupied for reasons of team and external stakeholder convenience. Personal bonds also
ACCEPTED MANUSCRIPT made it difficult to discard a role, especially when trust was formed between external stakeholders, such as suppliers and customers and the contact persons within the team. Another reason for the stickiness of roles was that team members felt responsible for their work and tended to maintain caring for its proper execution out of conscientiousness. For example, team members who had been formerly responsible for the facilitation of a
officially handed over responsibility to their successors.
CR IP T
project planning meeting kept attending subsequent planning meetings after they had
Given the implicit and sometimes uninvited assignment of roles, as well as the stickiness of roles, developers faced challenges regarding role related coordination activities.
AN US
While role structures were created to support uncertainty management, these challenges threatened to inhibit flexibility and thus impede uncertainty management.
M
4.4.2 Stakeholder integration
Project teams tried to manage requirements uncertainty especially with regard to changes or
ED
ambiguities threatening to cause more work through integrating diverse stakeholders closely into the software development process. All teams engaged in frequent communication with
PT
stakeholders, which was perceived to significantly improve decision-making. To some extent,
CE
this shifted responsibility, e.g. for product design decisions, away from the development team and toward clients. For instance, a developer noted: “in the old [non-agile development] style
AC
waterfall system, you get a screenshot, you implement it, you don't understand it directly, you just do what's on the screenshot, and afterwards the customer says 'Well, that's not what I like'” (developer, Team K). In contrast to this practice, some of the teams integrated clients to a degree where work would not continue as long as no decision was made to resolve requirements uncertainties, thus eliminating the threat of investing effort in the development of unapproved details: “we have a lot of external dependencies. There are many [tasks] we
ACCEPTED MANUSCRIPT cannot continue because we just need to clarify. So I have to ask: is that correct that way? Or how is the status? And inquire a bit and […] communication, a lot of communication, that’s what I mean” (developer, Team B). Most teams desired direct contact between developers and external stakeholders, especially customers. At the same time, this created tensions that were described as
CR IP T
unwelcome dependencies. Acknowledging the necessity for frequent contact with stakeholders, these dependencies were seen as necessary on the one hand, but detrimental to efficiency on the other, which tended to trouble teams. Attempts to resolve them resulted in a negotiation between adopting external parties‘ schedules and working styles, and imposing
AN US
the team‘s schedules and working styles on stakeholders. One team, for example, persuaded several of their clients to adopt the planning board that plays a central role in their work in order to synchronize and discuss future tasks. Others shared access to online collaboration
M
tools with their clients. In our data, there was a lot of complaint that suppliers that were not ‗agile‘ did not understand the timing of events and the role of iteration cycles, which
ED
prescribed frequent deadlines. The importance of adhering to them could not always be communicated clearly and was ignored by suppliers, threatening to disrupt project schedules
PT
and the pace of development work. As a remedy, teams strove to establish very close
AC
CE
integration of project stakeholders.
4.4.3 Task switching
Switching from a current task to another, or taking over a task from a colleague let teams uphold development work when interruptions occurred. Technical difficulties and workflow disruptions were frequently experienced when input was not available from external project stakeholders, e.g., when deliveries of work from contractors or suppliers were late or were not of sufficient quality so that they needed clarification or rework. One developer noted the
ACCEPTED MANUSCRIPT importance of a task backlog that holds additional items to be completed during a development iteration to which one can return in order to avoid idleness when waiting: ―I mean that almost always occurs in any project, that you need to wait for something. I mean, otherwise everything is planned, I mean, that doesn't happen that everything is planned out in a way that you don't need to wait […] it happens really all the time in the best projects. In the
CR IP T
worst projects, it's, it just happens a lot more and basically I think the trick for fixing that is just to have ... be open minded enough to work on something else and not get yourself ... be stopped in the process, I mean, ... But of course you need to have a backlog ... that's actionable to some degree and makes sense― (developer, Team I). Another developer
AN US
described how, if switching to another task while awaiting specific information is not possible, inefficiencies and re-work may result: ―we couldn't get information about the error handling, if there was a false input, how to react. So I had the uncertainty that I have to...
M
should I throw an exception and stop everything or should I return null values, I don't know, and I couldn't get the information from the customer. So I had to choose one, one way, and of
ED
course it was the wrong one (laughs) and I had to change it later‖ (developer, Team K). The importance of managing task uncertainty and task interdependencies surfaced
PT
particularly in situations, when task switching was difficult. One team reported experiencing
CE
the threat that developers became idle because of the team‘s dependency on database specialists within their company. The specialists repeatedly failed to deliver what the team
AC
ordered. In particular, lack of requested infrastructure threatened to delay the project several times. The problem was linked to the fact that there was not one individual in the database team responsible, but each time the next available employee processed incoming requests. The team leader negotiated a proposal with the database department according to which one database administrator would be integrated in his project team. This had the effect of creating of a novel business model; henceforth database specialists could be hired individually by
ACCEPTED MANUSCRIPT development teams to process their entire requests. This supported more effective communication and the elimination of misunderstood requests, as one specialist processed all requests. It also allowed turning a threat into the opportunity of improving the production
5. DISCUSSION
CR IP T
process by a newly created customized service.
In this study, we emphasize that two important and desirable outcomes of uncertainty management are mitigating threats and fostering opportunities. Detailing different approaches available toward these ends, we investigate software development team practices. In our
AN US
study, we deliberately focus on agile software development teams, which are increasingly employed in settings characterized by environmental turbulence. The underlying rationale is the organizational attempt to provide the necessary flexibility to react quickly and adequately
M
to diverse sources of change. Agile teams employ practices that are starkly inspired or directly derived from different software development methods. Yet, not all agile software
ED
development methods support addressing uncertainties equally well, and many only do implicitly so [28]. Teams must approach uncertainties using practices that are simultaneously
PT
informed by several, complementary agile software development methods. This is
CE
problematic especially with regard to supporting the management of opportunities, which is not explicitly addressed. For example, while agile methods provide structures that support the
AC
ability to respond to potential threats by fostering capabilities for collaborating with customers,
iterative
work,
team
learning,
and
software
development
process
improvement[77], agile methods do not equip teams with regard to cultivating and reaping beneficial outcomes [28]. In line with Fitzgerald et al. [78], we find that agile methods are individually incomplete in their support of product innovation, which depends on the systematic pursuit of opportunities. Practitioners have to rely on the combination of practices
ACCEPTED MANUSCRIPT from different methods such as Scrum, Kanban and XP, which invites confusion. Hence, it would be advisable for teams to draw upon the very possibilities embedded in iteration-based process inspection and adaptation, which is core to agile methods, to integrate further techniques in a self-directed way to respond to team and project needs. While it is arguably difficult to establish systematic practices to foster innovation, agile teams command qualities
CR IP T
that may be well suited to inform strategic project decisions, which we will detail below. Presenting examples for approaching uncertainties that assume both the possibilities for positive and negative implications, we document the benefits and challenges of practices employed by software development teams. Our results include ten practices (see Table 2) that
AN US
span four overarching principles; 1) uncertainty anticipation, which relates to the attempt to prepare for different possible scenarios regarding the future development of uncertainties and remain vigilant to profit from opportunities; 2) information accrual, which is strongly
M
influenced by the incremental working style of agile methodology, and speaks directly to uncertainty management, as uncertainty can only gradually be developed into opportunity or
ED
become unmasked as threat; 3) the frequent evaluation and inspection of solutions, which in our data increased the efficiency of discussions on multiple possible solutions and provided a
PT
basis for discussions among developers and customers, and 4) role-based coordination, which
CE
integrates team members and external project stakeholders on the basis of practices for establishing temporary, dynamic, and de-individualized roles to accomplish tasks. Many of
AC
the practices used by teams to manage uncertainty are directly influenced by suggestions that stem from different agile development methods, most prominently Scrum (on the project level) and XP (regarding programming techniques). We have included an overview of these influences in Table 2. Our findings show how some of these practices need to be established by development teams in order to complement agile development methods.
ACCEPTED MANUSCRIPT 5.1 PROACTIVELY MANAGING DIFFERENT TYPES OF UNCERTAINTY The four principles that our study identifies and details govern practices that function conjointly to provide teams with guidance in terms of effectively managing different types of uncertainty. In particular, the iterative development approach that agile methods entail is especially suited to address requirements uncertainty [48, 59]. Similarly, the step-wise
CR IP T
information accrual of development iterations is supportive for determining mismatches between required and available resources, hence, to mitigate resource uncertainty. For example, estimations of resource availability are an important input for the planning of development increments in Scrum. Further, solution inspection that entails the option to delay
AN US
decisions carries potential for the management of task uncertainty, which pertains to aspects of technologies employed. The underlying practices for estimating required effort are derived from a technique called Planning Poker, as well as from the practices of prototyping and
M
customer integration that are suggested by different agile methods [79, 80]. Striving to accomplish small tasks in an iterative fashion and integrating customer feedback on
ED
prototypes supported the management of requirement uncertainty, while distributing tasks across several roles often resulted in opportunities to create supplementary product features
PT
with better insight into technologies and market environments.
CE
Opportunity recognition is, unfortunately, left to the initiative of individual developers. While this is common in innovation settings [81], we argue that agile
AC
development teams command practices which could permit them to explore opportunities much more systematically by seizing their team-based approaches similarly to the way in which they manage threats. One important step in this direction could be the establishment of a backlog for opportunities in which options are recorded based on input from all team members in a regular fashion based on the discussion of possible strategies. Their potential market value could be estimated making use of cross-functionality, i.e. drawing upon
ACCEPTED MANUSCRIPT technological and business expertise of the teams. In this process, all developers should participate in order to reap their cumulated expertise regarding the product and systematically explore potential opportunities. While agile development teams have excellent decisionmaking capacity, Drury and colleagues argue that this capacity is, however, usually not employed to arrive at better strategic decisions, but rather to mitigate requirement uncertainty
CR IP T
[54]. Employing similar techniques for the search of novelty might provide companies strongly enhanced innovative capacity by addressing opportunities.
Toward this goal, considering different types of uncertainty and their potential positive versus negative development is vital. We would like to stress that differences in the
AN US
types of uncertainty can exist with regard to many aspects. Teams are likely to encounter further nuances in the different types we have investigated. For example, requirement uncertainty can stem from volatility of product features, or from a lack of information about
M
the truly required feature a customer needs, both of which may demand different approaches and different combinations of practices for their management, such as prototyping or the
ED
delay of decisions through the creation of alternative solutions. Teams are required to examine uncertainties closely with regard to the project context and situation they are in
PT
before deciding on adequate reactions.
CE
Ignoring the difference between uncertainties leading to threat versus uncertainties leading to opportunity decreases innovative potential and gives rise to a fixation on threat.
AC
While we do not intend to say that threats should be accepted or ignored, we extend a warning regarding the premature elimination of related uncertainties. Threat mitigation, for example, in the form of avoiding costly investments into later changing product requirements, is very important. Yet, there are situations in which design changes even at late stages in the development cycle can carry benefits [82]. Potential benefits of accepting uncertainty or even increasing uncertainty may carry important aspects for teams [7, 83].
ACCEPTED MANUSCRIPT According to the decision-making literature, team members tend to value uncertainty more than their superiors who often fail to see the benefits of remaining open to alternative solutions [54]. In line with these findings, we warn that decreasing flexibility in favor of a focus on control (minimizing uncertainty) implies the cost of forgone opportunities. Our analysis suggests that skepticism toward uncertainty dominates even in agile software
CR IP T
development settings, where we would expect to see teams rely on the exploitation of opportunities to innovate. We find that some developers are alert to opportunities, but most are more alert to threats – above all the threat of failing to meet rapidly changing market demands.
AN US
Given that most developers we interviewed associated uncertainty with threats, while team and project leaders were generally more open to associate opportunities with uncertainty, our concern is that much potential for opportunity realization remains unrealized.
M
This finding is in line with observations by Austin and colleagues [20], which illustrate the skew toward cost-driven, as opposed to opportunity-seeking, behavior of product developers.
ED
Whereas the types of behavior we have witnessed may be influenced by individual preferences regarding uncertainty avoidance versus uncertainty tolerance, we see a need for
PT
teams to create structures that incentivize exploratory activities while shielding opportunity
CE
explorers from detrimental outcomes. Leadership researchers point to the effectiveness of rewards for opportunity seeking behavior [84], although this may be challenging in the face
AC
of hierarchical structures (or rather, their absence) observed in agile teams.
5.2 THREATS AND OPPORTUNITIES IN SELF-MANAGING TEAMS
Agile software development teams rely on high levels of autonomy [85]. This has implications for the way in which they approach uncertainty. When left without clear guiding structures, their choice regarding how to deal with uncertainty becomes an uncertainty itself.
ACCEPTED MANUSCRIPT Extending earlier accounts in which teams establish structures in the form of role-based coordination [86], our findings document a dynamic system of de-individualized roles in software development. Agile software developers create role-based team structures to support their development work. Dynamic functional roles (i. e., changing informal within-team job descriptions) were used by scrutinizing the creation, modification and maintenance of team
CR IP T
member roles in support of adaptation to varying and unstable project goals. There are several ways in which dynamic role allocation influences how teams approach uncertainty. In contrast to work environments with standardized output, the goals of agile software development projects are neither known at the outset, nor stable; they emerge slowly and are
AN US
subject to frequent variation. As a result, development teams continuously aim to forge their supportive organizational structures by tailoring functional roles to match the development project‘s dynamic requirements. The dynamism of organizational structures results directly
M
from the creation and retirement of roles for specific work tasks, which are fundamentally different from each other, for example, in terms of managerial stint or temporal nature.
ED
When teams are able to employ dynamic roles, they can increase team efficiency by intelligently allocating individual capacities. Our results contain several examples for
PT
situations in which teams reap the benefits of dynamic role-based team structures, however,
CE
we also note some of the drawbacks. Specifically, the stickiness of roles (i.e., the difficulty that occurs when switching or retiring a role) holds potentially detrimental implications for
AC
teams in situations where roles are intended to be dynamic, but this is undermined by established team structures. When roles are intended to be dynamic and flexible by design, but do not conform to this characteristic in practice, teams will be hindered in their productivity and use their resources inefficiently. Recognizing specific characteristics of such inefficiencies may equip teams with the potential to act upon them. For example, it seems that role-based coordination issues can go unnoticed because individuals are not aware of
ACCEPTED MANUSCRIPT their systematic occurrence, while their mere discussion within teams would initiate possible solution strategies.
5.3 LIMITATIONS OF THE STUDY
CR IP T
While seizing the opportunities that qualitative methods offer, our research approach carries limitations that are connected to sample size and difficulties regarding the generalizability of findings. In particular, we draw on observations and interviews with a limited number of agile software development teams in the Swiss software industry. Differences in the lengths
AN US
of interviews that were conducted result in part from our aim to include more team members in larger teams, and allocate more interview time to participants in smaller teams so as to collect all relevant perspectives and validate experiences across team participants where
M
possible. An important limitation refers to the fact that agile software development teams operate under special conditions; for example with regard to decision latitude and team
ED
autonomy. Although agile practices are gaining increasing popularity far beyond softwaredeveloping teams, the conditions in which these teams operate carry implications for the
PT
generalizability of our findings to different contexts. We strove to mitigate limitations by
CE
methodologically triangulating data from several diverse companies that operate globally. This increases our confidence that our sample is representative for research and development
AC
contexts spanning the wider software industry. To our support, Smith [80] notes that software development projects in general share important characteristics with agile projects, such as low prototyping costs and opportunities to modularize products. In addition, the management of uncertainty plays a vital role in projects across a variety of industries and organizational settings [12, 87, 88], and the implications of our results may be applicable beyond agile software development projects.
ACCEPTED MANUSCRIPT
5.4 IMPLICATIONS FOR INDUSTRY The importance of risk and uncertainty in software development projects is undeniable and reflected by the large number of risk management frameworks that have been proposed. Yet, critics note that no framework has become a generally accepted standard [89], nor been
CR IP T
integrated well into development projects [4]. For example, the most widely adopted methods for agile software development, Scrum and XP, do not explicitly mention the management of risk or uncertainty [28]. The result is a lack of formal guidance for practitioners, which needs to be compensated by experience based practices [90].
AN US
In this study, we investigate principles and practices that may mitigate the guidance gap, first, by broadening the notion of risk management and shifting the focus toward uncertainty, and second, by introducing a language that permits the connection of practices
M
from different agile methods using the universally applicable concept of uncertainty. We highlight several distinct types of uncertainty. Based on our empirical results, we suggest that
ED
practitioners should not only acknowledge these differences but also consider diverse options to approach them. Systematic and continuous attention to uncertainties should best be
PT
structured along the different categories of uncertainty in order to support teams in
CE
determining adequate responses. This does not mean the early elimination of uncertainty, as we have repeatedly stressed. Opportunity management depends on being open to unexpected
AC
events [20], therefore a project‘s diverse sources of uncertainty should be iteratively and systematically analyzed and evaluated. Developing vigilance in spotting opportunities supports this. To derive innovation
regarding technical solutions as well as their commercialization, companies should seize the creative capital of each individual software development team member. Incentivizing and rewarding vigilance and opportunity-seeking practices could increase awareness among
ACCEPTED MANUSCRIPT developers and produce and sustain team performance. Our results highlight the necessary cross-disciplinary knowledge to foster individual team members to pursue opportunities. Companies should aim to cultivate vigilance and include it in their formulation of ‗agile values‘ such as autonomy. On a similar note, companies should aim to seize the collective capacity of agile teams not only with regard to solving technical problems, but also with
CR IP T
regard to informing strategic project decisions aimed at opportunity management. While Surowiecki [91] notes that under certain circumstances teams will make better decisions than individuals, their potential for strategically relevant project decisions in agile teams seems to remain largely untapped.
AN US
As the concept of uncertainty carries a negative connotation among practitioners, teams are at risk to dismiss hidden opportunities by attempts to eliminating uncertainties instead of coping with them. At the same time, existing approaches to uncertainty or risk
M
management may fail to uncover opportunities for similar reasons; many risk management frameworks are designed with the mitigation of negative events in mind. In order to profit
ED
from unexpected events, a change in perceptions that extends uncertainty to include opportunity is strongly advised. We propose that communication practices in agile
PT
development be extended to include the presented notion of uncertainty management, which
CE
can be structured along the types of uncertainty we identified. Team members should aim to integrate the sharing of incrementally collected information in existing communication
AC
structures to uncover uncertainty‘s positive or negative developments. A structured approach, as opposed to practices left to be carried out only by mindful team members, is more likely to improve uncertainty management practices and help practitioners in identifying threats and opportunities earlier. Learning and information sharing, which are crucial for this, are already fostered by agile development methods. These need to be extended by a shift to exploratory activities beyond technological solutions, and complemented by the systematic search for
ACCEPTED MANUSCRIPT opportunities. Whereas the literature documents failures to systematically approach risk and uncertainty management [92], our analysis stresses the importance of collecting information systematically and in combination with further practices that enable teams to reap benefits while preventing potentially detrimental developments.
CR IP T
5.5 IMPLICATIONS FOR RESEARCH
Different implications for scholars of uncertainty can be derived. Researchers should not only follow calls to look beyond risk and consider uncertainty management as important source of insight [33], as well as acknowledge the existence of different types of uncertainty to increase
AN US
investigations of beneficial uncertainties, which have often been ignored in the risk management literature. Considering that uncertainty affects projects in different ways [93], it is advisable that future work addresses the conditions under which different types of
M
uncertainty become manageable for development teams. For example, it is not clearly understood if the possibility for opportunities can be categorically excluded for some cases,
ED
which would allow different conditions for the mitigation of threats. While the focus of our study was on agile software development teams, practices for handling threats and
PT
opportunities may be affected by different challenges in other settings, such as traditional
CE
development projects or different types of product development. While our aim was to point to the consideration of distinct uncertainty types and their potentially different consequences,
AC
continuing this line of research in further settings will certainly yield important insight for the product development literature. Another important aspect to extend our understanding is the consideration of
individual differences such as risk attitudes that influence the behavior of actors. These aspects should be addressed in future studies. Grote [30, p. 48] suggests that the potential for uncertainty management in organizations is related to the ―belief systems held by
ACCEPTED MANUSCRIPT occupational groups and the belief systems developed in the companies themselves, that is, company culture.‖ While the complexity of the uncertainty concept has the potential to deter researchers and practitioners, it is a powerful lever of beneficial impacts on development
6. CONCLUSION
CR IP T
projects and deserves increased attention.
Like the ancient Roman god Janus, uncertainty has two faces. One is beneficial whereas the other is malign. In this paper, we empirically explore how agile software development teams deal with uncertainty, i. e. in situations in which they have incomplete information, in order
AN US
to reap opportunities and avoid threats resulting from it. We present work that explicitly continues to move the study of risk beyond the focus on threats by including potential benefits from uncertainty.
M
Our findings detail practices to approach different types of uncertainty (regarding resources, task, and requirements), which allow teams to mitigate threats while remaining
ED
alert to unanticipated opportunities. Many of these practices are informed or directly derived from agile software development methods, yet by delineating their effects through the lens of
PT
uncertainty our description takes a conceptual approach that extends beyond the scope of
CE
individual established methods such as Scrum and XP. Importantly, while most of the software development literature has viewed uncertainty in a negative light [94], we
AC
emphasize that uncertainties may develop into beneficial opportunities. For example, development teams complemented agile methods by practices for role-based coordination and opportunity management. While agile practices are helpful in supporting software developers to address uncertainty, their emphasis on opportunity and, ultimately, innovation is not as pronounced as their capabilities for the mitigation of threats. This provides a
ACCEPTED MANUSCRIPT promising avenue for the improvement of agile methods, which is even actively encouraged by their very values. Many of the practices we detail were performed simultaneously or in a periodically recurring fashion following four overarching principles for addressing uncertainty. Incorporating the possibility for unexpected events led development teams to reckon with
CR IP T
changes especially with regard to requirements and availabilities of resources. Through frequent probing and re-planning, teams were able to elaborate most adequate tasks and mitigate many negative consequences, for example, with regard to avoiding ineffective work. At the same time, some developers displayed the vigilance to remain alert to potential
AN US
opportunities stemming from the same sources of change, which often resulted in benefits for their teams.
We hope that these findings will guide teams in software development projects and in
M
new product development projects in general, which face difficulty in the discernment of
ED
uncertainty as threat and opportunity.
ACKNOWLEDGEMENTS
PT
The authors declare no conflict of interest. We wish to thank the participants of our study for
CE
their time and effort, and are extremely grateful for their support and valuable comments. An early version of this paper was presented as a short paper at the 16th International Conference
AC
on Agile Software Development (XP2015), which reports on preliminary work at a previous stage in the research process. We are grateful to the conference participants and in particular to Torgeir Dingsoyr, Alan Moran and Nancy Van Schooenderwoert for their valuable feedback and suggestions for revisions. We wish to express our sincere gratitude to our anonymous reviewers for their extremely helpful, supportive and constructive suggestions.
ACCEPTED MANUSCRIPT REFERENCES
[7] [8] [9] [10] [11] [12] [13] [14]
AC
[15] [16]
CR IP T
[6]
AN US
[5]
M
[4]
ED
[3]
PT
[2]
F. H. Knight, Risk, Uncertainty and Profit. Chicago: University of Chicago Press, 1921. S. Nidumolu, ―A comparison of the structural contingency and risk-based perspectives on coordination in software-development projects,‖ Journal of Management Information Systems, vol. 13, no. 2, pp. 77–113, 1996. K. S. Na, X. Li, J. T. Simpson, and K. Y. Kim, ―Uncertainty profile and software project performance: A cross-national comparison,‖ Journal of Systems and Software, 2004. S. Islam, H. Mouratidis, and E. R. Weippl, ―An empirical study on the implementation and evaluation of a goal-driven software development risk management model,‖ Information and Software Technology, vol. 56, no. 2, pp. 117– 133, Feb. 2014. H. Ibrahim, B. H. Far, A. Eberlein, and Y. Daradkeh, ―Uncertainty management in software engineering: Past, present, and future,‖ presented at the 2009 Canadian Conference on Electrical and Computer Engineering (CCECE), 2009, pp. 7–12. I. Stamelos and L. Angelis, ―Managing uncertainty in project portfolio cost estimation,‖ Information and Software Technology, vol. 43, no. 13, pp. 759–768, 2001. G. Grote, ―Promoting safety by increasing uncertainty - Implications for risk management,‖ Safety science, vol. 71, pp. 71–79, Jan. 2015. H. Jalonen, ―The uncertainty of innovation: a systematic review of the literature,‖ jmr, vol. 4, no. 1, pp. 1–47, Aug. 2011. E. T. Penrose, The Theory of the Growth of the Firm. Oxford: Blackwell, 1959. S. Jeschke, I. Isenhardt, F. Hees, and S. Trantow, Enabling Innovation. Berlin, Heidelberg: Springer Science & Business Media, 2011. M. Paixao and J. Souza, ―A robust optimization approach to the next release problem in the presence of uncertainties,‖ Journal of Systems and Software, vol. 103, no. C, pp. 281–295, May 2015. O. Perminova, M. Gustafsson, and K. Wikström, ―Defining uncertainty in projects – a new perspective,‖ International Journal of Project Management, vol. 26, pp. 73– 79, 2008. B. J. Kolltveit, J. T. Karlsen, and K. Gronhaug, ―Exploiting opportunities in uncertainty during the early project phase,‖ Journal of Management in Engineering, vol. 20, no. 4, pp. 134–140, Oct. 2004. J. Turner, ―A Comparison of the Process of Knowledge Elicitation with that of Information Requirements Determination,‖ 1990. D. Hillson, Managing Risk in Projects. Gower Publishing, Ltd., 2009. R. Atkinson, ―Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria,‖ International Journal of Project Management, vol. 17, no. 6, pp. 337–342, Dec. 1999. P. L. Bannerman, ―Risk and risk management in software projects: A reassessment,‖ Journal of Systems and Software, 2008. C. Barclay, ―Towards an integrated measurement of IS project performance: The project performance scorecard,‖ Inf Syst Front, vol. 10, no. 3, pp. 331–345, May 2008. A. MacCormack, R. Verganti, and M. Iansiti, ―Developing Products on ‗Internet Time‘: The Anatomy of a Flexible Development Process,‖ Management Science, vol. 47, no. 1, pp. 133–150, Jan. 2001.
CE
[1]
[17] [18] [19]
ACCEPTED MANUSCRIPT
[26] [27] [28] [29] [30] [31] [32]
AC
[33]
CR IP T
[25]
AN US
[24]
M
[23]
ED
[22]
PT
[21]
R. D. Austin, L. Devin, and E. E. Sullivan, ―Accidental Innovation: Supporting Valuable Unpredictability in the Creative Process,‖ Organization Science, vol. 23, no. 5, pp. 1505–1522, 2012. S. V. Shrivastava and U. Rathod, ―Categorization of risk factors for distributed agile projects,‖ Information and Software Technology, vol. 58, no. C, pp. 373–387, Feb. 2015. H. T. Barney, N. B. Moe, T. Dybå, A. Aurum, and M. Winata, ―Balancing Individual and Collaborative Work in Agile Teams,‖ presented at the Proceedings of the 10th Agile Processes in Software Engineering and Extreme Programming Conference (XP2009), Sardinia, Italy., 2009, pp. 1–10. N. B. Moe, A. Aurum, and T. Dybå, ―Challenges of shared decision-making: A multiple case study of agile software development,‖ Information and Software Technology, vol. 54, no. 8, pp. 853–865, Aug. 2012. P. Gregory, L. Barroca, K. Taylor, D. Salah, and H. Sharp, ―Agile challenges in practice: a thematic analysis,‖ presented at the 16th International Conference on Agile Software Development (XP2015), Helsinki, 2015, pp. 1–13. G. van Valkenhoef, T. Tervonen, B. de Brock, and D. Postmus, ―Quantitative release planning in extreme programming,‖ Information and Software Technology, vol. 53, no. 11, pp. 1227–1235, Nov. 2011. C. Andriopoulos and M. W. Lewis, ―Exploitation-Exploration Tensions and Organizational Ambidexterity: Managing Paradoxes of Innovation,‖ Organization Science, 2009. R. M. Fontana, V. Meyer Jr, S. Reinehr, and A. Malucelli, ―Progressive Outcomes: A framework for maturing in agile software development,‖ Journal of Systems and Software, vol. 102, no. C, pp. 88–108, Apr. 2015. A. Moran, Agile Risk Management. Cham: Springer Science & Business Media, 2014. L. Argote, ―Input Uncertainty and Organizational Coordination in Hospital Emergency Units,‖ Administrative Science Quarterly, vol. 27, no. 3, pp. 420–434, 1982. G. Grote, Management of Uncertainty - Theory and Application in the Design of Systems. Springer, 2009. R. Lipshitz and O. Strauss, ―Coping with Uncertainty: A Naturalistic DecisionMaking Analysis,‖ Organizational Behavior and Human Decision Processes, 1997. S. Madsen and J. Pries-Heje, ―Conceptualizing Perceived Uncertainty in Project Work. In J. Pries-Heje (Ed.), Project Management Multiplicity: CurrentTrends,‖ no. 7, Frederiksberg: Samfundslitteratur, 2012, pp. 127–148. S. Ward and C. Chapman, ―Transforming project risk management into project uncertainty management,‖ International Journal of Project Management, 2003. T. Aven and O. Renn, ―On risk defined as an event where the outcome is uncertain,‖ Journal of Risk Research, vol. 12, no. 1, pp. 1–11, Jan. 2009. E. Paté-Cornell, ―On ―Black Swans‖ and ―Perfect Storms‖: Risk Analysis and Management When Statistics Are Not Enough,‖ Risk Analysis, vol. 32, no. 11, pp. 1823–1833, Mar. 2012. D. Hillson, Effective Opportunity Management for Projects. CRC Press, 2003. K. De Bakker, A. Boonstra, and H. Wortmann, ―Does risk management contribute to IT project success? A meta-analysis of empirical evidence,‖ International Journal of Project Management, vol. 28, pp. 493–503, 2010. R. Holt, ―Risk management: The talking cure,‖ Organization, vol. 11, no. 2, pp. 251– 270, Mar. 2004.
CE
[20]
[34] [35] [36] [37] [38]
ACCEPTED MANUSCRIPT
[45]
[46] [47] [48] [49] [50] [51] [52]
AC
[53]
CR IP T
[44]
AN US
[43]
M
[42]
ED
[41]
PT
[40]
R. Miller and D. Lessard, ―Understanding and managing risks in large engineering projects,‖ International Journal of Project Management, no. 19, pp. 437–443, Sep. 2001. D. Hillson, ―Extending the risk process to manage opportunities,‖ International Journal of Project Management, vol. 20, no. 3, pp. 235–240, 2002. J. Galbraith, Designing Complex Organizations. Reading, MA: Addison Wesley, 1973. R. Olsson, ―Risk management in a multi‐ project environment,‖ Int J Qual & Reliability Mgmt, vol. 25, no. 1, pp. 60–71, Jan. 2008. R. P. Singh, ―A Comment on Developing the Field of Entrepreneurship through the Study of Opportunity Recognition and Exploitation,‖ The Academy of Management Review, vol. 26, no. 1, pp. 10–12, Jan. 2001. M. Marinho, S. Sampaio, and H. Moura, ―Uncertainties in software projects management,‖ presented at the 2014 XL Latin American Computing Conference (CLEI), 2014, pp. 1–10. M. V. Tatikonda and M. M. Montoya-Weiss, ―Integrating operations and marketing perspectives of product innovation: The influence of organizational process factors and capabilities on development performance,‖ Management Science, vol. 47, no. 1, pp. 151–172, Jan. 2001. H. P. Krane, A. Rolstadås, and N. O. E. Olsson, ―Categorizing risks in seven large projects-Which risks do the projects focus on?,‖ Proj Mgmt Jrnl, vol. 20, no. 3, pp. n/a–n/a, 2010. S. Nidumolu, ―Standardization, requirements uncertainty and software project performance,‖ Information & Management, vol. 31, pp. 135–150, 1996. L. M. Maruping, V. Venkatesh, and R. Agarwal, ―A Control Theory Perspective on Agile Methodology Use and Changing User Requirements,‖ Information Systems Research, vol. 20, no. 3, pp. 377–399, Sep. 2009. S. Faraj and A. Yan, ―Boundary work in knowledge teams.,‖ Journal of Applied Psychology, vol. 94, no. 3, pp. 604–617, May 2009. J. Ropponen and K. Lyytinen, ―Components of software development risk: How to address them? A project manager survey,‖ IEEE Transactions on Software Engineering, vol. 26, no. 2, pp. 98–112, Feb. 2000. S. J. Carson, T. Wu, and W. L. Moore, ―Managing the Trade-off between Ambiguity and Volatility in New Product Development,‖ Journal of Product Innovation Management, vol. 29, no. 6, pp. 1061–1081, Jun. 2012. T. Moynihan, ―Coping with ‗requirements-uncertainty‘: the theories-of-action of experienced IS/software project managers,‖ Journal of Systems and Software, vol. 53, no. 2, pp. 99–109, Aug. 2000. H. F. Hofmann and F. Lehner, ―Requirements engineering as a success factor in software projects,‖ IEEE Software, vol. 18, no. 4, pp. 58–+, 2001. M. Drury, K. Conboy, and K. Power, ―Obstacles to decision making in Agile software development teams,‖ Journal of Systems and Software, vol. 85, pp. 1239– 1254, Aug. 2012. W. Souder and R. Moenaert, ―Integrating market and R&D project personnel within innovation projects,‖ Journal of Management Studies, vol. 29, no. 4, pp. 487–512, Oct. 1992. L. McLeod and D. Smith, Managing IT Projects. Massachusetts: Boyd and Fraser Publishing, 1996. T. McBride, ―The mechanisms of project management of software development,‖ Journal of Systems and Software, vol. 81, pp. 2386–2395, Feb. 2008.
CE
[39]
[54] [55] [56] [57]
ACCEPTED MANUSCRIPT
[64] [65] [66] [67] [68] [69] [70] [71] [72]
AC
[73]
CR IP T
[63]
AN US
[62]
M
[61]
ED
[60]
PT
[59]
S. V. Sgourev, ―How Paris Gave Rise to Cubism (and Picasso): Ambiguity and Fragmentation in Radical Innovation,‖ Organization Science, vol. 24, no. 6, pp. 1601–1617, 2013. C. Larman and V. Basili, ―Iterative and incremental developments: A brief history,‖ IEEE Computer, vol. 2006, no. June, pp. 47–56, 2003. L. Jun, W. Qiuzhen, and M. Qingguo, ―The effects of project uncertainty and risk management on IS development project performance: A vendor perspective,‖ International Journal of Project Management, vol. 29, no. 7, pp. 923–933, Oct. 2011. A. M. Maier, D. Doenmez, and C. Hepperle, ―Improving Communication in Design: Recommendations from the Literature,‖ presented at the International Conference on Engineering Design, ICED11, 15 - 18 August 2011, Denmark, 2011. A. J. Shenhar and D. Dvir, Reinventing Project Management. Harvard Business Press, 2013. A. Marchenko and P. Abrahamsson, ―Scrum in a multiproject environment: An ethnographically-inspired case study on the adoption challenges,‖ Agile, 2008. AGILE '08. Conference, no. 4, pp. 15–26, 2008. N. Moe, T. Dingsoyr, and T. Dyba, ―A teamwork model for understanding an agile team: A case study of a Scrum project,‖ Information and Software Technology, 2010. A. M. Magdaleno, C. M. Lima Werner, and R. M. de Araujo, ―Reconciling software development models: A quasi-systematic review,‖ Journal of Systems and Software, vol. 85, no. 2, pp. 351–369, Feb. 2012. K. Schwaber and M. Beedle, Agile Software Development with Scrum. Upper Saddle River, NJ: Prentice-Hall, 2002. K. Beck, eXtreme Programming explained. San Francisco: Addison-Wesley, 2000. T. Dingsoyr, S. Nerur, V. G. Balijepally, and N. B. Moe, ―A decade of agile methodologies: Towards explaining agile software development,‖ Journal of Systems and Software, pp. 1213–1221, 2012. B. Schatz and I. Abdelshafi, ―Primavera gets Agile: A successful transition to Agile development,‖ IEEE Software, vol. 22, no. 3, pp. 36–42, May 2005. M. Golfarelli, S. Rizzi, and E. Turricchia, ―Multi-sprint planning and smooth replanning: An optimization model,‖ Journal of Systems and Software, vol. 86, no. 9, pp. 2357–2370, Sep. 2013. R. K. Yin, Case Study Research: Design and Methods. SAGE Publications, 2013. K. M. Eisenhardt and M. E. Graebner, ―Theory Building from Cases: Opportunities and Challenges,‖ The Academy of Management Journal, vol. 50, no. 1, pp. 25–32, Feb. 2007. P. Runeson and M. Hoest, ―Guidelines for conducting and reporting case study research in software engineering,‖ Empirical Software Engineering, vol. 14, no. 2, pp. 131–164, Apr. 2009. M. B. Miles, A. M. Huberman, and J. Saldaña, Qualitative data analysis. Thousand Oaks: Sage Publications, 2013. S. B. Merriam, Qualitative Research. John Wiley & Sons, 2014. J. C. Flanagan, ―The critical incident technique,‖ Psychological bulletin, vol. 51, no. 4, pp. 327–358, 1954. R. Vidgen and X. Wang, ―Coevolving Systems and the Organization of Agile Software Development,‖ Information Systems Research, vol. 20, no. 3, pp. 355–376, Sep. 2009. B. Fitzgerald, G. Hartnett, and K. Conboy, ―Customising agile methods to software practices at Intel Shannon,‖ Eur J Inform Syst, vol. 15, no. 2, pp. 200–213, Apr.
CE
[58]
[74] [75] [76] [77] [78]
ACCEPTED MANUSCRIPT
[86] [87] [88] [89] [90] [91] [92] [93]
AC
[94]
CR IP T
[85]
AN US
[84]
M
[83]
ED
[82]
PT
[80] [81]
2006. V. Mahnič and T. Hovelja, ―On using planning poker for estimating user stories,‖ Journal of Systems and Software, 2012. P. G. Smith, Flexible Product Development. John Wiley & Sons, 2007. R. Leifer, C. M. McDermott, G. C. OConnor, L. S. Peters, M. P. Rice, and R. W. Veryzer, Radical Innovation. Boston: Harvard Business Press, 2000. R. D. Austin and L. Devin, ―Research Commentary—Weighing the Benefits and Costs of Flexibility in Making Software: Toward a Contingency Theory of the Determinants of Development Process Design,‖ Information Systems Research, vol. 20, no. 3, pp. 462–477, Sep. 2009. S. Madsen, ―Conceptualising the causes and consequences of uncertainty in is development organisations and projects,‖ presented at the Proceedings of the 15th European Conference on Information Systems, ECIS 2007, 2007, pp. 855–864. A. Oke, N. Munshi, and F. O. Walumbwa, ―The influence of leadership on innovation processes and activities,‖ Organizational Dynamics, 2009. R. Hoda, J. Noble, and S. Marshall, ―The impact of inadequate customer collaboration on self-organizing Agile teams,‖ Information and Software Technology, vol. 53, no. 5, pp. 521–534, May 2011. M. A. Valentine and A. C. Edmondson, ―Team Scaffolds: How Mesolevel Structures Enable Role-Based Coordination in Temporary Groups,‖ Organization Science, vol. 26, no. 2, pp. 405–422, Apr. 2015. M. Song and M. M. Montoya-Weiss, ―The Effect of Perceived Technological Uncertainty on Japanese New Product Development,‖ The Academy of Management Journal, vol. 44, no. 1, pp. 61–80, Feb. 2001. E. Bonabeau, N. Bodick, and R. W. Armstrong, ―A more rational approach to newproduct development,‖ Harvard Business Review, 2008. R. Jiang, ―An Information-Entropy-based Risk Measurement Method of Software Development Project,‖ Journal of Information Science and Engineering, vol. 30, no. 5, pp. 1279–1301, Sep. 2014. S. Coyle and K. Conboy, A case study of risk management in agile systems development. Berlin: Springer, 2009. J. Surowiecki, The Wisdom of Crowds. Anchor, 2005. E. Kutsch, D. Denyer, and M. Hall, ―Does risk matter? Disengagement from risk management practices in information systems projects,‖ European Journal of Information Systems, 2012. R. Bradley and M. Drechsler, ―Types of Uncertainty,‖ Erkenntnis, vol. 79, no. 6, pp. 1225–1248, Aug. 2013. K.-S. Na, J. T. Simpson, X. Li, T. Singh, and K.-Y. Kim, ―Software development risk and project performance measurement: Evidence in Korea,‖ Journal of Systems and Software, vol. 80, no. 4, pp. 596–605, Apr. 2007. A. Moran, Managing Agile. Cham: Springer, 2015.
CE
[79]
[95]
ACCEPTED MANUSCRIPT Table 1. Overview of teams and project profiles
D
Finance
E
Insurance
F
Insurance
G
Finance
H
Finance
I
Software Dev. and IT Consulting Software Development
AC
J
K
Automotive
Interview participants 3 interviews: 1 team manager (Scrum Master) and 2 developer.
19 team members
5 interviews: 1 team manager (Scrum Master) and 4 developers, one of which later became a second Scrum Master. 4 interviews: 1 team manager (Product Owner) and 3 developers
CR IP T
Finance
Team size 7 team members
12 team members 12 team
AN US
C
The project was started 1.5 years prior to data collection with the aim to develop a software application that consolidates information from several customer relationship management products for internal company use. This project had two objectives. One was the development of a mobile application for end users, and the second was the creation of knowledge about new technologies that the company aims to exploit in the future. The project was started less than one year before data collection. For the previous five years, this project annually released improved versions of a software that is used by other software products of the bank to test their compliance with business rules. Team members regularly work in close collaboration with their clients from different departments of the company. The project has the objective of implementing enhancements to existing financial tools in the bank. It had been ongoing for only 3 months at the time of interviewing, and the team was still in the process of setting up agile development practices.
M
Telecommunications
ED
B
Project The project is run in close collaboration with a client in the ventilating and air-conditioning industry for whom an embedded system of smart devices is constantly enhanced. The project is one of company A‘s most stable collaboration and has been ongoing for more than 5 years with different team members working on it. The project had been set up two years before data collection in order to develop an application for customer order management of future product offerings. The team consists of several external developers who are contractors with special knowledge about functionality provided by suppliers. The client is internal to the company. This project was started two years before data collection with the objective to develop an archiving system for documents that need to be stored and retrieved digitally across the company‘s various locations. The client is internal to the company. The project serves the development and continuous improvement of new company communication technologies. It started seven years prior to data collection, with two product release cycles per year.
PT
Industry Software Development
This project was set up two years prior to data collection to develop an application as ordered by the client, which integrates control over 54 different hardware products via a mobile interface. This project involves the development, deployment and operation of a server back-end for a web and mobile consumer application, which integrates several services. It has been ongoing for two years. The development team works closely together with a larger team of the company that develops a specialized service for the back-end system. The objective of this project is to create smartphone applications and end-user software for integrated systems. The focus of the interviewed team was on navigation and routing software.
CE
Team A
12 team members 5 team members and 1 Scrum coach 10 team members
12 team members
6 team members
5 interviews: 2 team managers (Scrum Master and Product Owner) and 3 developers 4 interviews: 1 team manager (Product Owner) and 3 developers. 4 interviews: 1 team manager (Product Owner), 2 developers and the Scrum coach 4 interviews: 2 team managers (Scrum Master and Product Owner) and 2 developers 3 interviews: 1 team manager (Scrum Master), 1 external stakeholder (acting as Scrum coach) and 1 developer. 4 interviews: 1 team manager (Product Owner) and 3 developers
3 team members
3 interviews: 1 team manager (Scrum Master) and 2 developers.
4 team members
3 interviews: 1 team manager (Scrum Master) and 2 developers.
ACCEPTED MANUSCRIPT
Table 2. Practices for approaching uncertainty
Uncertainty anticipation
1. Incorporating uncertainty in plans 2. Developing vigilance 3. Incremental feedback
Information accrual
4. Team based task analysis 5. Knowledge sharing Solution inspection
6. Prototyping
7. Creating alternatives Role-based 8. Creating coordination functional roles
Related agile techniques* Increment planning (Not explicitly advised) Product review (for customer feedback) Planning Poker & Increment planning Pair programming & information radiators Prototyping (Not explicitly advised) (Not advised; Scrum even discourages this practice) Product review
Description of practice Acknowledging that changes will occur, teams try to anticipate and focus on product requirements least expected to change, yet remain flexible to adapt their plans. Team members strive to remain alert to opportunities that present themselves. Team members frequently collect feedback from colleagues and external project stakeholders.
CR IP T
Practice
Team members collectively analyze requirements before they create and plan tasks. Knowledge management structures are established to manage resource uncertainty. Preliminary versions of the final product foster discussions on functionality and indicate the quality of different possible solutions. Developers strive to explore several solutions in parallel to determine which best fits customer expectations. Team member roles are created temporally in order to handle unexpected events efficiently.
AN US
Principle
AC
CE
PT
ED
M
9. Stakeholder Teams value close collaboration with suppliers and clients integration and design decision structures accordingly. 10. Task Pair programTeams aim to create structures that permit developers to switching ming flexibly distribute tasks to freed resources. *The mentioned agile techniques are related to, but do not entirely cover the practices detailed on the left (with the exception of prototyping). A list of technical and non-technical agile techniques can be found in [95].
ACCEPTED MANUSCRIPT
Appendix A. Interview questions Guiding questions Purpose [Provide information about the purpose of the Explanation of the research context and interview, which is to study uncertainty questions, as well as the interview method. management in teams. Guarantee anonymity.] Explain critical incidents approach: ―I would like to go through different situations with you that are related to the team having to deal with uncertainty. There are different types of uncertainty, related to resources, tasks and requirements. I would like you to try and recall any situation in as much detail as you can and explain it to me step by step.‖ Project Please tell me about the project. Collect background information of the Background Please tell me about your role and tasks in the project, including its history, current focus, team. number of team members, stakeholders and what is expected from them, and the specific role of the interview partner. Uncertainties Can you remember a situation in your team in Collect incidents related to different types of (negative) which you have experienced negative uncertainty and their positive/negative consequences of uncertainty? consequences. Clarify understanding for What led to this situation? different uncertainty types: How did this affect the project? Resource uncertainty How did this affect your work? - (Un)availability of developers, software What was the team‘s reaction? tools, technical infrastructure, incl. How often does a situation like this happen? technical failures (e.g., licenses, servers) [Repeat for specific types of uncertainties: Requirement uncertainty 1) resource, 2) task, 3) requirement] - Changes to the product / features - Shared understanding of the requirements Task uncertainty - How clear is it what needs to be done? - How many features can be implemented in the given time frame? - How precise are estimations (how often are they changed?) Uncertainties Can you remember a situation in your team in (positive) which you have experienced positive consequences of uncertainty? What led to this situation? How did this affect the project? How did this affect your work? What was the team‘s reaction? How often does a situation like this happen? [Repeat for specific types of uncertainties: 1) resource, 2) task, 3) requirement] Conclusion [Announce the end of the interview, thank Provide opportunity to add comments / of the interviewee for their time and transition to remarks / additional relevant information. interview concluding remarks] Is there anything you would like to add? Thank you for your time.
AC
CE
PT
ED
M
AN US
CR IP T
Topic Introduction
ACCEPTED MANUSCRIPT Appendix B. Coding scheme Uncertainty Characteristic Achievable amount of work Availability of process artifacts Quality of input
Code
Explanation
Practice
Updating task estimations
4. Team based task analysis — (4.)
Availability of human resources
Working with redundant roles / skills
Task sizes are estimated in the planning game as a team-based activity Specific problems and possible solutions are shared with all team members To avoid lack of quality regarding supplied products, suppliers are closely integrated, e.g. in daily team meetings Several team members are required to be able to perform a specific task Important project information is centrally documented
Discussing workarounds with the whole team Increasing collaboration with suppliers
Maintaining a projectwide knowledge base
M
Lack of details about demanded functionality
Matching task dependencies to developer availabilities Integrating stakeholders‘ feedback
ED
Requirement
PT
Direct communication with customers Early prototyping
AC
CE
Ambiguous information
Visual planning (e.g., using charts, workflows, calendars posted to the wall) based on available and non-available information (represented by wildcard or scenarios) is used to clarify where uncertainty remains Developers are dynamically assigned tasks / roles to minimize task dependencies (idle times) Frequently integrating feedback from customers, managers, and other stakeholders supports the clarification of requirements and mitigate ambiguity Engaging in direct communication mitigates ambiguity Discussions with customers are based on prototypes from the start of a project Development of multiple solutions can be beneficial to get better feedback (internal and external) In searching for the best way to solve a problem, possible future constraints and then available or then no longer available options are considered Phases of stable development are interrupted by openness to change (e.g., after an iteration or a release cycle) to establish a rhythm of certain/uncertain development Testing early and frequently provides incremental feedback Integrating stakeholders, e.g. through direct communication, provides feedback Using knowledge management to
AN US
Enhancing transparency
Creating alternative solutions Anticipative search for technical solution
Unexpected changes
Allowing change requests only at certain points in time
Demanded quality of the product
Testing solutions
Quality of a
Improve discussions
Involve external stakeholders
9. Stakeholder integration
CR IP T
Uncertainty Type Resource
10. Task switching 5. Knowledge sharing 1. Incorporate uncertainty in plans
8. Creating functional roles 3. Incremental feedback — (9.) 6. Prototyping 7. Creating alternatives 2. Developing vigilance — (1.)
— (3.) — (3.) — (5.)
ACCEPTED MANUSCRIPT solution to a problem
Unexpected difficulties
Pooling team members into task forces Pair programming Using signaling devices
Mutual team member support Task sequence or process uncertainty
Using ad hoc meetings
Team reflections
AN US
Minimizing task sizes and dependencies
AC
CE
PT
ED
M
Time required to accomplish a task
improve discussions Creating temporal roles directed at specific problems Working in pairs increases the spread of knowledge within teams Visual tools are used, e.g., for blocked tasks (on the planning board) or within computer aided collaboration tools Abilities to support team members is cultivated, which enables task switching Frequent, small, ad hoc / informal meetings are used to discuss progress, solve minor problems, clarify tasks Team reflections are used to improve processes, for example to establish roles for specific tasks Small tasks allow more flexibility
— (8.) — (5.) — (5.)
— (10.) — (5.)
CR IP T
Task
— (8.)
— (10.)