Article

Project Management Journal

Vol. 00(0) 1–20
Investigating the “Socio” in Socio-­Technical © The Author(s) 2020
Article reuse guidelines:

Development: The Case for Psychological ​sagepub.​com/​journals-­​permissions

​DOI: ​10.​1177/​8756​9728​20933057

Safety in Agile Information ​journals.​sagepub.​com/​home/​pmx

Systems Development

Phil Hennel1 and Christoph Rosenkranz1

Abstract
One constitutional part of project management is the management of teams, their actions, and their social mechanisms. Team
processes, behavior, and agile practices used by team members play important parts in the success of projects. To reap benefits
from these highly interactive and social-­focused practices, team members need to feel safe to speak freely. We propose a model
that conceptualizes the effects of psychological safety and (social) agile practices on team performance. The proposed model
combines recent research from organizational psychology and agile information systems development to provide a better un-
derstanding of the team-­level effects. Our findings from three case studies conducted in two large insurance companies and one
software development company suggest that social agile practices positively influence psychological safety, transparency, com-
munication, and ultimately productivity.

Keywords
agile software development, psychological safety, performance, information systems development, project management,
social agile practices

Introduction action of agile practices in teams (Kautz et al., 2007; Lee & Xia,
2010; Persson et al., 2012; Sarker et al., 2009).
Approaching the end of the second decade after the Agile Looking back at the extant research on agile it becomes
Manifesto (Beck et al., 2001), the initial wave of enthusiasm is appar­ent that, although centered on teamwork, agile adds an
part of the past, and agile approaches have been disillusioned addi­tional layer to traditional teams—especially its focus on
by mixed results concerning their performance in practice embracing change as an inevitable factor instead of avoiding it
(Hoda et al., 2011; Janes & Succi, 2012). However, agile prac- at all costs. This unique focus is what differentiates agile prac-
tices are still becoming more and more popular in industry tices from traditional meth­ ods of project management.
(VersionOne, 2018), research is still publishing special issues Moreover, organizations face a multitude of challenges when
on agile (e.g., Niederman et al., 2018), and agile approaches introducing agile practices (e.g., Dikert et al., 2016; Gregory
have recently been integrated in to A Guide to the Project et al., 2016; Ramesh et al., 2010; VersionOne, 2018), further
Management Body of Knowledge (PMBOK® Guide) – Sixth implying the special nature of agile approaches when compared
Edition (e.g., Project Management Institute [PMI], 2017). to traditional project management approaches.
Agile practices put emphasis either on management practices However, research has not yet caught up with industry, and
such as daily standups (e.g., Scrum; Schwaber, 1995) or develop- team-­level research on agile information system development
ment practices such as pair programming (e.g., XP; Beck & (AISD) is scarce (Diegmann et al., 2018; Lee & Xia, 2010).
Andres, 2004). They aim at simultaneously decreasing sunk Existing studies mostly have investigated specific and
costs and path dependencies while increasing flexibility and
strengthening a team’s resilience to a changing environment,
ultimately benefiting project success. With emphasizing the need
1
for highly iterative project progress, constant feedback and com- University of Cologne, Germany
munication, and synchronization, the need for team management Corresponding Author:
and team collaboration increases as well—making it even more Phil Hennel, University of Cologne, Cologne, Germany.
important to understand the social behavior and mechanisms of Email: hennel@​wiso.​uni-​koeln.​de
2 Project Management Journal 00(0)

individual or organizational phenomena, such as the use and With this study, we follow this call and—in contrast to pre-
effects of specific agile practices (e.g., Balijepally et al., 2009; vious studies, which centered on method selection or project-­
Holmqvist & Pessi, 2006; Maruping, Zhang et al., 2009; Recker level performance (e.g., Tripp & Armstrong, 2018; van
et al., 2017; Tripp & Armstrong, 2018; van Oorschot et al., Oorschot et al., 2018)—aim at investigating the specific prac-
2018), or effects regarding whole projects or organizations, tices and their behavioral implications from a team-­level per-
such as the introduction of AISD approaches to teams (e.g., spective. To open the black box of the ISD process and
Cao et al., 2009; Heeager, 2012; Hong et al., 2011; Kotlarsky, conceptualize this for the domain of AISD, we build on and
2007; Mangalaraj et al., 2009), or the usage of AISD practices adapt findings of team and organizational behavior research,
in large-­scale, multi­team environments or portfolios (e.g., which has already taken technology-­induced effects into
Dikert et al., 2016; Dingsøyr et al., 2018; Sweetman & Conboy, account (e.g., Ilgen et al., 2005; Kozlowski & Ilgen, 2006) and
2018). Team-­level effects, however, are mostly absent from has explored social aspects of inter-­team-­member cognitive
these works, with only few exceptions (e.g., DevOps Research effects (e.g., shared cognition [Healey et al., 2015] or adaptive
& Assessment, & Google Cloud, 2019; Lindsjørn et al., 2016; structuration theory [DeSanctis & Poole, 1994]).
Przybilla et al., 2018; Schmidt et al., 2014). More specifically, we conceptualize the ISD process as
This is perplexing because information system develop- being stimulated by agile practices, which in turn affect and are
ment (ISD) is mostly conducted in teams and quintessentially affected by psychological safety. When embracing change, as it
is a team effort (Sawyer et al., 1997, 2010; Siau et al., 2010). is one of AISD’s core values, teams need to be resilient to the
ISD generally takes place in the form of projects (Hirschheim shocks and changes of a turbulent environment (Conboy, 2009).
et al., 1995, p. 33) or within product teams (Gerwin & To achieve team resilience (Meneghel et al., 2016), a team
Barrowman, 2002), with many involved stakeholders and needs to provide structure and an environment, which enable
team members (Chae & Poole, 2005). As a result, many of the open, free, and safe communication—psychological safety is a
problems associated with ISD projects are sociological, rather necessity for resilience (Lengnick-­Hall et al., 2011). For exam-
than technological, in nature (DeMarco & Lister, 1987, p. 4; ple, a regularly held retrospective aims at free, open, and honest
Sawyer et al., 1997, 2010). For example, coordination and exchange among team members and their views on issues in
communication between various stakeholders are necessary the project and the team; AISD cannot work without psycho-
for successful ISD (Corvera Charaf et al., 2013; Gallivan & logical safety —that is, “a shared belief held by members of a
Keil, 2003; Ko et al., 2005), and creating mutual understand- team that the team is safe for interpersonal risk taking”
ing and common ground between different involved stake- (Edmondson, 1999, p. 354), which is a driver for free, open,
holders is a major driver of ISD success (Bittner & Leimeister, and honest communication (e.g., Edmondson, 1999).
2014; Gallivan & Keil, 2003; Rosenkranz et al., 2013, 2014; We chose psychological safety as a central concept for three
Tan, 1994). Moreover, not only do practitioners call for more reasons. First, a healthy and supportive (i.e., psychologically
research on social aspects of AISD teams (Freudenberg & safe) organizational environment has been shown to be closely
Sharp, 2010), but also scant research exists on social aspects connected to team resilience (e.g., Bardoel et al., 2014;
of the development of socio-­technical systems in general, Lengnick-­Hall et al., 2011), which in turn is associated with
which information systems (IS) essentially are (e.g., Kautz AISD’s capability to respond to change (Chakravarty et al.,
et al., 2007; Long & Siau, 2007; Sawyer et al., 2010; van 2013). Second, psychological safety influences team perfor-
Kelle et al., 2015). To understand the mechanisms of action at mance significantly (e.g., Bunderson & Boumgarden, 2010;
work in AISD teams and their effects, an operationalization Carmeli & Gittell, 2009; Schulte et al., 2012), and it has been
on a team level is needed. Further, due to the increased impor- suggested as a key antecedent of team performance in ISD as
tance of social interactions in AISD compared to traditional well (DevOps Research & Assessment, & Google Cloud,
approaches to project management and ISD (Hummel et al., 2019). Third, it touches on many “pain points” of agile teams,
2015), team-­level effects in AISD likely differ from those for instance, by its mitigating capacity of negative effects of
found in traditional approaches and social aspects may vary. team diversity (Roberge & van Dick, 2010) or its positive effect
Importantly, our knowledge of the ISD process itself is often on team diversity climate (Singh et al., 2013). Promising recent
characterized as a “black box” (Siau et al., 2010, p. 92); only (e.g., Bunderson & Boumgarden, 2010; Carmeli & Gittell,
little ISD research goes beyond ISD methods, and there is a 2009; Schulte et al., 2012) and well-­established research (e.g.,
need for theory and studies about social behavior and pro- Edmondson, 1999) on psychological safety and its influence on
cesses of communication, negotiation, and learning (Kautz team performance has not yet been integrated into project man-
et al., 2007, p. 235). IS researchers therefore call for more agement and ISD research and has not been evaluated on their
conceptual and empirical research on team-­level effects in applicability and significance in AISD project management.
AISD (Conboy, 2009; Mangalaraj et al., 2009; McAvoy & When a whole range of similar, socially focused, practices are
Butler, 2009; McAvoy et al., 2013). Without extended knowl- implemented (i.e., an agile approach is applied), this becomes
edge on these important effects, AISD project management even more important. Additionally, agile practices, such as reg-
remains driven by chance and individual, isolated, and anec- ular retrospectives, add structure to a team’s processes, which,
dotal knowledge and experience. in turn, strengthens psychological safety (Bunderson &
Hennel and Rosenkranz 3

Boumgarden, 2010), suggesting a mutual interdependency. management and ISD methods supposedly aim to facilitate
Consequently, the following research question guides our communication and knowledge transfer among different partic-
study: ipants and stakeholders. For example, rational unified process
and various other approaches are often stated to have been cre-
How and why does the use of agile practices and their interac- ated just for this purpose (Kroll & Kruchten, 2003, pp. 145–
tion with psychological safety affect project team behavior and, 149; Kruchten, 2004, pp. 5, 92). The majority of traditional
in turn, performance? project management and ISD methods, either sequential or iter-
ative, is plan driven and relies on formal communication, such
We therefore propose a model to investigate the effects of as specification documents or models to control communica-
psychological safety on the use and effects of (social) agile tion and knowledge transfer among project members and other
practices. Specifically, we suggest that social agile practices stakeholders (Black et al., 2009; Boehm & Turner, 2004; Kraut
(SAPs; Hummel et al., 2015)—that is, practices such as daily & Streeter, 1995). For example, requirements are usually stated
standup meetings or pair programming, which contribute within a requirements document, which at the end of the system
directly to direct communication, collaboration, and interaction analysis phase, is a specification of the system to be built (Pohl,
among team members—are likely to affect and to be affected 1994). In rapidly changing environments, however, it is hard
by psychological safety, and therefore have an indirect effect on for formal mechanisms of communication, such as project
performance. With agile practices not only being popular in plans, models, or specification documents to react quickly
ISD projects in general (VersionOne, 2018), but also being enough, and plan-driven and sequential approaches falter (Byrd
transferred to other task domains (Niederman et al., 2018), this et al., 1992; Herbsleb & Mockus, 2003; Kraut & Streeter,
becomes a crucial focus for research on project management as 1995): “Rather than being bastions of order in an uncertain
well. world, traditional teams may indeed become chaotic should
To provide a first evaluation of our model and to test this their plan-­driven organization be overwhelmed by events”
model’s propositions, we conducted a multiple-­case study in (Vidgen & Wang, 2009, p. 374).
two major insurance companies and one software development Agile principles and new management concepts such as
company. Based upon empirical data gathered in these cases, Scrum or Extreme Programming have emerged during the last
we performed a two-step deductive coding process. We present decades and have built upon iterative work as the lowest com-
the results in this article. Providing deeper insights into benefits mon denominator (Beck & Andres, 2004; Beck et al., 2001;
and presuppositions of AISD practices aids research and prac- Martin, 1991; Poppendieck & Poppendieck, 2003; Schwaber,
tice, as these insights could help to reduce the number of failed 1995). The resulting AISD approaches (Cao et al., 2009; Vidgen
projects. & Wang, 2009) trade strict control for more flexibility and
In the following section, we give an overview about related autonomy within the team, the overall development process is
work, derive the proposed model and corresponding proposi- not planned and scheduled upfront, and progress is made in
tions, and describe the cases and coding process. Finally, we small iterative phases, while encouraging change and constant
discuss our results and implications. feedback (Cockburn & Highsmith, 2001; Highsmith &
Cockburn, 2001). Planning becomes a permanent task, and
team leadership is established via collaboration and is sepa-
Related Work rated from project lead (Dybå & Dingsøyr, 2008, 2009).
While the team is thus highlighted as the crucial aspect of
Information Systems Development, Project AISD in practice, extant research on AISD approaches mainly
Management, and Agile Approaches has investigated specific and individual or organizational phe-
Software-­based IS are often developed in the form of projects nomena, such as the use and effects of specific agile practices
(Hirschheim et al., 1995, p. 33), with many involved stakehold- (e.g., Balijepally, et al., 2009; Holmqvist & Pessi, 2006;
ers and project team members (Chae & Poole, 2005). The Maruping, Zhang et al., 2009; van Oorschot et al., 2018), or
nature of ISD is in many aspects intangible (Cule et al., 2000), effects regarding whole projects or organizations, such as the
and the major problems of ISD projects are not so much tech- introduction of AISD methods to teams (e.g., Cao et al., 2009;
nological as sociological in nature (DeMarco & Lister, 1987, p. Heeager, 2012; Hong et al., 2011; Kotlarsky, 2007; Mangalaraj
4). Communication, collaboration, and coordination are neces- et al., 2009), or the usage of AISD approaches in large-­scale,
sary for successful implementation (Gallivan & Keil, 2003; Ko multiteam environments or portfolios (e.g., Dingsøyr et al.,
et al., 2005; Rosenkranz et  al., 2017), and creating a shared 2018; Sweetman & Conboy, 2018).
understanding is deemed to be a major driver for ISD success As existing research thus covers individual and organization-­
(Corvera Charaf et al., 2013; Gallivan & Keil, 2003; Rosenkranz wide level of effects on AISD, team-­level effects are covered
et al., 2013; Tan, 1994). less so, and existing results are contradictory. For example,
In practice, approaches for developing software-­intensive IS team research has included technology as an influencing factor
range from sequential approaches (Royce, 1970) to more of teamwork (e.g., Kozlowski & Ilgen, 2006), but specific fea-
cyclic, iterative approaches (Boehm, 1988). Most project tures of (A)ISD have not been observed. Some studies have
4 Project Management Journal 00(0)

found that cohesive (i.e., nondiverse) teams are the optimal and moderates a latitude of team-­level effects (Martins et al.,
base for applying agile practices (Cao et al., 2009; Fruhling & 2013; Roberge & van Dick, 2010), among them learning, inno-
de Vreede, 2006), while other studies suggest that diversity vativeness, self-­reflection, and overall performance. As AISD
amplifies creativity and problem-­solving ability (Bear & practices rely heavily on social interactions, self-­organization,
Woolley, 2011; Lee & Xia, 2010; Phillips et al., 2006) and and self-­reflection, strengthening team learning behavior, infor-
therefore might provide benefits for AISD. These inconsisten- mation sharing behavior, innovating capacity, and improve
cies are especially important for AISD, as AISD teams rely team members’ motivation to speak up for organizational
heavily on efficiency (to respond quickly to changes; Conboy, improvements can be expected to improve agile team perfor-
2009) and problem-­solving ability (to complete complex, non- mance. Psychological safety affects all of these aspects (Baer &
routine tasks; Lee & Xia, 2010). Frese, 2003; Detert & Burris, 2007; Liang et al., 2012;
Nembhard & Edmondson, 2006), which leads us to suggest that
psychological safety plays an important role in moderating cor-
Team Resilience responding effects of AISD practices.
One concept closely linked to efficiency and problem-­solving Psychological safety, a shared belief held by members of a
ability (i.e., team effects), which has also been repeatedly team that the team is safe taking actions that could be interper-
linked to AISD, is team resilience (Meneghel et al., 2016). sonally risky in other teams (Edmondson, 1999, p. 354), has
AISD explicitly acknowledges the importance of being able to been used by researchers to explain organizational learning
respond to requirement changes and even embrace change and (Nembhard & Edmondson, 2006), information sharing, and
an ever-­changing environment (Beck et al., 2001). As changes how team members are motivated to speak up for improve-
impose difficulties for the team, AISD teams have to have the ments (Detert & Burris, 2007; Liang et al., 2012) or to take
capacity to recover quickly from changes and difficulties, initiatives to innovate (Baer & Frese, 2003). Structure (e.g., in
which is the textbook definition of resilience (Oxford English the form of clear procedures for coordinating and prioritizing
Dictionary). As AISD explicitly stresses the importance of work) fosters psychological safety, especially in self-­managed
being able to respond to requirement changes (Beck et al., teams, and improves team learning (Bunderson & Boumgarden,
2001), resilience supposedly is an important team trait for suc- 2010). Further, an influence of psychological safety on the abil-
cessful AISD, as changes in requirements is one of the main ity to learn from failures has been identified (Carmeli & Gittell,
reasons ISD projects fail (Maruping, Venkatesh et al., 2009). 2009; Jehn et al., 2014).
Resilience in general has been used in biology to describe Furthermore, psychological safety moderates (i.e., miti-
the ability of a dynamic multispecies ecological system to per- gates) the negative effect of diversity on performance (Roberge
sist with the same basic structure when subjected to stress & van Dick, 2010). A direct effect on performance (Schaubroeck
(Holling, 1973). Derived from this, team resilience is used to et al., 2011), especially in diverse teams (Singh et al., 2013), is
describe a team’s ability to “withstand disruptive factors, syn- apparent as well.
onymous with both buffering against disruptive factors and cor- In sum, extant research has applied theories of organiza-
recting for disruptive factors without significant strategic tional psychology while being focused on IT use rather than on
changes” (Chakravarty et al., 2013, p. 983). As an important AISD (e.g., DeSanctis & Poole, 1994; Gorecki et al., 2008;
aspect for this study of team resilience is its influence on per- Nan, 2011; Wang & Hahn, 2015). While research on teams thus
formance in teams in general (Meneghel et al., 2016). is not completely new to AISD research, psychological safety
While resilience can stem from different sources (e.g., indi- and its relationship to team resilience have not been investi-
vidual characteristics) and can vary depending on the present gated, but are seen as an important factor for AISD practitioners
disruption, one—intuitive and important—way to develop (DevOps Research & Assessment, & Google Cloud, 2019).
resilience is a critical review by the team of the team and its
success (Alliger et al., 2015). That way, a team can spot weak-
nesses in its processes and ways of work and improve itself. Theory Development
Team members therefore have to feel that they can voice con- Considering that research has yet to identify the preconditions
cerns and critique and feel safe to take interpersonal risks by for successful implementation and use of AISD, we propose to
doing so. This has been conceptualized in organizational psy- contribute to closing this research gap with a conceptual model.
chology by psychological safety (Edmondson, 1999). Based on previous work (Diegmann & Rosenkranz, 2017), we
argue that social agile practices (SAPs) in and of themselves do
not necessarily provide any benefit to performance. Instead, we
Psychological Safety propose that this benefit can only be realized if team members
Psychological safety, which originates from concepts such as feel that they can speak freely and voice concerns or give alter-
leadership style or cohesiveness, is seen by research in organi- native, possibly controversial, solutions. In support of this
zational behavior as an important one, especially in regard to claim, empowering management, flat hierarchies, a collabora-
innovativeness and learning behavior (Baer & Frese, 2003; tive environment, which enables team members to express their
Nembhard & Edmondson, 2006). Psychological safety affects opinions have been found to be important facilitators for AISD
Hennel and Rosenkranz 5

Figure 1.  Resulting research model.

(Batra et al., 2016; Chow & Cao, 2008) and similarly for learn- randomized samples in experiments), AISD research has not
ing organizations in general (Eisenberg et al., 2013; Ellinger & put these theories together and evaluated these effects in the
Bostrom, 1999). Therefore, we propose psychological safety to specific context of AISD teams in the field, although AISD
moderate the effect of SAPs. If the team is not feeling safe (i.e., methods rely heavily on team work, team composition, com-
low psychological safety), the AISD practices only provide munication, and interpersonal relationships (Beck et al., 2001;
marginal benefits or even reduce performance. If, however, the Lee & Xia, 2010; Maruping, Venkatesh et al., 2009; Rosenkranz
team does feel safe (i.e., high psychological safety), SAPs et al., 2013; Sawyer et al., 2010). If our assumptions hold true,
unfold their full potential and the team gets performance bene- the proposed model helps in explaining team-­level effects in
fits from the implementation of SAPs. We further argue for a AISD and in turn gives guidance to improve team resilience
feedback loop in that SAPs in turn lay the groundwork for and performance. Figure 1 displays our proposed model and
emergent psychological safety in AISD teams by providing Table 1 summarizes the constructs.
safe environments (e.g., via daily standup meetings) and foster- As structure helps self-­managed teams to improve their
ing mutual support and responsibility (e.g., via collective code learning from failures (Bunderson & Boumgarden, 2010) and
ownership). Note that we are not interested in textbook agile as SAPs provide this structure both in the form of daily rou-
approaches, but the individual configurations of SAPs (i.e., the tines (e.g., daily standup meetings), and in the form of mento-
respective method tailoring result employed in our cases). We ring and help-­ providing structures, (e.g., through pair
are therefore looking at the number of, as well as the frequency programming or collective code ownership), we argue that the
and quality of employed SAPs rather than the differences usage of SAPs positively influences performance and we pro-
between what agile practices call for and how these are imple- pose P1:
mented in the different cases.
While these phenomena have been investigated on their own P1: Usage of social agile practices positively affects
and mainly in the context of general or occasional teams (e.g., performance.

Table 1.  Construct Summaries

Name Definition References

Social Agile Practices (SAPs) Agile practices entailing communication practices or practices aiming at Hummel et al. (2015)
exchanging knowledge and facilitating interpersonal interaction (e.g., daily
scrums, retrospectives, or pair programming).
Psychological Safety Psychological safety is defined as “a shared belief held by members of a team Edmondson (1999)
that the team is safe for interpersonal risk taking” (Edmondson, 1999, p.
354), meaning that team members are more likely to engage in behaviors
such as seeking feedback, asking for help, speaking up about concerns
or mistakes, or coming up with innovative ideas when psychological safety
is high.
Performance Composed of on-­time completion, on-­budget completion, software Lee and Xia (2010)
functionality, and resilience. Resilience describes how quickly a team is Alliger et al. (2015)
likely to recover or bounce back from failure once failure has occurred. Hashimoto et al. (1982)
Also defined as “being able to withstand disruptive factors, synonymous Chakravarty et al. (2013)
with both buffering against disruptive factors and correcting for disruptive
factors without significant strategic changes” (Chakravarty et al., 2013,
p. 983).
6 Project Management Journal 00(0)

Linking psychological safety with AISD, we argue that sized software development company, focusing on business-­to-­
SAPs foster psychological safety by providing a safe environ- business (B2B) services. Develop1 began to use agile practices
ment for speaking up (e.g., during daily standup meetings or eight years ago, Insure1 and Insure2 both are in the process of
sprint reviews) and by creating a perception of shared responsi- introducing agile practices, which started in both cases a little
bility and mutual support (e.g., via shared code ownership or over a year ago. The main unit of analysis (i.e., “what” is the
pair programming), because structure (e.g., provided by daily case to be studied) is the team, with team members as subunits.
standup meetings or mentoring during pair programming) is All examined organizational units are based in Germany.
beneficial to psychological safety (Bunderson & Boumgarden, We collected data from various data sources and with differ-
2010). At the same time, research suggests that psychological ent data collection methods. Semi-­structured interviews, proj-
safety plays an important role regarding social interaction in ect documentation, instructional and managerial guidelines,
teams (Baer & Frese, 2003; Detert & Burris, 2007; Liang et al., and field notes were used to generate data. The participants for
2012; Nembhard & Edmondson, 2006). Especially with regard the semi-­structured interviews were sampled to cover common
to the emphasis SAPs place on social interaction, psychological roles in AISD projects (see Table 3), but also to interview those
safety acts as an enabler for SAPs, by empowering team mem- team members, which can give detailed insight in and an over-
bers to speak freely with one another, cooperate, and resolve view of current and recent projects. Supplementary documenta-
conflicts (Roberge & van Dick, 2010). Taken together, this tion, such as project and team descriptions, as well as internal
results in proposition P2: guidelines, were used to identify suitable participants. An inter-
view guideline (Appendix A) served as a rough structure, with
P2: Increased usage of social agile practices positively room for deviation and probing questions, and each interview
affects psychological safety, and increased psychological safety proceeded individually. The interview guideline was not shared
enforces the use of social agile practices. with the interviewees and we only used it as a checklist and
outline. The aim was to encourage the interviewees to provide
Building upon this argument for P2, psychological safety not a narrative of their experiences as freely as possible. We inter-
only enforces SAPs, it is a prerequisite for SAPs to unfold their viewed both project managers and project workers.
positive effects. Without feeling safe to voice concerns (e.g., Administrative documents, work descriptions, interview tran-
during reviews or pair programming), SAPs are destined to be scripts, and field notes were collected in a case study database.
less successful than when team members feel safe to engage in We collected data from July 2018 to August 2018 while con-
SAPs. P3 resembles this proposition: ducting 13 face-­to-­face interviews at the companies’ sites (see
Table 3). All participants of Insure1 and Insure2 were part of an
P3: Psychological safety enables and enforces the positive agile transformation team, enabling us to gain an overview over
effect of social agile practices on performance. all agile teams and, more importantly, were able to tell us about
any lessons learned. All participants from Develop1 were part
of a development team.
Research Design While loosely following the guideline, space for probing
and open questions was available. During these interviews, the
Case Overviews and Data Collection participants were asked about the implemented agile practices
To test our propositions and evaluate our proposed model, we and about teamwork in general. Furthermore, we asked partici-
conducted an embedded, confirmatory multiple-­case study pants about their perceptions of the applicability and success of
(Dubé & Paré, 2003; Lee, 1989b; Yin, 2003, p. 49) within three agile practices as well as team climate and interactions among
different case organizations (see Table 2). The cases were sam- team members. Our guidelines were derived from extant litera-
pled following a joint literal (conditions of the case lead to pre- ture. The interviews lasted about 60 minutes and were recorded
dicting the same results) and theoretical replication logic and transcribed. This resulted in about 169 recorded transcript
(conditions of the case lead to predicting contrasting results). pages (sheet size DIN A4). Follow-­up emails were sent to
The two similar cases are set in large insurance companies request clarifications and to offer informants the possibility to
(Insure1 and Insure2), one of which is active internationally provide feedback and comments.
and one only nationally. The third case (Develop1), selected as The interview protocol and guideline were checked against
a deliberate theoretical contrast, is set in a small-­to-­medium Bouchard (1976) and Mishler (1986). The guideline was

Table 2.  Case Site Overview

Name Industry Size State of Agile Adoption

Insure1 Insurance Large, international company Agile transformation in progress

Insure2 Insurance Large, national company Agile transformation in progress
Develop1 B2B Software Development Small-­to-­medium sized company Adopted since founding in 2010
Hennel and Rosenkranz 7

Table 3.  Interviewee Overview

Experience in …

Name Case Role/Assignment AISD ISD

I1-1 Insure1 Specialist for IT portfolio management in the agile transformation team >2 years >10 years
I1-2 Insure1 Specialist charged with initial setup of soon-­to-­be agile teams >2 years >10 years
I1-3 Insure1 Specialist for change management in the agile transformation team >2 years >2 years
I1-4 Insure1 Specialist charged with creating a team vision in the agile transformation team >5 years >5 years
I2-1 Insure2 Team leader of the agile transformation team >2 years -
I2-2 Insure2 Product architect and scrum master >3 years -
I2-3 Insure2 Specialist for quality assurance >2 years >5 years
I2-4 Insure2 Program manager for Insure2 >2 years >10 years
I2-5 Insure2 Specialist for strategy and enterprise architecture in the agile transformation team >2 years -
SW-1 Develop1 Scrum master 4 years 4 years
SW-2 Develop1 Specialist for software and application architecture 4 years 4 years
SW-3 Develop1 Developer and tester 4 years 4 years
SW-4 Develop1 Developer 4 years 4 years

Note. Experience in AISD and ISD in general were collected via a voluntary questionnaire. Where participants did choose to not fill out this questionnaire,
the experience was derived from the dates mentioned during the interviews and marked with “–” where no data was found.

especially checked regarding the sequence of questions; how- (e.g., field notes, instructional material/managerial guidelines).
ever, since the interviews were basically open, as few direct The theoretical constructs of SAPs (Hummel et al., 2015) and
questions as possible were asked and leading questions were psychological safety (Edmondson, 1999) served as guidelines.
avoided (Loftus, 1975). The second coding step in our coding process follows
hypothesis coding, which is suitable for testing purposes, espe-
cially to test for rules, causes, and explanations (Russell
Data Analysis Bernard, 2002; Saldaña, 2016; Weber, 1990). Furthermore,
Coding techniques and checklists (Miles & Huberman, 1994b, hypothesis coding can be applied in a later coding stage to con-
pp. 170–244; Yin, 2003, pp. 109–138) were afterwards used to firm or disconfirm developed assertions—as is the case for this
connect data with constructs from our model and the proposi- study (Saldaña, 2016). In this step, we aimed at identifying
tions. The data analysis process is outlined in Figure 2. We used statements in the conducted interviews and supplemental mate-
the software MaxQDA for coding our data. Following Saldaña rial (e.g., field notes, instructional material/managerial guide-
(2016), we applied different coding strategies. At the core is the lines) to support or reject our propositions. Once again, the
task of conceptualization, that is, “the process of grouping sim- theoretical constructs of SAPs (Hummel et al., 2015) and psy-
ilar items according to some defined properties and giving the chological safety (Edmondson, 1999) served as guidelines for
items a name that stands for that common link” (Strauss & coding the interviews. Further, we used supplementary data
Corbin, 1998, p. 121). As coding can be seen as a “cyclical act” sources (as mentioned above) to set participants’ statements
(Saldaña, 2016), our coding process therefore can be distin- into clearer context.
guished between a first and second step. We followed three tactics to increase construct validity (Lee,
First, we derived the codes from extant literature and our 1989b; Yin, 2003, pp. 40–44). We used multiple sources of evi-
proposed model (displayed in Table 4). Extant literature prede- dence (multiple key informants) and established a chain of evi-
termines our codes as, for instance, the sets of available SAPs dence (case study database) during data collection. Furthermore,
are already identified by Hummel et al. (2015) and Tripp et al. all key informants reviewed draft reports of the case study. In
(2016). Based on these predetermined codes, we set out to the data analysis, we addressed internal validity by pattern
identify and refine our proposed constructs by means of pattern matching (linking the propositions and constructs to data from
coding as described by Miles and Huberman (1994a) and the case study database) and explicit explanation building.
Saldaña (2016). Pattern coding is appropriate for the develop- Since this case study was explicitly designed to test the propo-
ment of major themes from data (Miles & Huberman, 1994a; sitions of our model, we used replication logic and theoretical
Saldaña, 2016). These codes are capable to “identify an emer- logic in the setup of multiple cases for ensuring external valid-
gent theme” and therefore are helpful for “grouping those sum- ity. The multiple-­case study design was explicitly chosen to
maries into a smaller number of sets, themes, or constructs” ensure analytical generalization. For addressing reliability, for
(Miles & Huberman, 1994a, p. 69). This analysis was per- each case in this study, we collected transcripts and protocols
formed on the conducted interviews and supplemental material from the interviews. Following Dibbern et al. (2008) and based
8 Project Management Journal 00(0)

Figure 2.  Coding process with illustrations.

on Dubé and Paré (2003), Appendix B gives a detailed over- “The wonderful thing is that you don’t have to be afraid that
view about the attributes used to assess the case study’s rigor. some statement will be used against you, because you might be
evaluated thereafter.” (I1-2, Q2)

Results “It is very important to me ... that they know that I am a totally
open guy ... and that they can and should say everything they
The main coding matrix resulting from our analysis is dis-
care about.” (I2-1, Q3)
played in Table 4. Depending on the frequency and clarity of
identified codings in our data, we labeled the vividness of each “Yes, it’s very friendly here, very humane.” (SW-1, Q4)
code as either high (i.e., found often and clearly) or low (i.e.,
found seldom and/or only indirectly). As can be seen, all three
The few instances in which a less safe environment was
cases implement a similar, yet different set of agile practices.
mentioned were either in relation to situations before the agile
During the interviews, we asked the participants to reflect on
transformation:
their specific circumstances, especially their set of SAPs. Also,
the levels of psychological safety are slightly different between
“[if someone made a mistake, ...] there was often the escalation
the cases. However, all three cases aim for a high level of psy-
toward project management before.” (I2-5, Q5)
chological safety:

“It is very important to Insure1 that employees can always give or in relation to (emotional or task) conflicts, which arose at
their honest opinion.” (I1-1, Q1) the very beginning of the agile transformation process due to
Hennel and Rosenkranz 9

Table 4.  Identified Codes and Codings

Code Group Code Insure1 Insure2 Develop1

Social Agile Practices* Daily Standups high high high

Reviews and Retrospectives high high high
Pair Programming low high low
Sprint Planning and Prioritization high high high
Collective Code Ownership - - high
Cross-­Functional Teams high high high
... affect Psychological Safety high high -
... affect Performance high high high
Psychological Safety Safe environment high high high
Neither safe nor unsafe environment low - high
Unsafe environment low low -
... affects SAPs high high high
... moderates SAPs → Performance high high high
Performance ... increased with SAPs high high high
... decreases with SAPs low low -

Note. * Of all SAPs, only the codes that were found are listed. (“high” marks a code that was identified clearly and often; “low” marks a code that was
identified seldom and/or only indirectly)

the increased transparency and interdependency of work but “[there are some who] were very hostile and played with prej-
always were resolved later on: udices [in the beginning] who now [after some successful proj-
ects, ...] if something goes well, say ‘sure, we did that the agile
“Partly where it was simply a matter of not including some peo- way.’” (I1-4, Q9)
ple who felt that they were being overlooked, and that actually
led to conflicts ... These were both, personal conflicts as well as As becomes clear through these statements, transparency
professional ones. ... However, the team often found this reso- was a critical factor in the agile transformation and plays an
lution process very fruitful. One has developed a joint solution important role in successful AISD, as, for example a facilitator
and thus there is a better feeling later. Everyone has contributed for trust, communication, and knowledge sharing (Laanti et al.,
and is involved. Everyone has a bringing-­us-­together function, 2011; McHugh et al., 2011).
so the team is more connected.” (I1-4, Q6) In regard to our propositions and as displayed in Table 4, we
found support for all three propositions as displayed in Figure 1
An important aspect in these statements is set in comparison and outlined in the section. Support for proposition P1 can be
to the “before agile” state of the organization. As will become found in all three cases:
clear in the following paragraphs, the overall situation painted
by the participants was positive and accepting; although some “In my opinion, Scrum helps to really deliver quality.” (I2-2,
hurdles had to be overcome, and the transformation into agile Q10)
ways was sometimes perceived as difficult. For instance, two of
“I know they [the team] perform and that we’re in roll-­out now.
three cases showed a partial negative effect of SAPs on
And obviously—it worked.” (I2-5, Q11)
performance:
“And towards the end, we had actual change requests. [...]
“There were also team members who said, ‘this [our set of prac- There you can see the complete harmony between what I ex-
tices] is all nonsense and does us no good.’” (I1-1, Q7) pected and what I got.” (I2-5, Q12)

However, these team members changed their attitude later Similarly, proposition P2 is supported by two of three cases.
on or their attitude was based on fear for increased transpar- One aspect, as identified by I1-3, is that by “forcing” people
ency on their work: together, by promoting social interactions, people are more
likely to develop a common understanding:
“That is a safeguard, some do not want to make their work
transparent [e.g., by participating in daily standup meetings], “You can’t avoid each other. ... You’re already working things
because then one would see what someone is doing and what out together. You must at least create a basic understanding to-
not.” (I1-4, Q8) gether and through this you must speak a common language
10 Project Management Journal 00(0)

[e.g., during retrospectives]. So, we have invested a lot of time “This is the agreement: You do your thing. I trust you, and I got
in a common understanding ... However, I believe that this is your backs—and this deal unfolds creativity and motivation.
very valuable in the long term.” (I1-3, Q13) It’s not easy to copy [practices by the book] because it’s based
on rather soft factors.” (I2-5, Q21)
I2-5 made a very similar argument. He thinks that an itera-
tive approach, combined with learning and a common vision Finally, we see support for proposition P3 in all three cases
help in establishing trust: as well. Some statements were less clear:

“All this didn’t work overnight. It has gone through a process “I think that this [i.e., Scrum-­like practices] works very well, as
and trust has been built up among each other. And you can ac- long as you have a Scrum team, which works well as a team.”
tually say that people have grown more attached to each other (I2-2, Q22)
and what you produce here as a product ... that can be sold on
the market, that’s their baby. They developed a deep identifica- which hint at a trusting and friendly (i.e., psychologically
tion with their work [after the introduction of agile practices].” safe) team as a prerequisite for success of AISD practices.
(I2-5, Q14) Other statements were clearer but discussing the effects of low
psychological safety:
Further support for proposition P2 can be found in all three
cases. Insure1’s internal guidelines document core organiza- “Sure, it becomes very transparent how I do something, how I
tional values close to the four values postulated in the Agile work. ... you also have to share a lot [e.g., during retrospectives].
Manifesto, and participants of Insure1 were especially outspo- And that’s just difficult for many people at first.” (I1-2, Q23)
ken about the effects of a safe environment on the agile
“Sometimes there was pure rejection and statements like ‘we have
practices:
tried agile before and it didn’t work.’ If you look more closely and
ask what went wrong—this had nothing to do with Scrum or the
“Colleagues should simply be open—to new topics and simply methodology, but rather with [affective and task-­related] conflicts
have fun trying things out.” (I1-2, Q15) in the team that had not been resolved.” (I1-4, Q24)
“I think to be able to work really well together; it is important
to be part of the team.” (I1-3, Q16) On the other hand, we found similarly clear statements dis-
cussing the effects of high psychological safety in Develop1.
Asked about the most important success factors for the success
The cyclical relationship between psychological safety and
of their agile implementation, SW-1 said:
SAPs, as described in P2, has been raised by participants as
well:
“Communication, honesty, and candor.” (SW-1, Q25)
“Many have not yet understood this concept of a learning organi-
zation either. ‘Why do you do this different now again?’ ‘We’ve These three factors are all linked to psychological safety, as
only just gotten used to the old way. Why does it have to be any psychological safety is based around honesty and candor and
different now?’ And these constant changes over and over again, improves communication.
that is just really difficult for some people.” (I1-2, Q18) Combining all statements, we find support for all our propo-
sitions, which leads to implications for both research and prac-
tice and opens new avenues for future research.
However, this resistance can be tackled by employing
change management tactics. The same applies for the partially
negative effects of SAPs mentioned beforehand. For instance: Discussion, Implications, and Limitations
“Just look at the team a bit, have a little more sense for the
As AISD methods rely heavily on team work, communication,
needs. And you have to sell why you want to do it this way.”
interpersonal relationships, and social interaction in general (Beck
(I1-3, Q19)
et al., 2001; Lee & Xia, 2010; Maruping, Venkatesh et al., 2009;
Rosenkranz et  al., 2013; Sawyer et al., 2010), a supportive,
friendly, and open environment is clearly a hotbed for successful
Insure2 reiterates that psychological safety influences their AISD implementation. Further, we found evidence for the influ-
way of work and the selection of SAPs: ence of SAPs on performance in general (e.g., Q10) and resilience
in particular (e.g., Q12). We outlined in the previous section and
“In the end, we simply encourage the team members to get in- displayed in Table 4 the support for all our propositions, espe-
volved and perhaps make suggestions on how to improve pro- cially for the importance of psychological safety—leading to a
cesses [and practices].” (I2-4, Q20) supportive, friendly, and open environment. It is demonstrated
that psychological safety can play a role in making SAPs more
Hennel and Rosenkranz 11

effective, and that effective SAPs can add to the sense of psycho- P3 : Psychological Safety Enables and Enforces the
logical safety experienced by agile team members. Positive Effect of SAPs on Performance
Based on the statements in our data set, we are confident that
this finding is robust. We identified strong support for the
Discussion of Propositions enabling effect of psychological safety across all cases. Further,
In the following section, we will take a closer look into each of as this effect is not cyclical as is proposition P2, we believe that
our propositions regarding the identified support and the this effect is even more robust.
respective transferability. In regard to transferability, we see agile teams as the core
beneficiaries of this effect. However, we could believe other,
non-­agile practices and routines, which rely on social interac-
P1: Usage of Social Agile Practices Positively Affects tion, to be heavily impacted by psychological safety—at least
Performance by psychological safety as a moderator of any positive effects
As pointed out in our results section, we found clear support derived by said practices and routines.
for our proposition P1. While the usage of these practices
sometimes led to a—temporary—decrease in performance
(e.g., due to an increase in need for communication), ulti- Consolidation
mately, interviewees reported an increase in performance due The collected data suggest that psychological safety plays two
to the usage of SAPs compared to their previous, waterfall-­ significant, cyclical roles in AISD. First, psychological safety
driven approach. Our main focus was on the overall usage of determines if team members accept SAPs (e.g., Q18). If psycho-
SAPs, rather than the how and how often usage of singular logical safety is low, team members are less likely to partake in
practices. Nevertheless, we found evidence for the impor- planning meetings and retrospectives. If, in contrast, psychologi-
tance of careful and conscious adoption and implementation cal safety is high, team members are more likely to accept SAPs
of SAPs. For instance, as reported in Insure1, if team mem- and give them a try. Second, psychological safety determines how
bers slip on their participation of daily standup meetings, the team members participate in SAPs (e.g., Q22). If psychological
beneficial effects of regular meetings cannot be realized. We safety is low and they do participate in SAPs, they are less likely
decided not to include this finding as a proposition, as it would to speak their minds, are less likely to give valuable input to
go beyond the scope of this study. achieve successful outcomes, and are less likely to offer ideas for
While this effect cannot be translated to purely traditional, continuous improvement. In contrast, a higher psychological
non-­agile projects, it can be transferred to any project imple- safety leads to more engagement, more helping behavior, and an
menting SAPs, regardless of the underlying software develop- increased willingness to offer new ideas and give valuable input,
ment methodology or ideology. which ultimately leads to improved outcomes and a learning
organization.
P2 : Increased Usage of Social Agile Practices However, if psychological safety is low, it can be improved
Positively Affects Psychological Safety and Increased and strengthened by implementing SAPs carefully (e.g., Q13).
Psychological Safety Fosters the Use of Social Agile As we have seen in the previous section, it is important to apply
Practices change management tactics and listen to the needs and con-
The previous section gives examples for the strong support we cerns of team members.
found for P2. However, some interviewees pointed out that the Taken together, these two roles stress that, while SAPs rely on
way in which SAPs were introduced and overseen by, for and are influenced by psychological safety, psychological safety
instance, the scrum master, influenced the respective effect on is enforced by SAPs, indicating that SAPs are not static, but to
psychological safety. If SAPs were forced onto the team, psy- some degree dynamic (e.g., Q14) in their implementations.
chological safety did—in some cases—not manifest as quickly These findings extend previous research on social aspects of
and strongly as in others. agile practices (especially Hummel et al., 2015) by explaining
This specific effect can only be observed in teams engaging the surrounding context (in this case psychological safety) of
in SAPs; however, we found no evidence suggesting that the successfully implemented SAPs. As put by Niederman et al.
underlying task domain would play a role for this effect. We (2018), conflict and conflict resolution differ in AISD from tradi-
further assume that the effect is especially visible in any prac- tional approaches. Psychological safety may explain when and
tices focusing strongly on social interactions (e.g., retrospec- why conflict can be beneficial to AISD teams.
tives), due to the implied hierarchy and power structure when
forcing a practice onto a team. It is important to note that a
forced usage of SAPs (e.g., by publicly shaming team members
Future Research and Implications
into cooperation) might very well further decrease psychologi- This study opens up new avenues for future research. Having
cal safety over time, turning this effect into a downward spiral. support for the influence of psychological safety means that
However, we found no indication of this trend occurring in our research now should investigate in more detail which boundary
sample. conditions are in effect for psychological safety to influence
12 Project Management Journal 00(0)

SAPs. Furthermore, a quantitative evaluation of this model being inclusive and open toward team members helps in creat-
could yield additional insights. Due to the qualitative nature of ing a psychologically safe environment (Edmondson, 1999;
this study, we have only limited indication for the strength and Nembhard & Edmondson, 2006). Raising psychological safety
significance of the identified effects. Additionally, future in the team not only benefits team performance, it also raises
research might look into the details of the “how” and “how job satisfaction (Bergheim et al., 2015) and should therefore be
often” of SAP usage, as we did find evidence for the significant in every team member’s own interest. Therefore, a psychologi-
effect of how and how often an SAP was adopted, implemented, cally safe environment appears to be extremely important to
and used. While the interviews indicate significant and strong successful implementation of AISD methods. This means that
effects, a quantitative follow-­up study would increase the con- before and during an agile transformation, an open and honest
fidence in our results. Methodological replication studies out- environment without fear for retribution or penalties has to be
side of the task domain of software development might further created and reinforced. Furthermore, practitioners should be
define and refine the boundary conditions of our findings and aware of the cyclic relationship between SAPs and psycholog-
help in building trust to our argumentation for transferability of ical safety. While psychological safety is an important factor
our findings to different task domains. While our study was for successful AISD implementation, SAPs enforce psycholog-
conducted in a new product development setting, all partici- ical safety, and psychological safety influences the engagement
pants worked in software-­related new product development of team members in SAPs and their selection of preferred
projects. While software- and non-­software based new product SAPs. This concept of a learning organization is seen as a threat
development projects share many similarities (e.g., unclear or by some team members, but with appropriate change manage-
at least changing requirements), they have differences. For ment, this constant process refinement can be beneficial to both
instance, software can often be modified cheaply even after the team members and the organization as a whole.
end user has started using the product—modifying an in-­use,
non-­software product is distinctly more costly and difficult.
These differences might lead to different findings in a non-­
Transferability to General Project
software new product development project and might be a Management
fruitful avenue for future research. Additionally, we see an ave- Industrial practice has not only identified social aspects as
nue for future research on the applicability of our findings in important drivers for success in AISD (e.g., McGregor &
other task domains and industries, as all of our cases worked on Doshi, 2018), but also reports of successful implementation
new product development tasks in the insurance industry. and adaptation of agile approaches surface as well (e.g., Rigby
Another, possibly fruitful avenue for future research might be et al., 2018). More specifically, agile is considered harmful if
an interaction between psychological safety and team resil- implemented superficially—if teams cannot experiment and
ience directly. While we did not find direct evidence in our data manage themselves, they stop learning and stop putting their
or our literature review, one might imagine an interaction best efforts into their work (McGregor & Doshi, 2018). An
between these two concepts, possibly over time. environment of high psychological safety is therefore needed to
For practitioners, these results have important implications reap the benefits of agile approaches, especially in uncertain or
as well. When considering using agile practices for AISD proj- changing environments—and for these environments, indus-
ects, the increased social aspect should be considered in addi- trial practice has seen success in implementing agile approaches
tion to established characteristics. If an environment with lower outside of software development. For instance, a company in
psychological safety can be assumed, AISD practices are likely engineering and construction was able to succeed in a business
to not fulfill their potential and might harm the process. When turnaround following a crisis of declining demand by imple-
considering transforming to an agile approach or implementing menting agile practices as a new way of work, resulting not
AISD practices, managers should, in addition to the previous only in reduced costs, but also in an increase in employee moti-
point, consider the additional tension a transformation might vation and acquired skill sets (Rigby et al., 2018).
bring to those who are adjusted to, for instance, a waterfall While our interviews were set in a software development
method. These tensions might need additional consideration, context, we strongly believe that our findings are transferable to
preparation, and an even higher level of psychological safety, agile teams in other task domains. Most interviewees from
compared to a new team. When already using AISD practices— Insure1 stated that they have experience working outside of
but the team members might not participate or if these practices software development as task domain and indicated that their
appear useless—managers might take a closer look at the psy- experiences regarding SAPs and psychological safety were not
chological safety in the team in general and during the execu- exclusive to the software development task domain. While
tion of these practices. As presented in the results section, some some SAPs, such as pair programming, are specific to software
team members might not feel safe (enough) to participate in development, substitutes exist (e.g., pair writing). Furthermore,
SAPs. Similar to managers, team members themselves could as agile approaches in general (and therefore AISD practices),
benefit from checking the psychological safety in their teams are increasingly diffused from information systems develop-
as, ultimately, every team member contributes to the team cli- ment to other domains, our findings help in understanding these
mate and psychological environment. As literature suggests, mechanisms of action not only in the AISD domain and might
Hennel and Rosenkranz 13

help in more direct and effective implementation of AISD prac- deeper into this issue and to try to isolate the effects of psycho-
tices inside and outside of information systems development. logical safety in AISD teams, for instance, via controlled
What these previous paragraphs amount to is the importance interventions.
of a supportive, friendly, and open environment, especially in The fifth limitation is the influence of social desirability
teams working in highly volatile and changing environments, bias, as it is generally more socially desirable to report success
or teams transitioning to agile approaches. To sum up, our find- rather than failure. Nederhof (1985) suggests postulating ques-
ings are applicable to general project management in that we tions that are neutral. We tried to minimize the social desirabil-
showed an interaction of SAPs on psychological safety, which, ity bias emerging from our questions. However, due to the clear
in turn, affects transparency, communication, and ultimately preferability of success over failure, social desirability bias was
productivity. It follows that any intervention (such as SAPs) still likely to emerge from questions during our interviews.
that increases psychological safety might solve transparency
and communication issues and can benefit productivity.
Conclusion
In this article, we constructed and argued for a novel model,
Limitations explaining the interplay between psychological safety and AISD
practices. As explained earlier, we were able to show that psycho-
This study is not without limitations. First, this study considers
logical safety is a critical success factor for agile teams. With the
only three different cases, two of which are similar in industry,
diffusion of agile practices outside of the domain of information
size, and state of agile adoption. The third, as the sole contrast-
systems development, our findings provide insights for general
ing case, has only limited explanatory power. By increasing
project management. However, due to the discussed limitations,
the number of cases, our findings could be refined and gain in
future research on team-­level effects in AISD is needed to further
validity if confirmed. Second, all three companies are based in
improve AISD, reducing the number of failed AISD projects, and
Germany, with only one company being part of an interna-
to review the applicability of our findings in additional contexts.
tional organization. Future research could conduct similar
studies in other countries and cultural regions to evaluate the
influence of cultural aspects on the importance of psychologi- Appendix A
cal safety. Third, we did not conduct interviews with every This interview protocol served as a rough guideline in the inter-
team member. It is likely that the perceptions of the specific views. However, most of the interviews followed a natural, but
team’s level of psychological safety and its influence on the individual course.
success of SAPs vary. We believe this difference to be of only
peripheral nature and to not have a significant effect on our
conclusions due to the very homogeneous nature of the state- Background
ments in all interviews. Similarly, we cannot rule out that in
some cases, we have identified a side effect as a cause, due to • Please tell us about yourself; your background; your role
the nature of a field experiment—for instance, we cannot in the team
determine if psychological safety benefitted from having regu- • Please tell us about the business unit within your organization:
lar meetings or having everyone participating in every meet- ◦ What is the overall structure of the unit?
ing. However, as our cases were similar, yet not identical (e.g., ◦ Is the use of certain tools and practices mandatory?
not all teams in Insure1 had everyone always participate, oth- ◦ What discretion do project team members have in
choosing the technologies and practices they will use?
ers did), we are confident in the reliability and validity of our
findings. Future research might still be able to strengthen the ◦ Is there a formal development methodology espoused
by the organization?
trustworthiness of our findings. Furthermore, our study is lim-
ited by the single pathway in a complex nomological network ◦ Please describe what you perceive as the most import-
ant success factor for your team with respect to effec-
described. It is unclear if SAPs always interact with psycho-
tive and efficient software development within your
logical safety and if this (perceived) psychological safety is
organization.
not determined by—possibly stronger—outside effects. The
same limitation applies for the observed influence on perfor-
mance. A great deal of outside effects (e.g., team members’ Assessment of Current Practice—Activities and Routines
capabilities, market forces) might affect performance stronger
and more significantly than the effects of SAPs and psycholog- • How far along is the project? At a very high level, could
ical safety. This all leads to the issue that psychological safety you walk me through the history of the project and the
is a very broad concept, making it possible to find influences future plans for the project?
on many different aspects of teamwork. However, we do think • Please tell me about the structure of your team and the
that our reasoning for these specific effects is sound and signif- regular activities within your team—who does what and
icant. We would nevertheless suggest future research to dig why?
14 Project Management Journal 00(0)

• What are the (key) roles (e.g., scrum master, agile coach, • Do you think team members trust each other?
project manager) or positions on this project? • Do you feel controlled?
• What are the (key) activities (e.g., dailies, retrospectives) • Do you think team members have always in mind what is
in this project? best for the team?
• How do team members communicate within the project? • How are your personal/project outcomes judged? Is this
◦ Which media or tools are used? somehow linked to your pay schedule?
◦ Are there any expectations with respect to who should • Do you think that flexibility and/or personal discretion
or may speak to whom? are important for the overall outcomes of your team?
◦ Do team members talk freely to one another—do they • Do you perceive any tension between the need for control
talk only about work-­related topics or also about personal and the allowance of flexibility in the team’s daily work
topics? Do team members know each other personally? routines?
• Who defines, selects, and oversees the activities and • Do you think that some control is beneficial to the overall
routines that are used on the project? outcomes of your team?
◦ How do those individuals ensure that the activities and
routines are carried out in the way that they prefer?
◦ How would you characterize the interaction between Requirements Changes
these individuals and other members?
• In your perception, why does the team work in the way • Did you perceive requirements changing during the
that it does? Is it a formal rule, an informal convention, project? In your opinion, what were the reasons for it?
or was it always done this way? • Do you think that these changing requirements may also
result in technical and managerial issues?
• Are these work practices and ways of interacting similar
to other projects that are going on right now? Is it the • During times of high time pressure—did someone “take
same as historical ways of doing things? the lead” to organize the team or did everyone proceed
as usual? Did people change in their behavior or role
• Has anyone proposed changes to the work practices or
enactment?
ways of interacting employed on this project? If so, why?

Psychological Safety and Trust/Personal Perceptions of Resilience

Control
• Do you think the team is able to recover quickly (using
little to no time, resources, etc.) from unforeseen crises/
• How do you think team members feel in your team? Do events shocks (e.g., requirement changes)?
they feel free to express unconventional or new ideas/
voice concerns/raise tough issues? • If an unforeseen crisis/event/shock occurs, how does
the team react? Do people act differently? Do routines
• Do you think team members feel valued?
change?
• Do you think it is easy for team members to ask each
• How do you perceive the diversity of your team—
other for help?
regarding skill sets/regarding gender, ethnicity, culture,
• Do you think team members feel that their mistakes
and so forth?
might be held against them?

Appendix B
Attributes Used to Assess the Case Study (Dibbern et al., 2008; Dubé & Paré, 2003).

Research Design

Nature of study Positivist, explanatory study recognizing subjective and interpretive elements in every research
(cf. Lee, 1989a, 1989b, 1991).
Clear research questions Yes.
A priori specification of constructs Yes (explanatory character).
Clean theoretical slate No, propositions were formulated a priori (explanatory character).
Theory of interest Psychological safety
Rival theory included No, because it was the first test of the model.
Multiple case design Yes, three organizations with multiple projects, with every project representing a case (with
multiple projects embedded).
Replication logic Both theoretical and literal replication logic.
(Continued)
Hennel and Rosenkranz 15

Research Design
Unit of analysis Projects in three different companies; however, all case studies are embedded and involve more
than one unit of analysis. This occurs when, within a single case, attention is also given to a
subunit or subunits. Although the specific projects represent the main unit of analysis, the
individual project team members represent a subunit. Any subunit is part of/or embedded in
the larger system (i.e., project) and it is important to understand the subunits in the larger
system.
Pilot case Not conducted, since it is highly recommended for exploratory studies only.
Team-­based research Yes, three researchers.
Different roles of investigators First author and another researcher undertook data collection. First author and another
researcher coded and interpreted the data independently before discussing and resolving
differences. Second author acted as discussant and challenger for the data.
Context Description
Detailed site description Yes.
Case period The case material was collected during a period of two months with several on-­site visits and
telephone calls.
Longitudinal design No.
Time spent on-­site by the researchers Yes, for setting up the case study design, for conducting interviews.
Nature of data collection Both retrospective and ongoing.
Data Collection Process
Multiple data collection methods Yes, data were solicited from different stakeholders via interviews; administrative documents,
work descriptions, printouts of project reports, interview transcripts and field notes were
collected and added to the analysis.
Qualitative and quantitative data Mostly qualitative.
Data triangulation Yes.
Case study protocol Yes.
Case study database Yes, using MaxQDA and Microsoft Excel.
Data Collection Methods
Interviews Yes.
Documentation Yes (e.g., administrative documents for project and interviewee selection).
Observation No.
Questionnaires No.
Artifacts No.
Time series No.
Sampling strategy Convenient sampling and quota sampling for the interview participants (three organizations that
offered access to projects).
Data Analysis Process
Field notes Yes.
Coding Yes, coding techniques and checklists were used to connect data with the propositions.
Data displays Yes.
Flexible and opportunistic process Yes.
Logical chain of evidence Yes.
Empirical testing Yes.
Explanation building Yes.
Time series analysis No.
Searching for cross-­case patterns Yes.
Use of natural controls Yes; focusing on informants that participated in more than one of the projects.
Quotes (evidence) Yes.
Project reviews Yes.
Comparison with extant literature Yes.

Declaration of Conflicting Interests Funding

The author(s) declared no potential conflicts of interest with respect to The author(s) received no financial support for the research, authorship,
the research, authorship, and/or publication of this article. and/or publication of this article.
16 Project Management Journal 00(0)

References Cao, L., Mohan, K., Xu, P., & Ramesh, B. (2009). A framework for
adapting agile development methodologies. European Journal
Alliger, G. M., Cerasoli, C. P., Tannenbaum, S. I., & Vessey, W. B. (2015).
of Information Systems, 18(4), 332–343.
Team resilience. Organizational Dynamics, 44(3), 176–184.
Carmeli, A., & Gittell, J. H. (2009). High-­ quality relationships,
Baer, M., & Frese, M. (2003). Innovation is not enough: Climates for
psychological safety, and learning from failures in work
initiative and psychological safety, process innovations, and
organizations. Journal of Organizational Behavior, 30(6), 709–729.
firm performance. Journal of Organizational Behavior, 24(1),
Chae, B., & Poole, M. S. (2005). The surface of emergence in
45–68.
systems development: Agency, institutions, and large-­ scale
Balijepally, V., Mahapatra, R., Nerur S., & Price, K. H. (2009). Are
information systems. European Journal of Information
two heads better than one for software development? The
Systems, 14(1), 19–36.
productivity paradox of pair programming. MIS Quarterly,
Chakravarty, A., Grewal, R., & Sambamurthy, V. (2013). Information
33(1), 91–119.
technology competencies, organizational agility, and firm
Bardoel, E. A., Pettit, T. M., De Cieri, H., & McMillan, L. (2014).
performance: Enabling and facilitating roles. Information Systems
Employee resilience: An emerging challenge for HRM. Asia
Research, 24(4), 976–997.
Pacific Journal of Human Resources, 52(3), 279–297.
Chow, T., & Cao, D.-B. (2008). A survey study of critical success
Batra, D., Xia, W., & Rathor, S. (2016). Agility facilitators for
factors in agile software projects. Journal of Systems and
contemporary software development. Journal of Database
Software, 81(6), 961–971.
Management, 27(1), 1–28.
Cockburn, A., & Highsmith, J. (2001). Agile software development,
Bear, J. B., & Woolley, A. W. (2011). The role of gender in team the people factor. IEEE Computer, 34(11), 131–133.
collaboration and performance. Interdisciplinary Science Conboy, K. (2009). Agility from first principles: Reconstructing the
Reviews, 36(2), 146–153. concept of agility in information systems development.
Beck, K., & Andres, C. (2004). Extreme programming explained: Information Systems Research, 20(3), 329–354.
Embrace change (2nd ed.). Addison-­Wesley Professional. Corvera Charaf, M., Rosenkranz, C., & Holten, R. (2013). The
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., emergence of shared understanding: Applying functional
Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., pragmatics to study the requirements development process.
Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Information Systems Journal, 23(2), 115–135.
Sutherland, J., & Thomas, D. (2001). Manifesto for agile software Cule, P., Schmidt, R., Lyytinen, K., & Keil, M. (2000). Strategies for
development. http://www.​agilemanifesto.​org/. heading off is project failure. Information Systems Management,
Bergheim, K., Nielsen, M. B., Mearns, K., & Eid, J. (2015). The 17(2), 61–69.
relationship between psychological capital, job satisfaction, DeMarco, T., & Lister, T. (1987). Peopleware: Productive projects
and safety perceptions in the maritime industry. Safety Science, and teams. Dorset House Publishing Co., Inc.
74, 27–36. DeSanctis, G., & Poole, M. S. (1994). Capturing the complexity in
Bittner, E. A. C., & Leimeister, J. M. (2014). Creating shared advanced technology use: Adaptive structuration theory.
understanding in heterogeneous work groups: Why it matters Organization Science, 5(2), 121–147.
and how to achieve it. Journal of Management Information Detert, J. R., & Burris, E. R. (2007). Leadership behavior and employee
Systems, 31(1), 111–144. voice: Is the door really open? Academy of Management Journal,
Black, S. E., Boca, P. P., Bowen, J. P., Gorman, J., & Hinchey, M. 50(4), 869–884.
(2009). Formal versus agile: Survival of the fittest. IEEE DevOps Research & Assessment, & Google Cloud. (2019). The 2019
Computer, 42(9), 37–45. Accelerate State of Devops.
Boehm, B. W. (1988). A spiral model of software development and Dibbern, J., Winkler, J., & Heinzl, A. (2008). Explaining variations in
enhancement. IEEE Computer, 21(5), 61–72. client extra costs between software projects offshored to India.
Boehm, B., & Turner, R. (2004). Balancing agility and discipline: MIS Quarterly, 32(2), 333–366.
A guide for the perplexed. Addison-­Wesley. Diegmann, P., Dreesen, T., Binzer, B., & Rosenkranz, C. (2018).
Bouchard, T. J. (1976). Field research methods: Interviewing, Journey towards agility: Three decades of research on agile
questionnaires, participant observation, systematic observation, information systems development [Conference session]. In
unobtrusive measures. In M. D. Dunnette (Ed.), Handbook of International Conference on Information Systems (ICIS 2018),
industrial and organizational psychology (pp. 363–413). Rand San Francisco, CA.
McNally. Diegmann, P., & Rosenkranz, C. (2017). Team diversity and
Bunderson, J. S., & Boumgarden, P. (2010). Structure and learning in performance—How agile practices and psychological safety
self-­managed teams: Why “bureaucratic” teams can be better interact [Conference session]. International Conference on
learners. Organization Science, 21(3), 609–624. Information Systems, Seoul, South Korea.
Byrd, T. A., Cossick, K. L., & Zmud, R. W. (1992). A synthesis of Dikert, K., Paasivaara, M., & Lassenius, C. (2016). Challenges and
research on requirements analysis and knowledge acquisition success factors for large-­scale agile transformations: A systematic
techniques. MIS Quarterly, 16(1), 117–138. literature review. Journal of Systems and Software, 119, 87–108.
Hennel and Rosenkranz 17

Dingsøyr, T., Moe, N. B., & Seim, E. A. (2018). Coordinating Hirschheim, R., Klein, H., & Lyytinen, K. (1995). Information systems
knowledge work in multiteam programs: Findings from a large-­ development and data modeling: Conceptual and philosophical
scale agile development program. Project Management Journal, foundations. Cambridge University Press.
49(6), 64–77. Hoda, R., Noble, J., & Marshall, S. (2011). The impact of inadequate
Dubé, L., & Paré, G. (2003). Rigor in information systems positivist customer collaboration on self-­organizing agile teams. Information
case research: Current practices, trends, and recommendations. and Software Technology, 53(5), 521–534.
MIS Quarterly, 27(4), 597–635. Holling, C. S. (1973). Resilience and stability of ecological systems.
Dybå, T., & Dingsøyr, T. (2008). Empirical studies of agile software Annual Review of Ecology and Systematics, 4(1), 1–23.
development: A systematic review. Information and Software Holmqvist, M., & Pessi, K. (2006). Agility through scenario development
Technology, 50(9-10), 833–859. and continuous implementation: A global aftermarket logistics
Dybå, T., & Dingsøyr, T. (2009). What do we know about agile case. European Journal of Information Systems, 15(2), 146–158.
software development? IEEE Software, 26(5), 6–9. Hong, W., Thong, J. Y. L., Chasalow, L. C., & Dhillon, G. (2011). User
Edmondson, A. (1999). Psychological safety and learning behavior in acceptance of agile information systems: A model and empirical
work teams. Administrative Science Quarterly, 44(2), 350–383. test. Journal of Management Information Systems, 28(1), 235–272.
Eisenberg, E. M., Goodall Jr, H. L., & Trethewey, A. (2013). Organi- Hummel, M., Rosenkranz, C., & Holten, R. (2015). The role of social
zational communication: Balancing creativity and constraint. agile practices for direct and indirect communication in
Macmillan Higher Education. information systems development teams. Communications of the
Ellinger, A. D., & Bostrom, R. P. (1999). Managerial coaching Association for Information Systems, 36, 273–300.
behaviors in learning organizations. Journal of Management Ilgen, D. R., Hollenbeck, J. R., Johnson, M., & Jundt, D. (2005).
Development, 18(9), 752–771. Teams in organizations: From input-­process-­output models to
Freudenberg, S., & Sharp, H. (2010). The top 10 burning research
IMOI models. Annual Review of Psychology, 56(1), 517–543.
questions from practitioners. IEEE Software, 27(5), 8–9.
Janes, A. A., & Succi, G. (2012). The dark side of agile software
Fruhling, A. N. N., & de Vreede, G.-J. (2006). Field experiences with
development [Symposium]. Proceedings of the ACM International
extreme programming: Developing an emergency response
Symposium on New Ideas, New Paradigms, and Reflections on
system. Journal of Management Information Systems, 22(4),
Programming and Software, ACM, 215–228.
39–68.
Jehn, K. A., Jonsen, K., & Rispens, S. (2014). Relationships at work:
Gallivan, M. J., & Keil, M. (2003). The user-­developer communication
Intragroup conflict and the continuation of task and social
process: A critical case study. Information Systems Journal,
relationships in workgroups. Current Topics in Management, 17,
13(1), 37–68.
1–23.
Gerwin, D., & Barrowman, N. J. (2002). An evaluation of research on
Kautz, K., Madsen, S., & Nørbjerg, J. (2007). Persistent problems and
integrated product development. Management Science, 48(7),
practices in information systems development. Information
938–953.
Systems Journal, 17(3), 217–239.
Gorecki, J., Berthon, P., DesAutels, P., Donnellan, B., & Teigland, R.
Ko, D.-G., Kirsch, L. J., & King, W. R. (2005). Antecedents of
(2008). The multinational’s nemesis: The rise of ICT-­enabled
distributed collective intelligence? ICIS 2008 Proceedings, 1–6. knowledge transfer from consultants to clients in enterprise
Gregory, P., Barroca, L., Sharp, H., Deshpande, A., & Taylor, K. system implementations. MIS Quarterly, 29(1), 59–85.
(2016). The challenges that challenge: Engaging with agile Kotlarsky, J. (2007). Re-­engineering at Lecroy corporation: The move
practitioners’ concerns. Information and Software Technology, to component-­based systems. Journal of Information Technology,
77, 92–104. 22(4), 265–278.
Hashimoto, T., Loucks, D. P., & Stedinger, J. R. (1982). Reliability, Kozlowski, S. W. J., & Ilgen, D. R. (2006). Enhancing the effectiveness
resiliency, robustness, and vulnerability criteria for water resource of work groups and teams. Psychological Science in the Public
systems. Water Resources Research, 18(1), 14–20. Interest, 7(3), 77–124.
Healey, M. P., Vuori, T., & Hodgkinson, G. P. (2015). When teams Kraut, R. E., & Streeter, L. A. (1995). Coordination in software
agree while disagreeing: Reflexion and reflection in shared development. Communications of the ACM, 38(3), 69–81.
cognition. Academy of Management Review, 40(3), 399–422. Kroll, P., & Kruchten, P. (2003). The rational unified process made
Heeager, L. T. (2012). Introducing agile practices in a documentation-­ easy: A practitioner’s guide to the RUP (4th ed.). Addison-­Wesley.
driven software development practice: A case study. Journal of Kruchten, P. (2004). The rational unified process: An introduction (3rd
Information Technology Case and Application Research, 14(1), ed.). Addison-­Wesley.
3–24. Laanti, M., Salo, O., & Abrahamsson, P. (2011). Agile methods rapidly
Herbsleb, J. D., & Mockus, A. (2003). An empirical study of speed and replacing traditional methods at Nokia: A survey of opinions on
communication in globally distributed software development. agile transformation. Information and Software Technology,
IEEE Transactions on Software Engineering, 29(6), 481–494. 53(3), 276–290.
Highsmith, J., & Cockburn, A. (2001). Agile software development: Lee, A. S. (1989a). Case studies as natural experiments. Human
The business of innovation. IEEE Computer, 34(9), 120–127. Relations, 42(2), 117–137.
18 Project Management Journal 00(0)

Lee, A. S. (1989b). A scientific methodology for MIS case studies. positive emotions on team performance. Journal of Happiness
MIS Quarterly, 13(1), 33–50. Studies, 17(1), 239–255.
Lee, A. S. (1991). Integrating positivist and interpretive approaches to Miles, M. B., & Huberman, A. M. (1994a). Qualitative data analysis:
organizational research. Organization Science, 2(4), 342–365. An expanded sourcebook. Sage Publications.
Lee, G., & Xia, W. (2010). Toward agile: An integrated analysis of Miles, M. B., & Huberman, A. M. (1994b). Qualitative data analysis:
quantitative and qualitative field data on software development A sourcebook of new methods. Sage.
agility. MIS Quarterly, 34(1), 87–114. Mishler, E. G. (1986). Research interviewing: Context and narrative.
Lengnick-­Hall, C. A., Beck, T. E., & Lengnick-­Hall, M. L. (2011). Harvard University Press.
Developing a capacity for organizational resilience through Nan, N. (2011). Capturing bottom-­up information technology use
strategic human resource management. Human Resource processes: A complex adaptive systems model. MIS Quarterly,
Management Review, 21(3), 243–255. 35(2), 505–540.
Liang, J., Farh, C. I. C., & Farh, J.-L. (2012). Psychological antecedents Nederhof, A. J. (1985). Methods of coping with social desirability
of promotive and prohibitive voice: A two-­wave examination. bias: A review. European Journal of Social Psychology, 15(3),
Academy of Management Journal, 55(1), 71–92. 263–280.
Lindsjørn, Y., Sjøberg, D. I. K., Dingsøyr, T., Bergersen, G. R., & Nembhard, I. M., & Edmondson, A. C. (2006). Making it safe: The
Dybå, T. (2016). Teamwork quality and project success in effects of leader inclusiveness and professional status on
software development: A survey of agile development teams. psychological safety and improvement efforts in health care
Journal of Systems and Software, 122, 274–286. teams. Journal of Organizational Behavior, 27(7), 941–966.
Loftus, E. F. (1975). Leading questions and the eyewitness report. Niederman, F., Lechler, T., & Petit, Y. (2018). A research agenda for
Cognitive Psychology, 7(4), 560–572. extending agile practices in software development and
Long, Y., & Siau, K. (2007). Social network structures in open source additional task domains. Project Management Journal, 49(6),
software development teams. Journal of Database Management, 3–17.
18(2), 25–40. Oxford English Dictionary. (2019). “Resilience.” Oxford University
Mangalaraj, G., Mahapatra, R., & Nerur, S. (2009). Acceptance of Press.
software process innovations—The case of extreme programming. Persson, J. S., Mathiassen, L., & Aaen, I. (2012). Agile distributed
European Journal of Information Systems, 18(4), 344–354. software development: Enacting control through media and
Martin, J. (1991). Rapid application development. Macmillan context. Information Systems Journal, 22(6), 411–433.
Publishing Co., Inc. Phillips, K. W., Northcraft, G. B., & Neale, M. A. (2006). Surface-­
Martins, L. L., Schilpzand, M. C., Kirkman, B. L., Ivanaj, S., & level diversity and decision-­making in groups: When does deep-­
Ivanaj, V. (2013). A contingency view of the effects of cognitive level similarity help? Group Processes & Intergroup Relations,
diversity on team performance: The moderating roles of team 9(4), 467–482.
psychological safety and relationship conflict. Small Group Pohl, K. (1994). The three dimensions of requirements engineering:
Research, 44(2), 96–126. A framework and its applications. Information Systems, 19(3),
Maruping, L. M., Venkatesh, V., & Agarwal, R. (2009). A control 243–258.
theory perspective on agile methodology use and changing user Poppendieck, M., & Poppendieck, T. (2003). Lean software
requirements. Information Systems Research, 20(3), 377–399. development: An agile toolkit. Addison-­Wesley.
Maruping, L. M., Zhang, X., & Venkatesh, V. (2009). Role of collective Project Management Institute (PMI). (2017). A guide to the project
ownership and coding standards in coordinating expertise in management body of knowledge (PMBOK®guide) – Sixth
software project teams. European Journal of Information edition. Author.
Systems, 18(4), 355–371. Przybilla, L., Wiesche, M., & Krcmar, H. (2018). The influence of
McAvoy, J., & Butler, T. (2009). A failure to learn by software agile practices on performance in software engineering teams: A
developers: Inhibiting the adoption of an agile software subgroup perspective [Conference session]. Proceedings of the
development methodology. Journal of Information Technology 2018 ACM SIGMIS Conference on Computers and People
Case and Application Research, 11(1), 23–46. Research, ACM. 33–40.
McAvoy, J., Nagle, T., & Sammon, D. (2013). Using mindfulness to Ramesh, B., Cao, L., & Baskerville, R. (2010). Agile requirements
examine ISD agility. Information Systems Journal, 23(2), engineering practices and challenges: An empirical study.
155–172. Information Systems Journal, 20(5), 449–480.
McGregor, L., & Doshi, N. (2018). Why agile goes awry—And how Recker, J., Holten, R., Hummel, M., & Rosenkranz, C. (2017). How agile
to fix it. Harvard Business Review. https://hbr.org/2018/10/why- practices impact customer responsiveness and development success:
agile-goes-awry-and-how-to-fix-it. A field study. Project Management Journal, 48(2), 99–121.
McHugh, O., Conboy, K., & Lang, M. (2011). Agile practices: The Rigby, D. K., Henderson, S., & D’Avino, M. (2018). How agile teams
impact on trust in software project teams. IEEE Software, 29(3), can help turnarounds succeed. Harvard Business Review. https://
71–76. hbr.org/2018/07/how-agile-teams-can-help-turnarounds-succeed.
Meneghel, I., Salanova, M., & Martínez, I. M. (2016). Feeling good Roberge, M-É., & van Dick, R. (2010). Recognizing the benefits of
makes us stronger: How team resilience mediates the effect of diversity: When and how does diversity increase group
Hennel and Rosenkranz 19

performance? Human Resource Management Review, 20(4), Sweetman, R., & Conboy, K. (2018). Portfolios of agile projects:
295–308. A complex adaptive systems’ agent perspective. Project Manag-
Rosenkranz, C., Charaf, M. C., & Holten, R. (2013). Language quality ement Journal, 49(6), 18–38.
in requirements development: Tracing communication in the Tan, M. (1994). Establishing mutual understanding in systems design:
process of information systems development. Journal of An empirical study. Journal of Management Information
Information Technology, 28(3), 198–223. Systems, 10(4), 159–182.
Rosenkranz, C., Holten, R., Räkers, M., & Behrmann, W. (2017). Tripp, J., & Armstrong, D. J. (2018). Agile methodologies:
Supporting the design of data integration requirements during Organizational adoption motives, tailoring, and performance.
the development of data warehouses: A communication theory-­ Journal of Computer Information Systems, 58(2), 170–179.
based approach. European Journal of Information Systems, Tripp, J., Rienemschneider, C., & Thatcher, J. (2016). Job satisfaction
26(1), 84–115. in agile development teams: Agile development as work
Rosenkranz, C., Vranesic, H., & Holten, R. (2014). Boundary redesign. Journal of the Association for Information Systems,
interactions and motors of change in requirements elicitation: 17(4), 267–307.
A dynamic perspective on knowledge sharing. Journal of the van Kelle, E., van der Wijst, P., Plaat, A., & Visser, J. (2015). An
Association for Information Systems, 15(6), 306–345. empirical study into social success factors for agile software
Royce, W. W. (1970). Managing the development of large software development [Conference session]. Proceedings of the Eighth
systems: Concepts and techniques. Proceedings of WesCon, International Workshop on Cooperative and Human Aspects of
Monterey, CA, USA, pp. 328–338. Software Engineering, IEEE Press, pp. 77–80.
Russell Bernard, H. (2002). Research methods in anthropology-­ van Oorschot, K. E., Sengupta, K., & Van Wassenhove, L. N. (2018).
qualitative and quantitative approaches (3rd ed.). AltaMira Press. Under pressure: The effects of iteration lengths on agile software
Saldaña, J. (2016). The coding manual for qualitative researchers. Sage. development performance. Project Management Journal, 49(6),
Sarker, S., Munson, C. L., Sarker, S., & Chakraborty, S. (2009). 78–102.
Assessing the relative contribution of the facets of agility to VersionOne. (2018). 12th state of agile report. https://​explore.​
distributed systems development success: An analytic hierarchy versionone.​com/​state-​of-​agile/​versionone-​12th-​annual-​state-​of-​
process approach. European Journal of Information Systems, agile-​report
18(4), 285–299. Vidgen, R., & Wang, X. (2009). Coevolving systems and the
Sawyer, S., Farber, J., & Spillers, R. (1997). Supporting the social organization of agile software development. Information Systems
processes of software development. Information Technology & Research, 20(3), 355–376.
People, 10(1), 46–62. Wang, Z., & Hahn, J. (2015). Crowd experience and performance: An
Sawyer, S., Guinan, P. J., & Cooprider, J. (2010). Social interactions of empirical analysis of crowdsourced new product development.
information systems development teams: A performance ICIS 2015 Proceedings, pp. 1–20.
perspective. Information Systems Journal, 20(1), 81–107. Weber, R. P. (1990). Basic content analysis. Sage.
Schaubroeck, J., Lam, S. S. K., & Peng, A. C. (2011). Cognition-­based Yin, R. K. (2003). Case study research: Design and methods (3rd ed.). Sage.
and affect-­based trust as mediators of leader behavior influences
on team performance. Journal of Applied Psychology, 96(4),
Author Biographies
863–871.
Schmidt, C., Kude, T., Heinzl, A., & Mithas, S. (2014). How agile Phil Hennel is a PhD student and research assistant. He holds a
practices influence the performance of software development bachelor’s degree and a master’s degree in information systems
teams: The role of shared mental models and backup [Conference from the University of Cologne, Germany. Currently, he is pursu-
session]. International Conferencee on Information Systems ing his PhD at the Professorship of Information Systems and
(ICIS 2014), Auckland, New Zealand. Integrated Information Systems at the University of Cologne. His
Schulte, M., Cohen, N. A., & Klein, K. J. (2012). The coevolution of research interests cover the management of IT projects and the
network ties and perceptions of team psychological safety. composition of agile IS development teams, especially in regard
Organization Science, 23(2), 564–581. to diversity, psychological safety, and time pressure. His research
Schwaber, K. (1995). Scrum development process [Conference has been published in Project Management Journal®, AIS
session]. Conference on Object-­Oriented Programming Systems, Transactions on Replication Research, and in proceedings of
Languages, and Applications, Austin, TX, USA. 117–134. international conferences and workshops, such as the International
Siau, K., Long, Y., & Ling, M. (2010). Toward a unified model of Conference on Information Systems, Americas Conference on
information systems development success. Journal of Database Information Systems, Hawaii International Conference on System
Management, 21(1), 80–101. Sciences, Wirtschaftsinformatik, and the International Research
Singh, B., Winkel, D. E., & Selvarajan, T. T. (2013). Managing Workshop on IT Project Management. He can be contacted at
diversity at work: Does psychological safety hold the key to hennel@​wiso.​uni-­​koeln.​de.
racial differences in employee performance? Journal of
Occupational and Organizational Psychology, 86(2), 242–263. Christoph Rosenkranz is Professor for Integrated
Strauss, A., & Corbin, J. (1998). Basics of qualitative research. Sage. Information Systems in the Cologne Center for Information
20 Project Management Journal 00(0)

Systems of the Faculty of Economics, Management and organizational effects of digital technologies. He has pre-
Social Sciences at the University of Cologne, Germany. sented his work at international conferences such as ECIS and
Christoph holds a doctoral degree (Dr. rer. pol.) from Goethe ICIS, and has published articles in publications including the
University and a diploma (Dipl. Wirt.-Inform.) from the European Journal of Information Systems, Information
University of Münster. His research focuses on information Systems Journal, Journal of Information Technology, and
systems development and IT project management, digital Journal of the Association for Information Systems. He can be
transformation and business process management, and contacted at r​ osenkranz@​wiso.​uni-­​koeln.​de