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
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.

Resulting research model.
Construct Summaries
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 P1:
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 P2:
Building upon this argument for P2, 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. P3 resembles this proposition:
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.
Case Site Overview
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.
Interviewee Overview
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.

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.
Identified Codes and Codings
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 P1 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 P2 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 P2 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 P2, 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 P3 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.
P1: Usage of Social Agile Practices Positively Affects Performance.
As pointed out in our results section, we found clear support 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), 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.
P2: 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 P2. 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.
P3: 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 P2, 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
