Investigating the “Socio” in Socio-Technical Development: The Case for Psychological Safety in Agile Information Systems Development

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 understanding 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, communication, and ultimately productivity.

Keywords

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

Introduction

Approaching the end of the second decade after the Agile Manifesto (Beck et al., 2001), the initial wave of enthusiasm is part of the past, and agile approaches have been disillusioned by mixed results concerning their performance in practice (Hoda et al., 2011; Janes & Succi, 2012). However, agile practices are still becoming more and more popular in industry (VersionOne, 2018), research is still publishing special issues on agile (e.g., Niederman et al., 2018), and agile approaches have recently been integrated in to A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) – Sixth Edition (e.g., Project Management Institute [PMI], 2017).

Agile practices put emphasis either on management practices such as daily standups (e.g., Scrum; Schwaber, 1995) or development practices such as pair programming (e.g., XP; Beck & Andres, 2004). They aim at simultaneously decreasing sunk 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 for highly iterative project progress, constant feedback and communication, and synchronization, the need for team management and team collaboration increases as well—making it even more important to understand the social behavior and mechanisms of action of agile practices in teams (Kautz et al., 2007; Lee & Xia, 2010; Persson et al., 2012; Sarker et al., 2009).

Looking back at the extant research on agile it becomes apparent that, although centered on teamwork, agile adds an additional layer to traditional teams—especially its focus on embracing change as an inevitable factor instead of avoiding it at all costs. This unique focus is what differentiates agile practices from traditional methods of project management. Moreover, organizations face a multitude of challenges when introducing agile practices (e.g., Dikert et al., 2016; Gregory et al., 2016; Ramesh et al., 2010; VersionOne, 2018), further implying the special nature of agile approaches when compared to traditional project management approaches.

However, research has not yet caught up with industry, and team-level research on agile information system development (AISD) is scarce (Diegmann et al., 2018; Lee & Xia, 2010). Existing studies mostly have investigated specific and individual or organizational phenomena, such as the use and effects of specific agile practices (e.g., Balijepally et al., 2009; Holmqvist & Pessi, 2006; Maruping, Zhang et al., 2009; Recker et al., 2017; Tripp & Armstrong, 2018; van Oorschot et al., 2018), or effects regarding whole projects or organizations, such as the introduction of AISD approaches to teams (e.g., Cao et al., 2009; Heeager, 2012; Hong et al., 2011; Kotlarsky, 2007; Mangalaraj et al., 2009), or the usage of AISD practices in large-scale, multiteam environments or portfolios (e.g., Dikert et al., 2016; Dingsøyr et al., 2018; Sweetman & Conboy, 2018). Team-level effects, however, are mostly absent from these works, with only few exceptions (e.g., DevOps Research & Assessment, & Google Cloud, 2019; Lindsjørn et al., 2016; Przybilla et al., 2018; Schmidt et al., 2014).

This is perplexing because information system development (ISD) is mostly conducted in teams and quintessentially is a team effort (Sawyer et al., 1997, 2010; Siau et al., 2010). ISD generally takes place in the form of projects (Hirschheim et al., 1995, p. 33) or within product teams (Gerwin & Barrowman, 2002), with many involved stakeholders and team members (Chae & Poole, 2005). As a result, many of the problems associated with ISD projects are sociological, rather than technological, in nature (DeMarco & Lister, 1987, p. 4; Sawyer et al., 1997, 2010). For example, coordination and communication between various stakeholders are necessary for successful ISD (Corvera Charaf et al., 2013; Gallivan & Keil, 2003; Ko et al., 2005), and creating mutual understanding and common ground between different involved stakeholders is a major driver of ISD success (Bittner & Leimeister, 2014; Gallivan & Keil, 2003; Rosenkranz et al., 2013, 2014; Tan, 1994). Moreover, not only do practitioners call for more research on social aspects of AISD teams (Freudenberg & Sharp, 2010), but also scant research exists on social aspects of the development of socio-technical systems in general, which information systems (IS) essentially are (e.g., Kautz et al., 2007; Long & Siau, 2007; Sawyer et al., 2010; van Kelle et al., 2015). To understand the mechanisms of action at work in AISD teams and their effects, an operationalization on a team level is needed. Further, due to the increased importance of social interactions in AISD compared to traditional approaches to project management and ISD (Hummel et al., 2015), team-level effects in AISD likely differ from those found in traditional approaches and social aspects may vary. Importantly, our knowledge of the ISD process itself is often characterized as a “black box” (Siau et al., 2010, p. 92); only little ISD research goes beyond ISD methods, and there is a need for theory and studies about social behavior and processes of communication, negotiation, and learning (Kautz et al., 2007, p. 235). IS researchers therefore call for more conceptual and empirical research on team-level effects in AISD (Conboy, 2009; Mangalaraj et al., 2009; McAvoy & Butler, 2009; McAvoy et al., 2013). Without extended knowledge on these important effects, AISD project management remains driven by chance and individual, isolated, and anecdotal knowledge and experience.

With this study, we follow this call and—in contrast to previous studies, which centered on method selection or project-level performance (e.g., Tripp & Armstrong, 2018; van Oorschot et al., 2018)—aim at investigating the specific practices and their behavioral implications from a team-level perspective. To open the black box of the ISD process and conceptualize this for the domain of AISD, we build on and adapt findings of team and organizational behavior research, which has already taken technology-induced effects into account (e.g., Ilgen et al., 2005; Kozlowski & Ilgen, 2006) and has explored social aspects of inter-team-member cognitive effects (e.g., shared cognition [Healey et al., 2015] or adaptive structuration theory [DeSanctis & Poole, 1994]).

More specifically, we conceptualize the ISD process as being stimulated by agile practices, which in turn affect and are affected by psychological safety. When embracing change, as it is one of AISD’s core values, teams need to be resilient to the shocks and changes of a turbulent environment (Conboy, 2009). To achieve team resilience (Meneghel et al., 2016), a team needs to provide structure and an environment, which enable open, free, and safe communication—psychological safety is a necessity for resilience (Lengnick-Hall et al., 2011). For example, a regularly held retrospective aims at free, open, and honest exchange among team members and their views on issues in the project and the team; AISD cannot work without psychological safety —that is, “a shared belief held by members of a team that the team is safe for interpersonal risk taking” (Edmondson, 1999, p. 354), which is a driver for free, open, and honest communication (e.g., Edmondson, 1999).

We chose psychological safety as a central concept for three reasons. First, a healthy and supportive (i.e., psychologically safe) organizational environment has been shown to be closely connected to team resilience (e.g., Bardoel et al., 2014; Lengnick-Hall et al., 2011), which in turn is associated with AISD’s capability to respond to change (Chakravarty et al., 2013). Second, psychological safety influences team performance significantly (e.g., Bunderson & Boumgarden, 2010; Carmeli & Gittell, 2009; Schulte et al., 2012), and it has been suggested as a key antecedent of team performance in ISD as well (DevOps Research & Assessment, & Google Cloud, 2019). Third, it touches on many “pain points” of agile teams, for instance, by its mitigating capacity of negative effects of team diversity (Roberge & van Dick, 2010) or its positive effect on team diversity climate (Singh et al., 2013). Promising recent (e.g., Bunderson & Boumgarden, 2010; Carmeli & Gittell, 2009; Schulte et al., 2012) and well-established research (e.g., Edmondson, 1999) on psychological safety and its influence on team performance has not yet been integrated into project management and ISD research and has not been evaluated on their applicability and significance in AISD project management. When a whole range of similar, socially focused, practices are implemented (i.e., an agile approach is applied), this becomes even more important. Additionally, agile practices, such as regular retrospectives, add structure to a team’s processes, which, in turn, strengthens psychological safety (Bunderson & Boumgarden, 2010), suggesting a mutual interdependency. Consequently, the following research question guides our study:

How and why does the use of agile practices and their interaction with psychological safety affect project team behavior and, in turn, performance?

We therefore propose a model to investigate the effects of psychological safety on the use and effects of (social) agile practices. Specifically, we suggest that social agile practices (SAPs; Hummel et al., 2015)—that is, practices such as daily standup meetings or pair programming, which contribute directly to direct communication, collaboration, and interaction among team members—are likely to affect and to be affected by psychological safety, and therefore have an indirect effect on performance. With agile practices not only being popular in ISD projects in general (VersionOne, 2018), but also being transferred to other task domains (Niederman et al., 2018), this becomes a crucial focus for research on project management as well.

To provide a first evaluation of our model and to test this model’s propositions, we conducted a multiple-case study in two major insurance companies and one software development company. Based upon empirical data gathered in these cases, we performed a two-step deductive coding process. We present the results in this article. Providing deeper insights into benefits and presuppositions of AISD practices aids research and practice, as these insights could help to reduce the number of failed projects.

In the following section, we give an overview about related work, derive the proposed model and corresponding propositions, and describe the cases and coding process. Finally, we discuss our results and implications.

Related Work

Information Systems Development, Project Management, and Agile Approaches

Software-based IS are often developed in the form of projects (Hirschheim et al., 1995, p. 33), with many involved stakeholders and project team members (Chae & Poole, 2005). The nature of ISD is in many aspects intangible (Cule et al., 2000), and the major problems of ISD projects are not so much technological as sociological in nature (DeMarco & Lister, 1987, p. 4). Communication, collaboration, and coordination are necessary for successful implementation (Gallivan & Keil, 2003; Ko et al., 2005; Rosenkranz et al., 2017), and creating a shared understanding is deemed to be a major driver for ISD success (Corvera Charaf et al., 2013; Gallivan & Keil, 2003; Rosenkranz et al., 2013; Tan, 1994).

In practice, approaches for developing software-intensive IS range from sequential approaches (Royce, 1970) to more cyclic, iterative approaches (Boehm, 1988). Most project management and ISD methods supposedly aim to facilitate communication and knowledge transfer among different participants and stakeholders. For example, rational unified process and various other approaches are often stated to have been created just for this purpose (Kroll & Kruchten, 2003, pp. 145–149; Kruchten, 2004, pp. 5, 92). The majority of traditional project management and ISD methods, either sequential or iterative, is plan driven and relies on formal communication, such as specification documents or models to control communication and knowledge transfer among project members and other stakeholders (Black et al., 2009; Boehm & Turner, 2004; Kraut & Streeter, 1995). For example, requirements are usually stated within a requirements document, which at the end of the system analysis phase, is a specification of the system to be built (Pohl, 1994). In rapidly changing environments, however, it is hard for formal mechanisms of communication, such as project plans, models, or specification documents to react quickly enough, and plan-driven and sequential approaches falter (Byrd et al., 1992; Herbsleb & Mockus, 2003; Kraut & Streeter, 1995): “Rather than being bastions of order in an uncertain world, traditional teams may indeed become chaotic should their plan-driven organization be overwhelmed by events” (Vidgen & Wang, 2009, p. 374).

Agile principles and new management concepts such as Scrum or Extreme Programming have emerged during the last decades and have built upon iterative work as the lowest common denominator (Beck & Andres, 2004; Beck et al., 2001; Martin, 1991; Poppendieck & Poppendieck, 2003; Schwaber, 1995). The resulting AISD approaches (Cao et al., 2009; Vidgen & Wang, 2009) trade strict control for more flexibility and autonomy within the team, the overall development process is not planned and scheduled upfront, and progress is made in small iterative phases, while encouraging change and constant feedback (Cockburn & Highsmith, 2001; Highsmith & Cockburn, 2001). Planning becomes a permanent task, and team leadership is established via collaboration and is separated from project lead (Dybå & Dingsøyr, 2008, 2009).

While the team is thus highlighted as the crucial aspect of AISD in practice, extant research on AISD approaches mainly has investigated specific and individual or organizational phenomena, such as the use and effects of specific agile practices (e.g., Balijepally, et al., 2009; Holmqvist & Pessi, 2006; Maruping, Zhang et al., 2009; van Oorschot et al., 2018), or effects regarding whole projects or organizations, such as the introduction of AISD methods to teams (e.g., Cao et al., 2009; Heeager, 2012; Hong et al., 2011; Kotlarsky, 2007; Mangalaraj et al., 2009), or the usage of AISD approaches in large-scale, multiteam environments or portfolios (e.g., Dingsøyr et al., 2018; Sweetman & Conboy, 2018).

As existing research thus covers individual and organization-wide level of effects on AISD, team-level effects are covered less so, and existing results are contradictory. For example, team research has included technology as an influencing factor of teamwork (e.g., Kozlowski & Ilgen, 2006), but specific features of (A)ISD have not been observed. Some studies have found that cohesive (i.e., nondiverse) teams are the optimal base for applying agile practices (Cao et al., 2009; Fruhling & de Vreede, 2006), while other studies suggest that diversity amplifies creativity and problem-solving ability (Bear & Woolley, 2011; Lee & Xia, 2010; Phillips et al., 2006) and therefore might provide benefits for AISD. These inconsistencies are especially important for AISD, as AISD teams rely heavily on efficiency (to respond quickly to changes; Conboy, 2009) and problem-solving ability (to complete complex, nonroutine tasks; Lee & Xia, 2010).

Team Resilience

One concept closely linked to efficiency and problem-solving ability (i.e., team effects), which has also been repeatedly linked to AISD, is team resilience (Meneghel et al., 2016). AISD explicitly acknowledges the importance of being able to respond to requirement changes and even embrace change and an ever-changing environment (Beck et al., 2001). As changes impose difficulties for the team, AISD teams have to have the capacity to recover quickly from changes and difficulties, which is the textbook definition of resilience (Oxford English Dictionary). As AISD explicitly stresses the importance of being able to respond to requirement changes (Beck et al., 2001), resilience supposedly is an important team trait for successful AISD, as changes in requirements is one of the main reasons ISD projects fail (Maruping, Venkatesh et al., 2009).

Resilience in general has been used in biology to describe the ability of a dynamic multispecies ecological system to persist with the same basic structure when subjected to stress (Holling, 1973). Derived from this, team resilience is used to describe a team’s ability to “withstand disruptive factors, synonymous with both buffering against disruptive factors and correcting for disruptive factors without significant strategic changes” (Chakravarty et al., 2013, p. 983). As an important aspect for this study of team resilience is its influence on performance in teams in general (Meneghel et al., 2016).

While resilience can stem from different sources (e.g., individual characteristics) and can vary depending on the present disruption, one—intuitive and important—way to develop resilience is a critical review by the team of the team and its success (Alliger et al., 2015). That way, a team can spot weaknesses in its processes and ways of work and improve itself. Team members therefore have to feel that they can voice concerns and critique and feel safe to take interpersonal risks by doing so. This has been conceptualized in organizational psychology by psychological safety (Edmondson, 1999).

Psychological Safety

Psychological safety, which originates from concepts such as leadership style or cohesiveness, is seen by research in organizational behavior as an important one, especially in regard to innovativeness and learning behavior (Baer & Frese, 2003; Nembhard & Edmondson, 2006). Psychological safety affects and moderates a latitude of team-level effects (Martins et al., 2013; Roberge & van Dick, 2010), among them learning, innovativeness, self-reflection, and overall performance. As AISD practices rely heavily on social interactions, self-organization, and self-reflection, strengthening team learning behavior, information sharing behavior, innovating capacity, and improve team members’ motivation to speak up for organizational improvements can be expected to improve agile team performance. Psychological safety affects all of these aspects (Baer & 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 corresponding effects of AISD practices.

Psychological safety, a shared belief held by members of a team that the team is safe taking actions that could be interpersonally risky in other teams (Edmondson, 1999, p. 354), has been used by researchers to explain organizational learning (Nembhard & Edmondson, 2006), information sharing, and how team members are motivated to speak up for improvements (Detert & Burris, 2007; Liang et al., 2012) or to take initiatives to innovate (Baer & Frese, 2003). Structure (e.g., in the form of clear procedures for coordinating and prioritizing work) fosters psychological safety, especially in self-managed teams, and improves team learning (Bunderson & Boumgarden, 2010). Further, an influence of psychological safety on the ability to learn from failures has been identified (Carmeli & Gittell, 2009; Jehn et al., 2014).

Furthermore, psychological safety moderates (i.e., mitigates) the negative effect of diversity on performance (Roberge & van Dick, 2010). A direct effect on performance (Schaubroeck et al., 2011), especially in diverse teams (Singh et al., 2013), is apparent as well.

In sum, extant research has applied theories of organizational psychology while being focused on IT use rather than on AISD (e.g., DeSanctis & Poole, 1994; Gorecki et al., 2008; Nan, 2011; Wang & Hahn, 2015). While research on teams thus is not completely new to AISD research, psychological safety and its relationship to team resilience have not been investigated, but are seen as an important factor for AISD practitioners (DevOps Research & Assessment, & Google Cloud, 2019).

Theory Development

Considering that research has yet to identify the preconditions for successful implementation and use of AISD, we propose to contribute to closing this research gap with a conceptual model. 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 propose that this benefit can only be realized if team members feel that they can speak freely and voice concerns or give alternative, possibly controversial, solutions. In support of this claim, empowering management, flat hierarchies, a collaborative environment, which enables team members to express their opinions have been found to be important facilitators for AISD (Batra et al., 2016; Chow & Cao, 2008) and similarly for learning organizations in general (Eisenberg et al., 2013; Ellinger & Bostrom, 1999). Therefore, we propose psychological safety to moderate the effect of SAPs. If the team is not feeling safe (i.e., low psychological safety), the AISD practices only provide marginal benefits or even reduce performance. If, however, the team does feel safe (i.e., high psychological safety), SAPs unfold their full potential and the team gets performance benefits from the implementation of SAPs. We further argue for a feedback loop in that SAPs in turn lay the groundwork for emergent psychological safety in AISD teams by providing safe environments (e.g., via daily standup meetings) and fostering mutual support and responsibility (e.g., via collective code ownership). Note that we are not interested in textbook agile approaches, but the individual configurations of SAPs (i.e., the respective method tailoring result employed in our cases). We are therefore looking at the number of, as well as the frequency and quality of employed SAPs rather than the differences between what agile practices call for and how these are implemented in the different cases.

While these phenomena have been investigated on their own and mainly in the context of general or occasional teams (e.g., randomized samples in experiments), AISD research has not put these theories together and evaluated these effects in the specific context of AISD teams in the field, although AISD methods rely heavily on team work, team composition, communication, and interpersonal relationships (Beck et al., 2001; Lee & Xia, 2010; Maruping, Venkatesh et al., 2009; Rosenkranz et al., 2013; Sawyer et al., 2010). If our assumptions hold true, the proposed model helps in explaining team-level effects in AISD and in turn gives guidance to improve team resilience and performance. Figure 1 displays our proposed model and Table 1 summarizes the constructs.

Figure 1

Resulting research model.

Table 1

Construct Summaries

Name	Definition	References
Social Agile Practices (SAPs)	Agile practices entailing communication practices or practices aiming at exchanging knowledge and facilitating interpersonal interaction (e.g., daily scrums, retrospectives, or pair programming).	Hummel et al. (2015)
Psychological Safety	Psychological safety is defined as “a shared belief held by members of a team 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.	Edmondson (1999)
Performance	Composed of on-time completion, on-budget completion, software functionality, and resilience. Resilience describes how quickly a team is likely to recover or bounce back from failure once failure has occurred. Also defined as “being able to withstand disruptive factors, synonymous with both buffering against disruptive factors and correcting for disruptive factors without significant strategic changes” (Chakravarty et al., 2013, p. 983).	Lee and Xia (2010) Alliger et al. (2015) Hashimoto et al. (1982) Chakravarty et al. (2013)

As structure helps self-managed teams to improve their learning from failures (Bunderson & Boumgarden, 2010) and as SAPs provide this structure both in the form of daily routines (e.g., daily standup meetings), and in the form of mentoring and help-providing structures, (e.g., through pair programming or collective code ownership), we argue that the usage of SAPs positively influences performance and we propose P₁:

P₁: Usage of social agile practices positively affects performance.

Linking psychological safety with AISD, we argue that SAPs foster psychological safety by providing a safe environment for speaking up (e.g., during daily standup meetings or sprint reviews) and by creating a perception of shared responsibility and mutual support (e.g., via shared code ownership or pair programming), because structure (e.g., provided by daily standup meetings or mentoring during pair programming) is beneficial to psychological safety (Bunderson & Boumgarden, 2010). At the same time, research suggests that psychological safety plays an important role regarding social interaction in teams (Baer & Frese, 2003; Detert & Burris, 2007; Liang et al., 2012; Nembhard & Edmondson, 2006). Especially with regard to the emphasis SAPs place on social interaction, psychological safety acts as an enabler for SAPs, by empowering team members to speak freely with one another, cooperate, and resolve conflicts (Roberge & van Dick, 2010). Taken together, this results in proposition P₂:

P₂: Increased usage of social agile practices positively affects psychological safety, and increased psychological safety enforces the use of social agile practices.

Building upon this argument for P₂, psychological safety not only enforces SAPs, it is a prerequisite for SAPs to unfold their positive effects. Without feeling safe to voice concerns (e.g., during reviews or pair programming), SAPs are destined to be less successful than when team members feel safe to engage in SAPs. P₃ resembles this proposition:

P₃: Psychological safety enables and enforces the positive effect of social agile practices on performance.

Research Design

Case Overviews and Data Collection

To test our propositions and evaluate our proposed model, we conducted an embedded, confirmatory multiple-case study (Dubé & Paré, 2003; Lee, 1989b; Yin, 2003, p. 49) within three different case organizations (see Table 2). The cases were sampled following a joint literal (conditions of the case lead to predicting the same results) and theoretical replication logic (conditions of the case lead to predicting contrasting results). The two similar cases are set in large insurance companies (Insure1 and Insure2), one of which is active internationally and one only nationally. The third case (Develop1), selected as a deliberate theoretical contrast, is set in a small-to-medium sized software development company, focusing on business-to-business (B2B) services. Develop1 began to use agile practices eight years ago, Insure1 and Insure2 both are in the process of introducing agile practices, which started in both cases a little over a year ago. The main unit of analysis (i.e., “what” is the case to be studied) is the team, with team members as subunits. All examined organizational units are based in Germany.

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

We collected data from various data sources and with different data collection methods. Semi-structured interviews, project documentation, instructional and managerial guidelines, and field notes were used to generate data. The participants for the semi-structured interviews were sampled to cover common roles in AISD projects (see Table 3), but also to interview those team members, which can give detailed insight in and an overview of current and recent projects. Supplementary documentation, such as project and team descriptions, as well as internal guidelines, were used to identify suitable participants. An interview guideline (Appendix A) served as a rough structure, with room for deviation and probing questions, and each interview proceeded individually. The interview guideline was not shared with the interviewees and we only used it as a checklist and outline. The aim was to encourage the interviewees to provide a narrative of their experiences as freely as possible. We interviewed both project managers and project workers. Administrative documents, work descriptions, interview transcripts, and field notes were collected in a case study database. We collected data from July 2018 to August 2018 while conducting 13 face-to-face interviews at the companies’ sites (see Table 3). All participants of Insure1 and Insure2 were part of an agile transformation team, enabling us to gain an overview over 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.

Table 3

Interviewee Overview

Name	Case	Role/Assignment	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.

While loosely following the guideline, space for probing and open questions was available. During these interviews, the participants were asked about the implemented agile practices and about teamwork in general. Furthermore, we asked participants about their perceptions of the applicability and success of agile practices as well as team climate and interactions among team members. Our guidelines were derived from extant literature. The interviews lasted about 60 minutes and were recorded and transcribed. This resulted in about 169 recorded transcript pages (sheet size DIN A4). Follow-up emails were sent to request clarifications and to offer informants the possibility to provide feedback and comments.

The interview protocol and guideline were checked against Bouchard (1976) and Mishler (1986). The guideline was especially checked regarding the sequence of questions; however, since the interviews were basically open, as few direct questions as possible were asked and leading questions were avoided (Loftus, 1975).

Data Analysis

Coding techniques and checklists (Miles & Huberman, 1994b, pp. 170–244; Yin, 2003, pp. 109–138) were afterwards used to connect data with constructs from our model and the propositions. The data analysis process is outlined in Figure 2. We used the software MaxQDA for coding our data. Following Saldaña (2016), we applied different coding strategies. At the core is the task of conceptualization, that is, “the process of grouping similar items according to some defined properties and giving the items a name that stands for that common link” (Strauss & Corbin, 1998, p. 121). As coding can be seen as a “cyclical act” (Saldaña, 2016), our coding process therefore can be distinguished between a first and second step.

Figure 2

Coding process with illustrations.

First, we derived the codes from extant literature and our proposed model (displayed in Table 4). Extant literature predetermines our codes as, for instance, the sets of available SAPs are already identified by Hummel et al. (2015) and Tripp et al. (2016). Based on these predetermined codes, we set out to identify and refine our proposed constructs by means of pattern coding as described by Miles and Huberman (1994a) and Saldaña (2016). Pattern coding is appropriate for the development of major themes from data (Miles & Huberman, 1994a; Saldaña, 2016). These codes are capable to “identify an emergent theme” and therefore are helpful for “grouping those summaries into a smaller number of sets, themes, or constructs” (Miles & Huberman, 1994a, p. 69). This analysis was performed on the conducted interviews and supplemental material (e.g., field notes, instructional material/managerial guidelines). The theoretical constructs of SAPs (Hummel et al., 2015) and psychological safety (Edmondson, 1999) served as guidelines.

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
Performance	… 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 second coding step in our coding process follows hypothesis coding, which is suitable for testing purposes, especially to test for rules, causes, and explanations (Russell Bernard, 2002; Saldaña, 2016; Weber, 1990). Furthermore, hypothesis coding can be applied in a later coding stage to confirm or disconfirm developed assertions—as is the case for this study (Saldaña, 2016). In this step, we aimed at identifying statements in the conducted interviews and supplemental material (e.g., field notes, instructional material/managerial guidelines) to support or reject our propositions. Once again, the theoretical constructs of SAPs (Hummel et al., 2015) and psychological safety (Edmondson, 1999) served as guidelines for coding the interviews. Further, we used supplementary data sources (as mentioned above) to set participants’ statements into clearer context.

We followed three tactics to increase construct validity (Lee, 1989b; Yin, 2003, pp. 40–44). We used multiple sources of evidence (multiple key informants) and established a chain of evidence (case study database) during data collection. Furthermore, all key informants reviewed draft reports of the case study. In the data analysis, we addressed internal validity by pattern matching (linking the propositions and constructs to data from the case study database) and explicit explanation building. Since this case study was explicitly designed to test the propositions of our model, we used replication logic and theoretical logic in the setup of multiple cases for ensuring external validity. The multiple-case study design was explicitly chosen to ensure analytical generalization. For addressing reliability, for each case in this study, we collected transcripts and protocols from the interviews. Following Dibbern et al. (2008) and based on Dubé and Paré (2003), Appendix B gives a detailed overview about the attributes used to assess the case study’s rigor.

Results

The main coding matrix resulting from our analysis is displayed in Table 4. Depending on the frequency and clarity of identified codings in our data, we labeled the vividness of each 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 cases implement a similar, yet different set of agile practices. During the interviews, we asked the participants to reflect on their specific circumstances, especially their set of SAPs. Also, the levels of psychological safety are slightly different between the cases. However, all three cases aim for a high level of psychological safety:

“It is very important to Insure1 that employees can always give their honest opinion.” (I1-1, Q1)

“The wonderful thing is that you don’t have to be afraid that some statement will be used against you, because you might be evaluated thereafter.” (I1-2, Q2)

“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 care about.” (I2-1, Q3)

“Yes, it’s very friendly here, very humane.” (SW-1, Q4)

The few instances in which a less safe environment was mentioned were either in relation to situations before the agile transformation:

“[if someone made a mistake, …] there was often the escalation toward project management before.” (I2-5, Q5)

or in relation to (emotional or task) conflicts, which arose at the very beginning of the agile transformation process due to the increased transparency and interdependency of work but always were resolved later on:

“Partly where it was simply a matter of not including some people who felt that they were being overlooked, and that actually led to conflicts … These were both, personal conflicts as well as professional ones. … However, the team often found this resolution process very fruitful. One has developed a joint solution and thus there is a better feeling later. Everyone has contributed and is involved. Everyone has a bringing-us-together function, so the team is more connected.” (I1-4, Q6)

An important aspect in these statements is set in comparison to the “before agile” state of the organization. As will become clear in the following paragraphs, the overall situation painted by the participants was positive and accepting; although some hurdles had to be overcome, and the transformation into agile ways was sometimes perceived as difficult. For instance, two of three cases showed a partial negative effect of SAPs on performance:

“There were also team members who said, ‘this [our set of practices] is all nonsense and does us no good.’” (I1-1, Q7)

However, these team members changed their attitude later on or their attitude was based on fear for increased transparency on their work:

“That is a safeguard, some do not want to make their work transparent [e.g., by participating in daily standup meetings], because then one would see what someone is doing and what not.” (I1-4, Q8)

“[there are some who] were very hostile and played with prejudices [in the beginning] who now [after some successful projects, …] if something goes well, say ‘sure, we did that the agile way.’” (I1-4, Q9)

As becomes clear through these statements, transparency was a critical factor in the agile transformation and plays an important role in successful AISD, as, for example a facilitator for trust, communication, and knowledge sharing (Laanti et al., 2011; McHugh et al., 2011).

In regard to our propositions and as displayed in Table 4, we found support for all three propositions as displayed in Figure 1 and outlined in the section. Support for proposition P₁ can be found in all three cases:

“In my opinion, Scrum helps to really deliver quality.” (I2-2, Q10)

“I know they [the team] perform and that we’re in roll-out now. And obviously—it worked.” (I2-5, Q11)

“And towards the end, we had actual change requests. […] There you can see the complete harmony between what I expected and what I got.” (I2-5, Q12)

Similarly, proposition P₂ is supported by two of three cases. One aspect, as identified by I1-3, is that by “forcing” people together, by promoting social interactions, people are more likely to develop a common understanding:

“You can’t avoid each other. … You’re already working things out together. You must at least create a basic understanding together and through this you must speak a common language [e.g., during retrospectives]. So, we have invested a lot of time in a common understanding … However, I believe that this is very valuable in the long term.” (I1-3, Q13)

I2-5 made a very similar argument. He thinks that an iterative approach, combined with learning and a common vision help in establishing trust:

“All this didn’t work overnight. It has gone through a process and trust has been built up among each other. And you can actually say that people have grown more attached to each other and what you produce here as a product … that can be sold on the market, that’s their baby. They developed a deep identification with their work [after the introduction of agile practices].” (I2-5, Q14)

Further support for proposition P₂ can be found in all three cases. Insure1’s internal guidelines document core organizational values close to the four values postulated in the Agile Manifesto, and participants of Insure1 were especially outspoken about the effects of a safe environment on the agile practices:

“Colleagues should simply be open—to new topics and simply have fun trying things out.” (I1-2, Q15)

“I think to be able to work really well together; it is important to be part of the team.” (I1-3, Q16)

The cyclical relationship between psychological safety and SAPs, as described in P₂, has been raised by participants as well:

“Many have not yet understood this concept of a learning organization either. ‘Why do you do this different now again?’ ‘We’ve only just gotten used to the old way. Why does it have to be any different now?’ And these constant changes over and over again, that is just really difficult for some people.” (I1-2, Q18)

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:

“Just look at the team a bit, have a little more sense for the needs. And you have to sell why you want to do it this way.” (I1-3, Q19)

Insure2 reiterates that psychological safety influences their way of work and the selection of SAPs:

“In the end, we simply encourage the team members to get involved and perhaps make suggestions on how to improve processes [and practices].” (I2-4, Q20)

“This is the agreement: You do your thing. I trust you, and I got your backs—and this deal unfolds creativity and motivation. It’s not easy to copy [practices by the book] because it’s based on rather soft factors.” (I2-5, Q21)

Finally, we see support for proposition P₃ in all three cases as well. Some statements were less clear:

“I think that this [i.e., Scrum-like practices] works very well, as long as you have a Scrum team, which works well as a team.” (I2-2, Q22)

which hint at a trusting and friendly (i.e., psychologically safe) team as a prerequisite for success of AISD practices. Other statements were clearer but discussing the effects of low psychological safety:

“Sure, it becomes very transparent how I do something, how I work. … you also have to share a lot [e.g., during retrospectives]. And that’s just difficult for many people at first.” (I1-2, Q23)

“Sometimes there was pure rejection and statements like ‘we have 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 methodology, but rather with [affective and task-related] conflicts in the team that had not been resolved.” (I1-4, Q24)

On the other hand, we found similarly clear statements discussing the effects of high psychological safety in Develop1. Asked about the most important success factors for the success of their agile implementation, SW-1 said:

“Communication, honesty, and candor.” (SW-1, Q25)

These three factors are all linked to psychological safety, as psychological safety is based around honesty and candor and improves communication.

Combining all statements, we find support for all our propositions, which leads to implications for both research and practice and opens new avenues for future research.

Discussion, Implications, and Limitations

As AISD methods rely heavily on team work, communication, interpersonal relationships, and social interaction in general (Beck 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 AISD implementation. Further, we found evidence for the influence of SAPs on performance in general (e.g., Q10) and resilience in particular (e.g., Q12). We outlined in the previous section and displayed in Table 4 the support for all our propositions, especially for the importance of psychological safety—leading to a supportive, friendly, and open environment. It is demonstrated that psychological safety can play a role in making SAPs more effective, and that effective SAPs can add to the sense of psychological safety experienced by agile team members.

Discussion of Propositions

In the following section, we will take a closer look into each of our propositions regarding the identified support and the respective transferability.

P₁: Usage of Social Agile Practices Positively Affects Performance.

As pointed out in our results section, we found clear support for our proposition P₁. While the usage of these practices sometimes led to a—temporary—decrease in performance (e.g., due to an increase in need for communication), ultimately, interviewees reported an increase in performance due to the usage of SAPs compared to their previous, waterfall-driven approach. Our main focus was on the overall usage of SAPs, rather than the how and how often usage of singular practices. Nevertheless, we found evidence for the importance of careful and conscious adoption and implementation of SAPs. For instance, as reported in Insure1, if team members slip on their participation of daily standup meetings, the beneficial effects of regular meetings cannot be realized. We decided not to include this finding as a proposition, as it would go beyond the scope of this study.

While this effect cannot be translated to purely traditional, non-agile projects, it can be transferred to any project implementing SAPs, regardless of the underlying software development methodology or ideology.

P₂: Increased Usage of Social Agile Practices Positively Affects Psychological Safety and Increased Psychological Safety Fosters the Use of Social Agile Practices.

The previous section gives examples for the strong support we found for P₂. However, some interviewees pointed out that the way in which SAPs were introduced and overseen by, for instance, the scrum master, influenced the respective effect on psychological safety. If SAPs were forced onto the team, psychological safety did—in some cases—not manifest as quickly and strongly as in others.

This specific effect can only be observed in teams engaging in SAPs; however, we found no evidence suggesting that the underlying task domain would play a role for this effect. We further assume that the effect is especially visible in any practices focusing strongly on social interactions (e.g., retrospectives), 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 into cooperation) might very well further decrease psychological safety over time, turning this effect into a downward spiral. However, we found no indication of this trend occurring in our sample.

P₃: Psychological Safety Enables and Enforces the 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 enabling effect of psychological safety across all cases. Further, as this effect is not cyclical as is proposition P₂, we believe that this effect is even more robust.

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 interaction, to be heavily impacted by psychological safety—at least by psychological safety as a moderator of any positive effects derived by said practices and routines.

Consolidation

The collected data suggest that psychological safety plays two significant, cyclical roles in AISD. First, psychological safety determines if team members accept SAPs (e.g., Q18). If psychological safety is low, team members are less likely to partake in planning meetings and retrospectives. If, in contrast, psychological safety is high, team members are more likely to accept SAPs and give them a try. Second, psychological safety determines how team members participate in SAPs (e.g., Q22). If psychological safety is low and they do participate in SAPs, they are less likely to speak their minds, are less likely to give valuable input to achieve successful outcomes, and are less likely to offer ideas for continuous improvement. In contrast, a higher psychological safety leads to more engagement, more helping behavior, and an increased willingness to offer new ideas and give valuable input, which ultimately leads to improved outcomes and a learning organization.

However, if psychological safety is low, it can be improved and strengthened by implementing SAPs carefully (e.g., Q13). As we have seen in the previous section, it is important to apply change management tactics and listen to the needs and concerns of team members.

Taken together, these two roles stress that, while SAPs rely on and are influenced by psychological safety, psychological safety is enforced by SAPs, indicating that SAPs are not static, but to some degree dynamic (e.g., Q14) in their implementations. These findings extend previous research on social aspects of agile practices (especially Hummel et al., 2015) by explaining the surrounding context (in this case psychological safety) of successfully implemented SAPs. As put by Niederman et al. (2018), conflict and conflict resolution differ in AISD from traditional approaches. Psychological safety may explain when and why conflict can be beneficial to AISD teams.

Future Research and Implications

This study opens up new avenues for future research. Having support for the influence of psychological safety means that research now should investigate in more detail which boundary conditions are in effect for psychological safety to influence SAPs. Furthermore, a quantitative evaluation of this model could yield additional insights. Due to the qualitative nature of this study, we have only limited indication for the strength and significance of the identified effects. Additionally, future research might look into the details of the “how” and “how often” of SAP usage, as we did find evidence for the significant effect of how and how often an SAP was adopted, implemented, and used. While the interviews indicate significant and strong effects, a quantitative follow-up study would increase the confidence in our results. Methodological replication studies outside of the task domain of software development might further define and refine the boundary conditions of our findings and help in building trust to our argumentation for transferability of our findings to different task domains. While our study was conducted in a new product development setting, all participants worked in software-related new product development projects. While software- and non-software based new product development projects share many similarities (e.g., unclear or at least changing requirements), they have differences. For instance, software can often be modified cheaply even after the 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-software new product development project and might be a fruitful avenue for future research. Additionally, we see an avenue for future research on the applicability of our findings in other task domains and industries, as all of our cases worked on new product development tasks in the insurance industry. Another, possibly fruitful avenue for future research might be an interaction between psychological safety and team resilience directly. While we did not find direct evidence in our data or our literature review, one might imagine an interaction between these two concepts, possibly over time.

For practitioners, these results have important implications as well. When considering using agile practices for AISD projects, the increased social aspect should be considered in addition to established characteristics. If an environment with lower psychological safety can be assumed, AISD practices are likely to not fulfill their potential and might harm the process. When considering transforming to an agile approach or implementing AISD practices, managers should, in addition to the previous point, consider the additional tension a transformation might bring to those who are adjusted to, for instance, a waterfall method. These tensions might need additional consideration, preparation, and an even higher level of psychological safety, compared to a new team. When already using AISD practices—but the team members might not participate or if these practices appear useless—managers might take a closer look at the psychological safety in the team in general and during the execution of these practices. As presented in the results section, some team members might not feel safe (enough) to participate in SAPs. Similar to managers, team members themselves could benefit from checking the psychological safety in their teams as, ultimately, every team member contributes to the team climate and psychological environment. As literature suggests, being inclusive and open toward team members helps in creating a psychologically safe environment (Edmondson, 1999; Nembhard & Edmondson, 2006). Raising psychological safety in the team not only benefits team performance, it also raises job satisfaction (Bergheim et al., 2015) and should therefore be in every team member’s own interest. Therefore, a psychologically safe environment appears to be extremely important to successful implementation of AISD methods. This means that before and during an agile transformation, an open and honest environment without fear for retribution or penalties has to be created and reinforced. Furthermore, practitioners should be aware of the cyclic relationship between SAPs and psychological safety. While psychological safety is an important factor for successful AISD implementation, SAPs enforce psychological safety, and psychological safety influences the engagement of team members in SAPs and their selection of preferred SAPs. This concept of a learning organization is seen as a threat by some team members, but with appropriate change management, this constant process refinement can be beneficial to both team members and the organization as a whole.

Transferability to General Project Management

Industrial practice has not only identified social aspects as important drivers for success in AISD (e.g., McGregor & Doshi, 2018), but also reports of successful implementation and adaptation of agile approaches surface as well (e.g., Rigby et al., 2018). More specifically, agile is considered harmful if implemented superficially—if teams cannot experiment and manage themselves, they stop learning and stop putting their best efforts into their work (McGregor & Doshi, 2018). An environment of high psychological safety is therefore needed to reap the benefits of agile approaches, especially in uncertain or changing environments—and for these environments, industrial practice has seen success in implementing agile approaches outside of software development. For instance, a company in engineering and construction was able to succeed in a business turnaround following a crisis of declining demand by implementing agile practices as a new way of work, resulting not only in reduced costs, but also in an increase in employee motivation and acquired skill sets (Rigby et al., 2018).

While our interviews were set in a software development context, we strongly believe that our findings are transferable to agile teams in other task domains. Most interviewees from Insure1 stated that they have experience working outside of software development as task domain and indicated that their experiences regarding SAPs and psychological safety were not exclusive to the software development task domain. While some SAPs, such as pair programming, are specific to software development, substitutes exist (e.g., pair writing). Furthermore, as agile approaches in general (and therefore AISD practices), are increasingly diffused from information systems development to other domains, our findings help in understanding these mechanisms of action not only in the AISD domain and might help in more direct and effective implementation of AISD practices inside and outside of information systems development.

What these previous paragraphs amount to is the importance of a supportive, friendly, and open environment, especially in teams working in highly volatile and changing environments, or teams transitioning to agile approaches. To sum up, our findings are applicable to general project management in that we showed an interaction of SAPs on psychological safety, which, in turn, affects transparency, communication, and ultimately productivity. It follows that any intervention (such as SAPs) that increases psychological safety might solve transparency and communication issues and can benefit productivity.

Limitations

This study is not without limitations. First, this study considers only three different cases, two of which are similar in industry, size, and state of agile adoption. The third, as the sole contrasting case, has only limited explanatory power. By increasing the number of cases, our findings could be refined and gain in validity if confirmed. Second, all three companies are based in Germany, with only one company being part of an international organization. Future research could conduct similar studies in other countries and cultural regions to evaluate the influence of cultural aspects on the importance of psychological safety. Third, we did not conduct interviews with every team member. It is likely that the perceptions of the specific team’s level of psychological safety and its influence on the 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 statements in all interviews. Similarly, we cannot rule out that in some cases, we have identified a side effect as a cause, due to the nature of a field experiment—for instance, we cannot determine if psychological safety benefitted from having regular meetings or having everyone participating in every meeting. However, as our cases were similar, yet not identical (e.g., not all teams in Insure1 had everyone always participate, others did), we are confident in the reliability and validity of our findings. Future research might still be able to strengthen the trustworthiness of our findings. Furthermore, our study is limited by the single pathway in a complex nomological network described. It is unclear if SAPs always interact with psychological safety and if this (perceived) psychological safety is not determined by—possibly stronger—outside effects. The same limitation applies for the observed influence on performance. A great deal of outside effects (e.g., team members’ capabilities, market forces) might affect performance stronger and more significantly than the effects of SAPs and psychological safety. This all leads to the issue that psychological safety is a very broad concept, making it possible to find influences on many different aspects of teamwork. However, we do think that our reasoning for these specific effects is sound and significant. We would nevertheless suggest future research to dig deeper into this issue and to try to isolate the effects of psychological safety in AISD teams, for instance, via controlled interventions.

The fifth limitation is the influence of social desirability bias, as it is generally more socially desirable to report success rather than failure. Nederhof (1985) suggests postulating questions that are neutral. We tried to minimize the social desirability bias emerging from our questions. However, due to the clear preferability of success over failure, social desirability bias was still likely to emerge from questions during our interviews.

Conclusion

In this article, we constructed and argued for a novel model, explaining the interplay between psychological safety and AISD practices. As explained earlier, we were able to show that psychological safety is a critical success factor for agile teams. With the diffusion of agile practices outside of the domain of information systems development, our findings provide insights for general project management. However, due to the discussed limitations, future research on team-level effects in AISD is needed to further improve AISD, reducing the number of failed AISD projects, and to review the applicability of our findings in additional contexts.

Footnotes

Appendix A

This interview protocol served as a rough guideline in the interviews. However, most of the interviews followed a natural, but individual course.

Appendix B

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

Declaration of Conflicting Interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) received no financial support for the research, authorship, and/or publication of this article.

Author Biographies

Phil Hennel is a PhD student and research assistant. He holds a bachelor’s degree and a master’s degree in information systems from the University of Cologne, Germany. Currently, he is pursuing his PhD at the Professorship of Information Systems and Integrated Information Systems at the University of Cologne. His research interests cover the management of IT projects and the composition of agile IS development teams, especially in regard to diversity, psychological safety, and time pressure. His research has been published in Project Management Journal, AIS Transactions on Replication Research, and in proceedings of international conferences and workshops, such as the International Conference on Information Systems, Americas Conference on Information Systems, Hawaii International Conference on System Sciences, Wirtschaftsinformatik, and the International Research Workshop on IT Project Management. He can be contacted at hennel@wiso.uni-koeln.de.

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

References

Alliger

G. M.

Cerasoli

C. P.

Tannenbaum

S. I.

Vessey

W. B

. (2015). Team resilience. Organizational Dynamics, 44(3), 176–184.doi:10.1016/j.orgdyn.2015.05.003

Baer

Frese

. (2003). Innovation is not enough: Climates for initiative and psychological safety, process innovations, and firm performance. Journal of Organizational Behavior, 24(1), 45–68.doi:10.1002/job.179

Balijepally,

Mahapatra,

Nerur

Price,

K. H

. (2009). Are two heads better than one for software development? The productivity paradox of pair programming. MIS Quarterly, 33(1), 91–119.doi:10.2307/20650280

Bardoel

E. A.

Pettit

T. M.

De Cieri

McMillan

. (2014). Employee resilience: An emerging challenge for HRM. Asia Pacific Journal of Human Resources, 52(3), 279–297.doi:10.1111/1744-7941.12033

Batra

Xia

Rathor

. (2016). Agility facilitators for contemporary software development. Journal of Database Management, 27(1), 1–28.doi:10.4018/JDM.2016010101

Bear

J. B.

Woolley

A. W

. (2011). The role of gender in team collaboration and performance. Interdisciplinary Science Reviews, 36(2), 146–153.doi:10.1179/030801811X13013181961473

Beck

Andres

. (2004). Extreme programming explained: Embrace change (2nd ed.). Addison-Wesley Professional.

Beck

Beedle

van Bennekum

Cockburn

Cunningham

Fowler

Grenning

Highsmith

Hunt

Jeffries

Kern

Marick

Martin

R. C.

Mellor

Schwaber

Sutherland

Thomas

. (2001). Manifesto for agile software development. http://www.agilemanifesto.org/.

Bergheim

Nielsen

M. B.

Mearns

Eid

. (2015). The relationship between psychological capital, job satisfaction, and safety perceptions in the maritime industry. Safety Science, 74, 27–36.doi:10.1016/j.ssci.2014.11.024

10.

Bittner

E. A. C.

Leimeister

J. M

. (2014). Creating shared understanding in heterogeneous work groups: Why it matters and how to achieve it. Journal of Management Information Systems, 31(1), 111–144.doi:10.2753/MIS0742-1222310106

11.

Black

S. E.

Boca

P. P.

Bowen

J. P.

Gorman

Hinchey

. (2009). Formal versus agile: Survival of the fittest. IEEE Computer, 42(9), 37–45.doi:10.1109/MC.2009.284

12.

Boehm

B. W

. (1988). A spiral model of software development and enhancement. IEEE Computer, 21(5), 61–72.doi:10.1109/2.59

13.

Boehm

Turner

. (2004). Balancing agility and discipline: A guide for the perplexed. Addison-Wesley.

14.

Bouchard

T. J

. (1976). Field research methods: Interviewing, questionnaires, participant observation, systematic observation, unobtrusive measures. In Dunnette

M. D.

(Ed.), Handbook of industrial and organizational psychology (pp. 363–413). Rand McNally.

15.

Bunderson

J. S.

Boumgarden

. (2010). Structure and learning in self-managed teams: Why “bureaucratic” teams can be better learners. Organization Science, 21(3), 609–624.doi:10.1287/orsc.1090.0483

16.

Byrd

T. A.

Cossick

K. L.

Zmud

R. W

. (1992). A synthesis of research on requirements analysis and knowledge acquisition techniques. MIS Quarterly, 16(1), 117–138.doi:10.2307/249704

17.

Cao

Mohan

Ramesh

. (2009). A framework for adapting agile development methodologies. European Journal of Information Systems, 18(4), 332–343.doi:10.1057/ejis.2009.26

18.

Carmeli

Gittell

J. H

. (2009). High-quality relationships, psychological safety, and learning from failures in work organizations. Journal of Organizational Behavior, 30(6), 709–729.doi:10.1002/job.565

19.

Chae

Poole

M. S

. (2005). The surface of emergence in systems development: Agency, institutions, and large-scale information systems. European Journal of Information Systems, 14(1), 19–36.doi:10.1057/palgrave.ejis.3000519

20.

Chakravarty

Grewal

Sambamurthy

. (2013). Information technology competencies, organizational agility, and firm performance: Enabling and facilitating roles. Information Systems Research, 24(4), 976–997.doi:10.1287/isre.2013.0500

21.

Chow

Cao

D.-B

. (2008). A survey study of critical success factors in agile software projects. Journal of Systems and Software, 81(6), 961–971.doi:10.1016/j.jss.2007.08.020

22.

Cockburn

Highsmith

. (2001). Agile software development, the people factor. IEEE Computer, 34(11), 131–133.doi:10.1109/2.963450

23.

Conboy

. (2009). Agility from first principles: Reconstructing the concept of agility in information systems development. Information Systems Research, 20(3), 329–354.doi:10.1287/isre.1090.0236

24.

Corvera Charaf

Rosenkranz

Holten

. (2013). The emergence of shared understanding: Applying functional pragmatics to study the requirements development process. Information Systems Journal, 23(2), 115–135.doi:10.1111/j.1365-2575.2012.00408.x

25.

Cule

Schmidt

Lyytinen

Keil

. (2000). Strategies for heading off is project failure. Information Systems Management, 17(2), 61–69.doi:10.1201/1078/43191.17.2.20000301/31229.8

26.

DeMarco

Lister

. (1987). Peopleware: Productive projects and teams. Dorset House Publishing Co., Inc.

27.

DeSanctis

Poole

M. S

. (1994). Capturing the complexity in advanced technology use: Adaptive structuration theory. Organization Science, 5(2), 121–147.doi:10.1287/orsc.5.2.121

28.

Detert

J. R.

Burris

E. R

. (2007). Leadership behavior and employee voice: Is the door really open? Academy of Management Journal, 50(4), 869–884.doi:10.5465/amj.2007.26279183

29.

DevOps Research & Assessment, & Google Cloud . (2019). The 2019 Accelerate State of Devops .

30.

Dibbern,

Winkler,

Heinzl,

. (2008). Explaining variations in client extra costs between software projects offshored to India. MIS Quarterly, 32(2), 333–366.doi:10.2307/25148843

31.

Diegmann

Dreesen

Binzer

Rosenkranz

. (2018). Journey towards agility: Three decades of research on agile information systems development [Conference session]. In International Conference on Information Systems (ICIS 2018), San Francisco, CA.

32.

Diegmann

Rosenkranz

. (2017). Team diversity and performance—How agile practices and psychological safety interact [Conference session]. International Conference on Information Systems, Seoul, South Korea.

33.

Dikert

Paasivaara

Lassenius

. (2016). Challenges and success factors for large-scale agile transformations: A systematic literature review. Journal of Systems and Software, 119, 87–108.doi:10.1016/j.jss.2016.06.013

34.

Dingsøyr

Moe

N. B.

Seim

E. A

. (2018). Coordinating knowledge work in multiteam programs: Findings from a large-scale agile development program. Project Management Journal, 49(6), 64–77.

35.

Dubé,

Paré,

. (2003). Rigor in information systems positivist case research: Current practices, trends, and recommendations. MIS Quarterly, 27(4), 597–635.doi:10.2307/30036550

36.

Dybå

Dingsøyr

. (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology, 50(9-10), 833–859.doi:10.1016/j.infsof.2008.01.006

37.

Dybå

Dingsøyr

. (2009). What do we know about agile software development? IEEE Software, 26(5), 6–9.doi:10.1109/MS.2009.145

38.

Edmondson

. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly, 44(2), 350–383.doi:10.2307/2666999

39.

Eisenberg

E. M.

Goodall

H. L.

Jr Trethewey

. (2013). Organizational communication: Balancing creativity and constraint. Macmillan Higher Education.

40.

Ellinger

A. D.

Bostrom

R. P

. (1999). Managerial coaching behaviors in learning organizations. Journal of Management Development, 18(9), 752–771.doi:10.1108/02621719910300810

41.

Freudenberg

Sharp

. (2010). The top 10 burning research questions from practitioners. IEEE Software, 27(5), 8–9.doi:10.1109/MS.2010.129

42.

Fruhling

A. N. N.

de Vreede

G.-J

. (2006). Field experiences with extreme programming: Developing an emergency response system. Journal of Management Information Systems, 22(4), 39–68.doi:10.2753/MIS0742-1222220403

43.

Gallivan

M. J.

Keil

. (2003). The user-developer communication process: A critical case study. Information Systems Journal, 13(1), 37–68.doi:10.1046/j.1365-2575.2003.00138.x

44.

Gerwin

Barrowman

N. J

. (2002). An evaluation of research on integrated product development. Management Science, 48(7), 938–953.doi:10.1287/mnsc.48.7.938.2818

45.

Gorecki

Berthon

DesAutels

Donnellan

Teigland

. (2008). The multinational’s nemesis: The rise of ICT-enabled distributed collective intelligence?

ICIS 2008 Proceedings,

1–6.

46.

Gregory

Barroca

Sharp

Deshpande

Taylor

. (2016). The challenges that challenge: Engaging with agile practitioners’ concerns. Information and Software Technology, 77, 92–104.doi:10.1016/j.infsof.2016.04.006

47.

Hashimoto

Loucks

D. P.

Stedinger

J. R

. (1982). Reliability, resiliency, robustness, and vulnerability criteria for water resource systems. Water Resources Research, 18(1), 14–20.doi:10.1029/WR018i001p00014

48.

Healey

M. P.

Vuori

Hodgkinson

G. P

. (2015). When teams agree while disagreeing: Reflexion and reflection in shared cognition. Academy of Management Review, 40(3), 399–422.doi:10.5465/amr.2013.0154

49.

Heeager

L. T

. (2012). Introducing agile practices in a documentation-driven software development practice: A case study. Journal of Information Technology Case and Application Research, 14(1), 3–24.doi:10.1080/15228053.2012.10845693

50.

Herbsleb

J. D.

Mockus

. (2003). An empirical study of speed and communication in globally distributed software development. IEEE Transactions on Software Engineering, 29(6), 481–494.doi:10.1109/TSE.2003.1205177

51.

Highsmith

Cockburn

. (2001). Agile software development: The business of innovation. IEEE Computer, 34(9), 120–127.doi:10.1109/2.947100

52.

Hirschheim

Klein

Lyytinen

. (1995). Information systems development and data modeling: Conceptual and philosophical foundations. Cambridge University Press.

53.

Hoda

Noble

Marshall

. (2011). The impact of inadequate customer collaboration on self-organizing agile teams. Information and Software Technology, 53(5), 521–534.doi:10.1016/j.infsof.2010.10.009

54.

Holling

C. S

. (1973). Resilience and stability of ecological systems. Annual Review of Ecology and Systematics, 4(1), 1–23.doi:10.1146/annurev.es.04.110173.000245

55.

Holmqvist

Pessi

. (2006). Agility through scenario development and continuous implementation: A global aftermarket logistics case. European Journal of Information Systems, 15(2), 146–158.doi:10.1057/palgrave.ejis.3000602

56.

Hong

Thong

J. Y. L.

Chasalow

L. C.

Dhillon

. (2011). User acceptance of agile information systems: A model and empirical test. Journal of Management Information Systems, 28(1), 235–272.doi:10.2753/MIS0742-1222280108

57.

Hummel

Rosenkranz

Holten

. (2015). The role of social agile practices for direct and indirect communication in information systems development teams. Communications of the Association for Information Systems, 36, 273–300.doi:10.17705/1CAIS.03615

58.

Ilgen

D. R.

Hollenbeck

J. R.

Johnson

Jundt

. (2005). Teams in organizations: From input-process-output models to IMOI models. Annual Review of Psychology, 56(1), 517–543.doi:10.1146/annurev.psych.56.091103.070250

15709945

59.

Janes

A. A.

Succi

. (2012). The dark side of agile software development [Symposium]. Proceedings of the ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software, ACM. 215–228.

60.

Jehn

K. A.

Jonsen

Rispens

. (2014). Relationships at work: Intragroup conflict and the continuation of task and social relationships in workgroups. Current Topics in Management, 17, 1–23.

61.

Kautz

Madsen

Nørbjerg

. (2007). Persistent problems and practices in information systems development. Information Systems Journal, 17(3), 217–239.doi:10.1111/j.1365-2575.2007.00222.x

62.

Ko,

D.-G.

Kirsch,

L. J.

King,

W. R

. (2005). Antecedents of knowledge transfer from consultants to clients in enterprise system implementations. MIS Quarterly, 29(1), 59–85.doi:10.2307/25148668

63.

Kotlarsky

. (2007). Re-Engineering at Lecroy Corporation: The move to component-based systems. Journal of Information Technology, 22(4), 265–278.doi:10.1057/palgrave.jit.2000099

64.

Kozlowski

S. W. J.

Ilgen

D. R

. (2006). Enhancing the effectiveness of work groups and teams. Psychological Science in the Public Interest, 7(3), 77–124.doi:10.1111/j.1529-1006.2006.00030.x

65.

Kraut

R. E.

Streeter

L. A

. (1995). Coordination in software development. Communications of the ACM, 38(3), 69–81.doi:10.1145/203330.203345

66.

Kroll

Kruchten

. (2003). The rational unified process made easy: A practitioner’s guide to the RUP (4th ed.). Addison-Wesley.

67.

Kruchten

. (2004). The rational unified process: An introduction (3rd ed.). Addison-Wesley.

68.

Laanti

Salo

Abrahamsson

. (2011). Agile methods rapidly replacing traditional methods at Nokia: A survey of opinions on agile transformation. Information and Software Technology, 53(3), 276–290.doi:10.1016/j.infsof.2010.11.010

69.

Lee

A. S

. (1989a). Case studies as natural experiments. Human Relations, 42(2), 117–137.doi:10.1177/001872678904200202

70.

Lee

A. S

. (1989b). A scientific methodology for MIS case studies. MIS Quarterly, 13(1), 33–50.doi:10.2307/248698

71.

Lee

A. S

. (1991). Integrating positivist and interpretive approaches to organizational research. Organization Science, 2(4), 342–365.doi:10.1287/orsc.2.4.342

72.

Lee,

Xia,

. (2010). Toward agile: An integrated analysis of quantitative and qualitative field data on software development agility. MIS Quarterly, 34(1), 87–114.doi:10.2307/20721416

73.

Lengnick-Hall

C. A.

Beck

T. E.

Lengnick-Hall

M. L

. (2011). Developing a capacity for organizational resilience through strategic human resource management. Human Resource Management Review, 21(3), 243–255.doi:10.1016/j.hrmr.2010.07.001

74.

Liang

Farh

C. I. C.

Farh

J.-L

. (2012). Psychological antecedents of promotive and prohibitive voice: A two-wave examination. Academy of Management Journal, 55(1), 71–92.doi:10.5465/amj.2010.0176

75.

Lindsjørn

Sjøberg

D. I. K.

Dingsøyr

Bergersen

G. R.

Dybå

. (2016). Teamwork quality and project success in software development: A survey of agile development teams. Journal of Systems and Software, 122, 274–286.doi:10.1016/j.jss.2016.09.028

76.

Loftus

E. F

. (1975). Leading questions and the eyewitness report. Cognitive Psychology, 7(4), 560–572.doi:10.1016/0010-0285(75)90023-7

77.

Long

Siau

. (2007). Social network structures in open source software development teams. Journal of Database Management, 18(2), 25–40.doi:10.4018/jdm.2007040102

78.

Mangalaraj

Mahapatra

Nerur

. (2009). Acceptance of software process innovations—The case of extreme programming. European Journal of Information Systems, 18(4), 344–354.doi:10.1057/ejis.2009.23

79.

Martin

. (1991). Rapid application development. Macmillan Publishing Co., Inc.

80.

Martins

L. L.

Schilpzand

M. C.

Kirkman

B. L.

Ivanaj

. (2013). A contingency view of the effects of cognitive diversity on team performance: The moderating roles of team psychological safety and relationship conflict. Small Group Research, 44(2), 96–126.

81.

Maruping

L. M.

Venkatesh

Agarwal

. (2009). A control theory perspective on agile methodology use and changing user requirements. Information Systems Research, 20(3), 377–399.doi:10.1287/isre.1090.0238

82.

Maruping

L. M.

Zhang

Venkatesh

. (2009). Role of collective ownership and coding standards in coordinating expertise in software project teams. European Journal of Information Systems, 18(4), 355–371.doi:10.1057/ejis.2009.24

83.

McAvoy

Butler

. (2009). A failure to learn by software developers: Inhibiting the adoption of an agile software development methodology. Journal of Information Technology Case and Application Research, 11(1), 23–46.doi:10.1080/15228053.2009.10856152

84.

McAvoy

Nagle

Sammon

. (2013). Using mindfulness to examine ISD agility. Information Systems Journal, 23(2), 155–172.doi:10.1111/j.1365-2575.2012.00405.x

85.

McGregor

Doshi

. (2018). Why agile goes awry—And how to fix it. Harvard Business Review. https://hbr.org/2018/10/why-agile-goes-awry-and-how-to-fix-it.

86.

McHugh

Conboy

Lang

. (2011). Agile practices: The impact on trust in software project teams. IEEE Software, 29(3), 71–76.doi:10.1109/MS.2011.118

87.

Meneghel

Salanova

Martínez

I. M

. (2016). Feeling good makes us stronger: How team resilience mediates the effect of positive emotions on team performance. Journal of Happiness Studies, 17(1), 239–255.doi:10.1007/s10902-014-9592-6

88.

Miles

M. B.

Huberman

A. M

. (1994a). Qualitative data analysis: An expanded sourcebook. Sage Publications.

89.

Miles

M. B.

Huberman

A. M

. (1994b). Qualitative data analysis: A sourcebook of new methods. Sage.

90.

Mishler

E. G

. (1986). Research interviewing: Context and narrative. Harvard University Press.

91.

Nan,

. (2011). Capturing bottom-up information technology use processes: A complex adaptive systems model. MIS Quarterly, 35(2), 505–540.doi:10.2307/23044054

92.

Nederhof

A. J

. (1985). Methods of coping with social desirability bias: A review. European Journal of Social Psychology, 15(3), 263–280.doi:10.1002/ejsp.2420150303

93.

Nembhard

I. M.

Edmondson

A. C

. (2006). Making it safe: The effects of leader inclusiveness and professional status on psychological safety and improvement efforts in health care teams. Journal of Organizational Behavior, 27(7), 941–966.doi:10.1002/job.413

94.

Niederman

Lechler

Petit

. (2018). A research agenda for extending agile practices in software development and additional task domains. Project Management Journal, 49(6), 3–17.doi:10.1177/8756972818802713

95.

Oxford English Dictionary . (2019). “Resilience.” Oxford University Press.

96.

Persson

J. S.

Mathiassen

Aaen

. (2012). Agile distributed software development: Enacting control through media and context. Information Systems Journal, 22(6), 411–433.doi:10.1111/j.1365-2575.2011.00390.x

97.

Phillips

K. W.

Northcraft

G. B.

Neale

M. A

. (2006). Surface-level diversity and decision-making in groups: When does deep-level similarity help? Group Processes & Intergroup Relations, 9(4), 467–482.doi:10.1177/1368430206067557

98.

Pohl

. (1994). The three dimensions of requirements engineering: A framework and its applications. Information Systems, 19(3), 243–258.doi:10.1016/0306-4379(94)90044-2

99.

Poppendieck

. (2003). Lean software development: An agile toolkit. Addison-Wesley.

100.

Project Management Institute (PMI) . (2017). A guide to the project management body of knowledge (PMBOK ^® guide) – Sixth edition. Author.

101.

Przybilla

Wiesche

Krcmar

. (2018). The influence of agile practices on performance in software engineering teams: A subgroup perspective [Conference session]. Proceedings of the 2018 ACM SIGMIS Conference on Computers and People Research, ACM. 33–40.

102.

Ramesh

Cao

Baskerville

. (2010). Agile requirements engineering practices and challenges: An empirical study. Information Systems Journal, 20(5), 449–480.doi:10.1111/j.1365-2575.2007.00259.x

103.

Recker

Holten

Hummel

Rosenkranz

. (2017). How agile practices impact customer responsiveness and development success: A field study. Project Management Journal, 48(2), 99–121.doi:10.1177/875697281704800208

104.

Rigby

D. K.

Henderson

D’Avino

. (2018). How agile teams can help turnarounds succeed. Harvard Business Review. https://hbr.org/2018/07/how-agile-teams-can-help-turnarounds-succeed.

105.

Roberge

M-É.

van Dick

. (2010). Recognizing the benefits of diversity: When and how does diversity increase group performance? Human Resource Management Review, 20(4), 295–308.doi:10.1016/j.hrmr.2009.09.002

106.

Rosenkranz

Charaf

M. C.

Holten

. (2013). Language quality in requirements development: Tracing communication in the process of information systems development. Journal of Information Technology, 28(3), 198–223.doi:10.1057/jit.2012.33

107.

Rosenkranz

Holten

Räkers

Behrmann

. (2017). Supporting the design of data integration requirements during the development of data warehouses: A communication theory-based approach. European Journal of Information Systems, 26(1), 84–115.doi:10.1057/ejis.2015.22

108.

Rosenkranz

Vranesic

Holten

. (2014). Boundary interactions and motors of change in requirements elicitation: A dynamic perspective on knowledge sharing. Journal of the Association for Information Systems, 15(6), 306–345.

109.

Royce

W. W

. (1970). Managing the development of large software systems: Concepts and techniques. Proceedings of WesCon, Monterey, CA, USA, pp. 328–338.

110.

Russell Bernard

. (2002). Research methods in anthropology-qualitative and quantitative approaches (3rd ed.). AltaMira Press.

111.

Saldaña

. (2016). The coding manual for qualitative researchers. Sage.

112.

Sarker

Munson

C. L.

Sarker

Chakraborty

. (2009). Assessing the relative contribution of the facets of agility to distributed systems development success: An analytic hierarchy process approach. European Journal of Information Systems, 18(4), 285–299.doi:10.1057/ejis.2009.25

113.

Sawyer

Farber

Spillers

. (1997). Supporting the social processes of software development. Information Technology & People, 10(1), 46–62.doi:10.1108/09593849710166156

114.

Sawyer

Guinan

P. J.

Cooprider

. (2010). Social interactions of information systems development teams: A performance perspective. Information Systems Journal, 20(1), 81–107.doi:10.1111/j.1365-2575.2008.00311.x

115.

Schaubroeck

Lam

S. S. K.

Peng

A. C

. (2011). Cognition-based and affect-based trust as mediators of leader behavior influences on team performance. Journal of Applied Psychology, 96(4), 863–871.doi:10.1037/a0022625

21299271

116.

Schmidt

Kude

Heinzl

Mithas

. (2014). How agile practices influence the performance of software development teams: The role of shared mental models and backup [Conference session]. International Conferencee on Information Systems (ICIS 2014), Auckland, New Zealand.

117.

Schulte

Cohen

N. A.

Klein

K. J

. (2012). The coevolution of network ties and perceptions of team psychological safety. Organization Science, 23(2), 564–581.doi:10.1287/orsc.1100.0582

118.

Schwaber

. (1995). Scrum development process [Conference session]. Conference on Object-Oriented Programming Systems, Languages, and Applications, Austin, TX, USA. 117–134.

119.

Siau

Long

Ling

. (2010). Toward a unified model of information systems development success. Journal of Database Management, 21(1), 80–101.doi:10.4018/jdm.2010112304

120.

Singh

Winkel

D. E.

Selvarajan

T. T

. (2013). Managing diversity at work: Does psychological safety hold the key to racial differences in employee performance? Journal of Occupational and Organizational Psychology, 86(2), 242–263.doi:10.1111/joop.12015

121.

Strauss

Corbin

. (1998). Basics of qualitative research. Sage.

122.

Sweetman

Conboy

. (2018). Portfolios of agile projects: A complex adaptive systems’ agent perspective. Project Management Journal, 49(6), 18–38.

123.

Tan

. (1994). Establishing mutual understanding in systems design: An empirical study. Journal of Management Information Systems, 10(4), 159–182.

124.

Tripp

Armstrong

D. J

. (2018). Agile methodologies: Organizational adoption motives, tailoring, and performance. Journal of Computer Information Systems, 58(2), 170–179.doi:10.1080/08874417.2016.1220240

125.

Tripp

Rienemschneider

Thatcher

. (2016). Job satisfaction in agile development teams: Agile development as work redesign. Journal of the Association for Information Systems, 17(4), 267–307.doi:10.17705/1jais.00426

126.

van Kelle

van der Wijst

Plaat

Visser

. (2015). An empirical study into social success factors for agile software development. Proceedings of the Eighth International Workshop on Cooperative and Human Aspects of Software Engineering, IEEE Press, pp. 77–80.

127.

van Oorschot

K. E.

Sengupta

Van Wassenhove

L. N

. (2018). Under pressure: The effects of iteration lengths on agile software development performance. Project Management Journal, 49(6), 78–102.

128.

VersionOne . (2018). 12th state of agile report. https://explore.versionone.com/state-of-agile/versionone-12th-annual-state-of-agile-report

129.

Vidgen

Wang

. (2009). Coevolving systems and the organization of agile software development. Information Systems Research, 20(3), 355–376.doi:10.1287/isre.1090.0237

130.

Wang

Hahn

. (2015). Crowd experience and performance: An empirical analysis of crowdsourced new product development. ICIS 2015 Proceedings, pp. 1–20.

131.

Weber

R. P

. (1990). Basic content analysis. Sage.

132.

Yin

R. K

. (2003). Case study research: Design and methods (3rd ed.). Sage.

Investigating the “Socio” in Socio-Technical Development: The Case for Psychological Safety in Agile Information Systems Development

Abstract

Keywords

Introduction

Related Work

Information Systems Development, Project Management, and Agile Approaches

Team Resilience

Psychological Safety

Theory Development

Research Design

Case Overviews and Data Collection

Data Analysis

Results

Discussion, Implications, and Limitations

Discussion of Propositions

P1: Usage of Social Agile Practices Positively Affects Performance.

P2: Increased Usage of Social Agile Practices Positively Affects Psychological Safety and Increased Psychological Safety Fosters the Use of Social Agile Practices.

P3: Psychological Safety Enables and Enforces the Positive Effect of SAPs on Performance.

Consolidation

Future Research and Implications

Transferability to General Project Management

Limitations

Conclusion

Footnotes

Appendix A

Appendix B

Declaration of Conflicting Interests

Funding

Author Biographies

References

P₁: Usage of Social Agile Practices Positively Affects Performance.

P₂: Increased Usage of Social Agile Practices Positively Affects Psychological Safety and Increased Psychological Safety Fosters the Use of Social Agile Practices.

P₃: Psychological Safety Enables and Enforces the Positive Effect of SAPs on Performance.