Antecedents of Psychological Safety in Agile Software Development Teams

Context: Psychological safety continues to inspire researchers’ curiosity in various fields of study. It has been shown to enhance teams’ performance, efficiency, and learning, among other corollaries. Researchers are stretching the boundaries of these early findings to identify further effects of psychological safety. Recent work shows that psychological safety promotes knowledge sharing, norm clarity, and complements agile values. Objective: Studies show that psychological safety enhance agile values and practices, and some practitioners went as far as to claim ‘‘agile doesn’t work without psychological safety.’’ Yet, researchers have not explored its antecedents. In this study, we sought to understand how psychological safety materializes in agile software development teams. Method: We opted for a two-phase mixed-methods study; an exploratory qualitative phase (18 interviews) followed by a quantitative phase (survey study, N = 365) to broaden the empirical coverage and test phase one’s findings. Results: Our findings show that psychological safety is established in agile software teams when individuals, the team, and the leadership adopt and promote strategies conducive to promoting a psychologically safe workplace. While openness and no blame towards team members are the ‘‘butter and bread’’ of psychological safety, collective-decision making within the team and the leadership ownership remain the pillars of a psychologically safe workplace. Conversely, team autonomy, technical practices providing a safety net and slack time were not found to promote psychological safety. Conclusion: To institutionalize psychological safety in agile software teams, individuals, teams, and the leadership should consolidate their effort to adopt no blame, openness, collective decision-making in the team, and assuming the ownership of promoting a psychologically safe workplace.


INTRODUCTION
The concept of psychological safety originated in the seminal work of Schein and Bennis [41] in the 1960s.They defined it as the degree to which people feel safe and confident in their ability to deal with change [41].A quarter of a century after Schein and Bennis, Kahn [25] renewed interest in psychological safety.In the late 1990s, the concept was revived again in organizational studies, prominently by Edmondson's work [18].
Psychological safety is the shared belief among team members that it is safe to take interpersonal risks in the workplace [18].In a psychologically safe work climate, individuals feel confident that they will not be rejected or blamed by other team members for speaking up, making their views and opinions known, feel that it is safe to experiment and take risks and trust that their peers will engage in constructive dialogue when conflicts arise [18].Psychological safety has been linked to various outcomes, e.g., learning and performance, at the individual and team levels of analysis [19].
There is a timid increased interest in the topic of psychological safety in software development teams, most apparent in the information systems community.The focus has been, so far, exploring potential outcomes of psychological safety not covered by social sciences work and more relevant to software teams.Researchers investigated the role of psychological safety in promoting knowledge sharing [45] and supporting agile practices [6,13,24,42].Still, there is a scarcity of work dedicated to psychological safety in agile software development teams, especially on the antecedents.
Agile methods aim to improve the agility of a software development team (i.e., its ability to create and respond to change) by relying on iterative development, self-organizing teams, craftsmanship, and processes that are light and manoeuvrable while providing adequate coordination for project behaviors [9].To date, agile software development (ASD) methods have become mainstream [14,17,27].
Very little research has been done on psychological safety in the context of ASD, even though it plays a crucial role according to organizational research and Google's renowned Artistotle project [15].Positive effects of psychological safety on team performance [6,20,28], job satisfaction [28], and team reflexivity [6] have been supported by research.Some antecedents of psychological safety, such as team autonomy, boundary reinforcement, boundary buffering, and boundary spanning, have also been supported [20].Social agile practices and psychological safety are mutually reinforcing, according to qualitative research on psychological safety in IS projects [24].Furthermore, a lack of psychological safety might be a significant barrier to agile transformations [42].Even though these studies have provided useful information, there is a major gap in the current literature on psychological safety in ASD.While there is substantial evidence of the antecedents of psychological safety from organizational studies, there is little work on the antecedents in the specific context of ASD.This is unfortunate because agile teams, with their focus on close customer collaboration, changing requirements, and iterative development [9], may face challenges in establishing psychological safety that may differ from the challenges in, for example, the medical teams that were in the focus of Edmondson's seminal work.Hence, we propose to investigate: RQ: How does psychological safety materialize in agile software development teams?Understanding software engineering in its social context is significant and relevant because it has practical consequences that shape not only how we see software engineering in its social context but also how we may utilize the latter to foster better results.For example, Alami and Krancher [1] found that psychologically safe Scrum teams achieve better software quality.In a psychologically safe Scrum work environment, team members care about quality by speaking out about it and attempting to improve it without fear or guilt.Consequently, errors and defects are identified, and the required efforts to achieve quality are spent.Developers care about quality and will go beyond lengths to ensure it when they feel safe doing so [1].
We opted for a mixed methods study (Qualitative → Quantitative) [10].The first phase was inductive and qualitative, aiming at gaining insights into how psychological safety is created and maintained in agile software teams.Constructs, dimensions, and propositions yielded in this phase were translated into hypotheses for a subsequent confirmatory phase using survey instruments.This allowed us not only to test the hypotheses drawn from the first phase but also to broaden the empirical basis we used to draw conclusions.This research design is valid when the phenomenon under study is less understood [10].Although psychological safety has been associated with several outcomes (e.g., performance and learning), to the best of our knowledge, no prior work have attempted to unveil its antecedents in ASD.Hence, we used interviews with 18 software developers and quality assurance (QA) professionals to explore the topic; then we tested the resulting hypotheses using a survey with N = 365 respondents.
Our findings show that psychological safety has three levels of antecedents in agile software teams; leadership, team, and individual.The combined effort invested by these roles to build a psychologically safe environment results in sustained benefits.Building a psychologically safe work environment is not, by all means, a oneoff process; it is a continuous endeavor where all parties contribute to establishing and sustaining psychological safety.For example, while leadership ownership is essential to establish psychological safety, they still need to show continuous support to the team and "walk the talk" to maintain high psychological safety.
We start by reviewing related work in section 2. We describe how we measured psychological safety in section 3.Then, we present our methods in section 4. Section 5 is devoted to interpreting our first and second phases' data.Then, we discuss the implications of our findings in section 6 and make recommendations for organizations seeking to implement an agile method to enhance their teams' psychological safety.We highlight the limitations, the study's assumptions, and threats to validity in section 7. We conclude in section 8.

RELATED WORK
Our search for related work shows scarce work on the topic in the software engineering communities.This lack of focus on this topic limits not only our understanding of the micro and macro levels of psychological safety antecedents and outcomes but also our capacity to understand whether psychological safety and its implications vary in software engineering teams.In addition, we are still not in a position to translate the long-standing contributions of the social sciences to software engineering contexts.In this section, we highlight the antecedents of psychological safety identified in social science work.We also summarize a growing work in information systems on psychological safety in agile teams.

Antecedents of psychological safety
The attainment of a psychologically safe workplace is highly influenced by supportive leadership behaviors [34].It entails a leadership exhibiting inclusiveness [4,8], support [31], trustworthiness [30], and openness [11].Decades of research have shown that these leadership qualities signal to employees that it is safe to take risks and engage in frank communication [34].Newman et al. [34] assert that displaying these behaviors at one point in time is not enough for a psychologically safe workplace, they argue that the effects will be more enduring when psychological safety is sustained through continuous learning and the leadership behaviors are adopted collectively [34].Similarly, Schaubroeck et al. suggest that consistent supportive leadership behaviors encourage the team and the individual alike to reciprocate such behaviors.Team characteristics have also been linked to psychological safety [40].Behaviors such as sharing rewards [41] and collective responsibility [35] have been attributed to promoting psychological safety within the team.

Psychological safety in agile software teams
Fostering psychological safety in agile software teams has been shown to complement and enhance the functioning of agile methods.Some even claim that it is a prerequisite to encourage behaviors adjunct to agile values and principles [5,42].Buvik and Tkalich [5] investigated the effects of team autonomy, task interdependence and role clarity on psychological safety and whether it influences outcomes such as team reflexivity and performance in agile software development teams [5].Their findings suggest that autonomy significantly affects psychological safety; however, task interdependence and role clarity were not significant [5].The results did not support that team reflexivity mediates the relationship between psychological safety and team performance.Instead, they found that psychological safety and team performance are directly and strongly interrelated [5].Lenberg and Feldt's study also suggests that psychological safety and clarity of team norms affect both performance and job satisfaction in agile software development teams [28].
Thorgren and Caiman [42] found that psychological safety can mitigate workplace culture misalignment with agile values [42].Using a case study, they investigated cultural differences related to attitudes toward inclusiveness, collective responsibility, and openness and their implications for a Scrum implementation.They found that potential clashes and tensions between agile practices, values, and workplace culture can be mitigated when psychological safety is promoted in the team [42].
Hennel and Rosenkranz [24] used three case studies to examine how social agile practices (e.g., daily stand-ups, retrospectives, and  Sprint planning) and psychological safety affect software development team behavior [24].They assert that psychological safety plays a significant role in espousing agile practices.They found that, when psychological safety is high, team members are willing to actively partake in ceremonies, speak their minds and contribute with initiatives to assure continuous improvement.Higher psychological safety also promotes peer helping and learning.They also found that psychological safety and agile practices reinforce each other [24].The work on psychological safety in ASD has, so far, focused on the synergies and selected antecedents.Even though it has brought new insights peculiar to agile implementations, still, it does not zoom into relevant challenges of interest to software engineering such as software quality, the adoption of contemporary software engineering practices, keeping pace with innovation and technology changes, requirements volatility, and other factors.Our work is a small step in this direction.Agile methods are highly sought to improve team efficiency, customer satisfaction and software quality [14]; hence, we purposefully sought to investigate the antecedents of PS.

MEASURING PSYCHOLOGICAL SAFETY
Edmondson [18] argued that psychological safety is best treated as a team-level quality.She developed and validated a 7-item scale to measure team psychological safety [18].This measure includes items that capture shared perceptions amongst team members whether they believe that others will not reject members for being themselves, team members care about each other as individuals, team members have positive intentions to one another, and team members respect the competence of others.Although researchers in the social sciences have used various adaptations of the measures, they have been shown to be a reliable tool to assess team-level psychological safety [34].
We adopted Edmondson's measures to assess the psychological safety of our participants' teams.Table 1 lists the items which we used in both phases of our study.We used these items in Phase I to guide and structure the interview, and in Phase II as a survey instrument to measure the level of psychological safety in the respondent's team.

METHODS
Our methodological choice is influenced by our epistemological stance, pragmatism.Epistemologically, pragmatism is premised on the idea that research should focus on "practical understandings" of concrete, real-world issues and that knowledge should have the potential to influence practices [37].Methodologically, pragmatism advocates for choices based on their relevance to the problem being studied [37].We opted for a mixed methods approach to our inquiry because of its relevance to the phenomenon we sought to understand.More specifically, we chose an exploratory sequential design (Qualitative → Quantitative) [10].In this design, the qualitative phase precedes the quantitative phase, which depends on the outcome of the former [10].In the first phase, we conducted qualitative interviews to generate detailed explanations of how psychological safety emerges in ASD environments and formulate hypotheses based on these explanations.In the second phase, we tested these hypotheses on a broader empirical basis through a survey.Since there was little work on the antecedents of psychological safety in ASD, an exploratory sequential design was judged to be more appropriate than a study that bases hypotheses on prior theories and literature.

Phase I
This phase aimed to explore antecedents of psychological safety as they emanate from practitioners' experiences.Practitioners' experiences are a valid source of knowledge and empirical evidence.Collecting data about practitioners' experiences is a commonly used approach, as practitioners have an emic perspective, which is difficult to obtain otherwise.
Participants' Characteristics & Sampling.We recruited participants using convenience sampling and snowballing [37].We used our industry contacts to help us to recruit software developers and quality assurance (QA) professionals.We received a total of 20 referrals and successfully interviewed 12 participants after the selection process (we opted to interview only practitioners with a minimum of five years experience).We used already interviewed participants to recruit future participants from among their professional acquaintances.This recruitment technique has created a snowballing effect, resulting in additional six participants.Table 2 documents the interviewees of phase I.The column "Sampling" is the sampling technique used to recruit the participant."Exp." is the participant's number of years of experience in software development."Method" refers to the agile methods adopted by the participant's team."Project type" is the type of software being developed by the participant's team."Industry" is the type of business carried out by the participant's employer as stated in their LinkedIn profile."PS level" is the participant's subjective assessment of the team's level of psychological safety.As the table shows, 17 out of the 18 participants assessed their level of psychological safety as high.Although this presented an important bias in our data, we proceeded because phase II would allow us to test our findings in a sample with more variance in psychological safety.The last column is the country where the participant resides and works.We interviewed 18 participants.We limited our interviewees to software developers and QA roles.QAs are software testers part of the agile development team.Both roles have the "nuts and bolts"  Data Collection.We used semi-structured interviews to collect the data for phase I.This method permits flexibility and allows a dynamic discussion.Still, all interviews followed a similar structure based on a predefined interview guide.We designed the guide into three categories: introductory, core, and probing questions.The introductory questions' objectives were to collect data about the participant, her/his team and the level of psychological safety in the team.The introductory questions have also assisted in building up to the core topic of the interview.The core questions were used to gather data related to our research questions.To facilitate depth and breadth during the discussion, we prepared probing questions, which helped us to make the conversations more detailed and concrete.Although we planned probing questions during semistructured interviews, the conversation took different paths in each interview.When that was the case, the researcher was prompted to ask additional questions according to the participant's answers.Table 3 lists examples from our interview guide (full interview guide available, part of the replication package, Sect.4.3).Our participants were dispersed geographically, so all interviews were conducted using Zoom, an audio-video conferencing tool.The interviews lasted 40-90 minutes and generated an average of 17 pages of verbatim transcription.The first author conducted the interviews in the period between January and March 2022.To transcribe the interviews, we used the online transcription tool "otter.ai"2 .We manually checked the transcripts against the recorded audio and made the necessary corrections when required.We asked phase I participants for permission to make anonymized versions of the interview transcripts available (see Sect. 4.3).

Dear [Participant name],
Thanks for accepting to participate in our study.Before we can organize the interview, can you please answer the questions below: If you make mistakes on your team, is it often held against you?(Please answer yes or no and explain briefly) Members of your team can bring up problems and tough issues?(Please answer yes or no and explain briefly) People on your team sometimes reject other for being different.(Please answer yes or no and explain briefly) It is safe to take risks on your team.(Please answer yes or no and explain briefly) It is difficult to ask other members of your team for help.(Please answer yes or no and explain briefly) No one on my team would deliberately act in a way that undermines my efforts.(Please answer yes or no and explain briefly) Working with members of my team, my unique skills and talents are valued and utilized.(Please answer yes or no and explain briefly) Kind regards, Table 4: Questions sent to the interviewees via email prior to the interview Data Analysis.We opted to use Miles et al. 's [32] guidelines for the analysis of the interview data.They [32] propose two consecutive stages of analysis: (1) First Cycle and (2) Second Cycle.During the First Cycle, data "chunks" relevant to our RQ were selected and codes were assigned to them [32].Given the focus of our RQ, we selected text passages that indicated a causal link between specific conditions or actions and psychological safety.This coding exercise aimed at "condensing" the data into meaningful yet initial codes for antecedents to psychological safety [32].We used an inductive approach to coding in this early iteration.This allowed the initial codes to emerge from the raw data, which fits well with the exploratory approach of this phase.In the subsequent Second Cycle, we synthesized the various codes of the First Cycle into a more comprehensive and unified scheme [32].This process is called "pattern coding" [32].Pattern codes were the result of clustering the initial codes either by code types, by codes pertaining to the same topics, concepts or logically mean the same thing, explanations, causes, or relations of constructs [32].
In line with our RQ of how psychological safety materializes in agile software development teams, the pattern codes represented broad conditions or actions that influence psychological safety.Given the breadth of our sample, we were sensitive to the possibility that some pattern codes might emerge only for interviewees that met particular conditions (e.g., only for QA roles).However, no such regularities emerged from the data analysis.Once all pattern codes were finalized, we translated them into hypotheses that would be tested in Phase II.
The first author conducted the First Cycle of coding.Then, the second and third authors reviewed the codes, provided feedback and suggested additional codes.Subsequently, the first author updated and proposed a final list of codes.Then, the first author conducted the Second Cycle of coding before the second and third authors reviewed the proposed pattern codes.This "reliability check" [32,37] process allowed us to consolidate our decisions on coding, and reconcile any differences for more credible conclusions.

Phase II
In the second phase, we extended the empirical coverage and tested the hypotheses using data collected in a survey.Phase I data and analysis allowed us to identify constructs and relations pertinent to our RQ; then, we proposed hypotheses (see Tbl. 6) based on these findings, which we tested in Phase II.
Hypotheses Formulation.Table 6 shows our hypotheses.Each hypothesis translates a pattern code and its relations into propositions that encapsulate the essence and the meaning as emerged from the qualitative analysis.For example, openness has been translated to H7.We found, in Phase I, that openness promotes psychological safety when team members show the willingness to listen and try out other team members' ideas and to accept constructive criticism or even rejections of their own ideas.Then, in Phase II, we proposed H7 to sum up the essence of this finding.
Instrumentation.After the hypothesis formulation, we designed a survey.The survey had 43 questions (see Sect. 4.3) that were designed to measure psychological safety and the concepts identified during Phase I. We conducted a pilot test (N = 20) to assess the validity of our survey instrument; we asked the pilot respondents to provide feedback on every page of the survey.Upon completing the pilot, we examined the free-text comments and performed an exploratory factor analysis of the survey responses in SPSS v. 28.In the exploratory factor analysis, we examined Cronbach alpha values and factor loadings.Although most of the qualitative comments expressed that the survey questions were clear, we performed minor modifications to those survey questions that had low standard deviations, low Cronbach alpha values or low factor loadings.
Upon the completion of the final survey, we performed a confirmatory factor analysis using SmartPLS v 3.3.9. to examine the convergent and discriminant validity and the reliability of our final survey instrument.Convergent validity implies that survey items measuring the same constructs (e.g., the four survey questions measuring collective decision-making) are strongly related, while discriminant validity implies that survey items measuring different constructs are less strongly related [12].We examined convergent validity by examining whether Average Variance Extracted (AVE) was greater than .50for all latent constructs [22].In the first round of analysis, we found convergent validity issues with the fourth item of the autonomy scale and with the second item of the psychological safety scale.Following established procedures for survey research [39], we removed these two items from the analysis.After dropping these items, AVE values were above .5 for all constructs, with the only exception of psychological safety, which had an AVE value of .39(see Tbl. 7).Although these results may suggest that psychological safety has several dimensions, we proceeded by conceptualizing psychological safety as a single construct to retain the consistency of conceptualizations and measurement of psychological safety with prior research (see Sect. 3 for further discussion).
To establish discriminant validity, we verified whether construct correlations were below AVE square roots for all construct pairs [22].As Table 8 shows, the results passed this test.Discriminant validity was also supported by the Heterotrait-Monotrait Ratio Test.Reliability is indicated by Cronbach alpha and composite reliability values above .7 [39].Table 7 shows that all constructs passed this test.
Sampling.We used Prolific, a research market platform, to collect Phase II data.We used purposive sampling to select the population of Phase II.This sampling strategy uses specific characteristics relevant to the study's objective [37].Similar to Phase I, we included software development and QA roles.Upon completing the pilot, we ran a prescreening process to select the population for the final survey.This was because Prolific prescreening data did not meet our requirements.In addition, by prescreening, we become more confident in the quality and reliability of our sample.The prescreening survey had five questions (Tbl.10).The prescreening process was iterative.We launched daily prescreening surveys with a limit of up to 50 respondents.We capped the number of respondents to allow us to scrutinize the prescreening data closely.The prescreening process took place between May 2nd and May 26th 2022.For each iteration of the prescreening, we conducted a six steps elimination process: • Step 1: We eliminated all entries with "No" response to Q1 • Step 2: We eliminated all entries with "Other" response to Q2 and the free text response was not a software development or QA-related role.

Ownership of psychological safety by the leadership
Promoting psychological safety "So we have internal ... training on the company values and they do have like a little how they call it values booklet that we try to the company tries to give each employee as an example.
This is what we try to be as company these are the values that we like to have and they're trying to do all kinds of exercises to socialize these values" (P11).
Management listening to the team "they [management] listen and they adjust the client expectations all the time and they try to protect us from the client pressuring us.We feel much much less pressure" (P6).
Management supporting the team "When I felt relieved because I was very frustrated, I was angry.But when he [team lead] stepped up, he supported me, defended me, he talked about it he talked to the management, and he also explained me the things that may have made me felt better" (P5).
"...I am responsible to resolve the issue.But my lead or manager will be the one who will be questioning and backing me" (P8).
Leadership integrity "in order to be a great developer and a great leader, you need to be able to see our mistakes, and not hide them.And bring them back again, you know, to the surface, and willing to admit your mistake" (P3, Tech lead).We eliminated all entries with "Other" response to Q3 and the free text response was not an agile method • Step 4: We eliminated all entries with "False" responses to Q4 • Step 5: We filtered all entries with Q5 answers either "strongly disagree", or "somewhat disagree." Then, we examined the comments of the free text (i.e., Q6) to assess the rationale behind the disagreement.None of these cases were genuine responses; they were either ambiguous or uncomprehensive, indicating that the respondent was not a genuine software developer or QA.Then, we eliminated all "strongly disagree" and "somewhat disagree" entries.Then, we filtered "neither agree nor disagree" to examine Q6.First, we looked for categorical objections to the definition, then the entry would have been eliminated (no such cases were found in all iterations).Then, if the disagreement with the definition was based on reservations, the entry was not excluded.For example, a respondent commented: "software quality can not be solely described by satisfying the various stakeholders needs." We deemed this objection rational, as the comment hints that the definition disregards the internal features of software quality, such as code quality and the actual design of the software.To sum up, "strongly disagree" and "somewhat disagree" entries were not genuine respondents based on the qualitative comments.Respondents who selected "neither agree nor disagree" had genuine reservations about the definition and were not excluded.• Step 6: For the remaining entries (i.e., "somewhat agree" and "strongly agree"), we examined every comment of the Q6 text field to assess the quality of the response and thus qualify the participant's eligibility to participate in Phase II.
We eliminated entries that we deemed to be ambiguous, inauthentic or uncomprehensive or that indicated low efforts made by the participant.
The prescreening phase attracted 914 respondents.Then, the qualifying process (steps discussed above) yielded a reliable sample of 436 potential participants.Still, we included additional quality control measures in the main survey to assure the quality of our data.
Data Quality Control.Aware of potential data quality issues using a research marketplace, we implemented several methods to assure the quality of our data discussed in the literature [29].To what extent do you agree with these statements: 1 -In our team, we are responsible for deciding how to organize our work 2 -In our team, we decide how to achieve our goals 3 -In our team, we make the decisions regarding the technical solutions with no interferences from management or our stakeholders 4 -In our team, we make decisions regarding the tasks' estimation 5 -In our team, we make the decisions for changing our processes in order to improve our performance (2) Collective Decision Making .83.88.66 Four Likert Scale (5 level scale, i.e., "Strongly agree" to "Strongly disagree") questions.
To what extent do you agree with these statements: 1 -In our team, we engage in constructive discussions to make our decisions 2 -In our team, each team member's voice counts when decisions are made 3 -In our team, we make decisions based on the best arguments that team members contribute 4 -In our team, we aim to reach consensus when make our decisions To what extent do you agree with these statements: 1 -People in our team are open to criticism and feedback from their peers 2 -People in our team always welcome new ideas and initiatives put forward by their peers 3 -People in our team do not reject ideas based on the individual who proposed it but based on the strength and the soundness of the idea 4 -People in our team accept the rejection of new ideas when the rejection is based on strong arguments 5 -People in our team accept the rejection of ideas when they fail to convince team members with their arguments (6) Psychological safety .70.79.39 Seven Likert Scale (5 level scale, i.e., "Strongly agree" to "Strongly disagree") questions.
To what extent do you agree with these statements: 1 -"If you make mistakes on my team, is it often held against you" 2 -"Members of my team can bring up problems and tough issues" 3 -"People on my team sometimes reject others based on the ideas they propose" 4 -"It is safe to take a risk (e.g., experiment with a new technology, propose initiatives, raise difficult issues, disclose own knowledge gaps) on my team" 5 -"I feel comfortable asking my team members for help" 6 -"No one on my team would deliberately act in a way that undermine my efforts" 7 -"Working with members of my team, my unique skills and talents are valued and utilized"

Q5
We use ISO/IEC 25010 definition of software quality in this study, which states: "[Software quality is] the degree to which the system satisfies the stated and implied needs of its various stakeholders, and thus provides value."This ISO model also covers some non-functional characteristics, mainly, "performance", "compatibility", "usability", "reliability", "security", "maintainability", and "portability." Do you agree with this definition?
Multiple choice (i.e., strongly disagree to strongly agree) Q6 Please, explain and comment on your response: Free text Table 10: Prescreening Survey Questions selected and implemented to counter them.All responses that failed our quality checks have been eliminated from the final dataset.
Data Collection.After the prescreening, we invited 416 potential participants.The survey was launched the 27th of May 2022 and ran until the 8th of June 2022.We paid 0.5 GBP for the prescreening and 6.5 GBP for the pilot and the main survey.We received 406 responses and after the quality checks, we ended up with N = 365 valid entries.The survey design is available in the shared material (Sect.4.3).Table 12 provides an overview of the characteristics of our sample.Table 9 shows descriptive statistics of our constructs.The standard deviation of psychological safety was 0.57, which is greater than the values of 0.31 [6] and of 0.48 [20] reported in prior survey studies of psychological safety in software development teams.This suggests that our phase II survey study was instrumental in broadening our empirical basis with greater variety in the values of psychological safety.Indeed, only 20 out of the 365 teams had the maximum psychological safety value of 5.0.
Data Analysis.After establishing the validity and reliability of our survey instrument, we tested our hypotheses by ordinary least squares (OLS) regression in SPSS v. 28.In contrast to the analysis of bi-variate correlations, OLS regression allows controlling for the effects of other variables when testing the effect of specific independent variables.This helps mitigate omitted variables bias (i.e., erroneously attributing an effect to one variable even though it is caused by another variable) [3].We standardized all non-binary variables (i.e., normalized them such that their standard deviation was 1) to ease interpretation.Our regression model included the control variables shown in Table 13 Potential Problem Mitigation Strategy Implementation

Bogus accounts & bots Prolific accounts control
Prolific uses various techniques to control accounts.This includes every account being verified using a non-VOIP phone number (one unique number per account), restricting signups based on IP and ISP (blocking low-trustworthy IP/ISPS), limiting the number of accounts that can use the same IP address and the machine to prevent duplicate accounts, limiting the number of unique IPs per "HIT" (study), and unique PayPal per account.

Liars (malingerers) & cheats
Prescreening, open-ended questions and re-asking same questions Q4 & Q6 questions of the prescreening have helped us to identify and eliminate liars.In addition, in the main survey, we used several open-ended questions to test the authenticity of the responses.We also re-asked prescreening questions at the end of the survey and matched the answers to test the integrity of the respondent.We asked the respondent's role at the start of the survey and re-asked the same question at the end.Dupuis et al. [16] explain that this technique helps identify random pattern responses and potential liars.

Slackers
Instructional manipulation check (IMC) [36] and re-asked one open-ended question We used two IMC questions and re-asked one open-ended question.The first IMC question was after the 19th survey question, we instructed the respondent: "Please, indicate your agreement with the following statement:" and the statement was "I'm passionate about my job.Please, answer "Strongly agree"." We used a matrix table with a five Likert scale range ("Strongly disagree" to "Strongly agree").The second IMC question was after the 32nd question.We asked: "This is a simple test, when asked about your favorite city you must select Casablanca.What is your favorite city?"We used a five multi-choice scale including Paris, Casablanca, Venice, New York and Sydney, in this order.At the start of the survey, we asked respondents about the scope of their current project and re-asked the same question at the end.to reduce unobserved variable bias.A hypothesis was supported whenever the significance level of a regression coefficient was below 0.05.We examined whether important assumptions behind OLS regression were met [44].The regression residuals followed a pattern of normal distribution, indicating that the assumption of normally distributed error terms was met.Variance inflation factors were far below 10 (highest value: 2.5), indicating that multicollinearity was not a concern.Regression plots did not indicate any non-linear relationships.

Replication Package 5
We made this study's data and other artifacts available here. 6

FINDINGS
Figure 1 summarizes the integrated findings from both phases of our study.Our analyses suggest that psychological safety is institutionalized and sustained by strategies owned by different roles in the organization.Openness and no blame are part of the DNA shaping psychological safety.For the latter to be institutionalized and sustained, these two basic qualities need to be adopted and exercised authentically across organizational levels.This happens when individuals adhere to openness and no blame, which helps signal a commitment to psychological safety at the team and organization levels.For psychological safety to transcend hierarchies and become a team behavior, leadership must take ownership of its values, exercise, and demonstrate them.Moreover, the practice of collective decision-making also helps establish and sustain psychological safety.
The findings of Phase I show that psychological safety emerges from three distinct but connected sources: Leadership, team, and individuals.While leadership, team behavior and their strategies to promote psychological safety are relevant, they remain dependent on individuals' commitment to openness, and no blaming to demonstrate that they are truthful, care, and they are trusting other team members.The individual strategies apply to teams and leadership alike; they constitute the cornerstone of a psychologically safe workplace.In this section, we present our findings by source (i.e., leadership, team, and individuals).For each source, we will discuss their distinct strategies, e.g., ownership for leadership and collective In-house vs. Outsourced This control variable captures whether the participant team carries out an in-house or outsourced development Multiple choice.Choices include, In-house and outsourced.

Team Size
The number of individuals in the participant team (logarithmized to reduce skew) Free text (only a number of up to three digits was allowed)

Age
The age of the participant Multiple choice.Choices include 21 -30 years, 30 -40 years, etc.

Gender
The gender of the participant Multiple choice.Choices include Male, Female, Non-binary, etc.

Experience
The experience of the participant in software development Multiple choice.Choices include 3 -5 years, 6 -8 years, etc.

Agile Experience
The experience of the participant in software development Multiple choice.Choices include Less than 3 years, 4 -5 years, etc.

Multi-functional team
The purpose of this control variable is to capture whether the participant team is multi-functional Likert scale (strongly disagree to strongly agree).

Enduring Teams
The purpose of this variable is to capture the time the participant team continued to work together Multiple choice.Choices include less than one year, 1 -2 years, etc.

Distributed Team
This variable captures the number of times per week the team of the participant is collocated (vs.distributed) Multiple choice.Choices include Always collocated, 3 -4 days per week collocated, etc.

Multiple Teams
The purpose of this control variable is to capture whether the participant project is carried out by multiple teams Yes and No multiple choice.

RQ: Strategies to promote and sustain psychological safety
Institutionalizing and sustaining psychological safety

Psychological Safety
Figure 1: Antecedents of psychological safety decision-making for teams, then common strategies shared by all levels, openness and no blame (individual strategies).
In phase II, we tested the propositions developed during Phase I by conducting a regression analysis of our survey data.Table 14 shows the regression results.Model 1 regresses psychological safety on control variables and on the predictors hypothesized in H1-H7.As the Adjusted R Squared value of .45shows, the model has high explanatory power.
Leadership strategy.In Phase I, we identified ownership as a leadership strategy to promote psychological safety.Ownership means that the leadership of the organization is resolute, withdrawing from liability, and owning the risks and consequences of their own actions; this can be demonstrated by simply saying, "I take ownership of this."Taking ownership brings psychological safety to bear.Still, saying that one values psychological safety is one thing and exercising it is another thing.Leadership integrity or "walk the talk" raises teams' confidence in their leadership's faithfulness to their own values of psychological safety.To test these findings, we proposed H1.We found a positive and significant relationship (beta = 0.14, p<0.05).Thus, H1 holds.While Phase II data analysis secures our confidence in this finding, Phase I data provide depth to understand the essence of this antecedent of psychological safety.Phase I participants unfolded the tale of this finding.They explained that psychological safety is "beyond labels."In essence, psychological safety remains words and promises and not a reality, only a pointer to it, until when leadership at all its levels moves beyond them.This happens by actively doing it while remaining authentic such that the team experiences psychological safety.P11 explained: "so we have internal see training on the company values ... to socialize these values ... well, it's nice to like to see that corporate, let's say management tries to embody those values, but they should try to, to give an example of what they would like to see happening.But it's more important that the managers practice it [psychological safety].Because if they could say like, here's the perfect company, look how cool we are.So it highly matters that managers and project owners also embody this kind of behavior." (P11, software engineer).
P6 further explained that when leaders live by the values of psychological safety, then its effects are felt profoundly on the team.He used the example of his team not being blamed for mistakes.He explained that when mistakes occur and the team is not blamed, then the team reciprocates with trust and respect and team members become invested in the project.He explained: "yeah.So instead of blaming, when he [senior manager] talks like that, or not, especially, we felt some sort of feeling that we are not guilty.Okay.I have done this.And this has been happening, this has changed a lot of things in the project.So when you have that feeling, we don't think about the time, we don't think about the hours we are working, we always try to deliver our best thing to him.So as a leader, not only in this field, as a leader, he, he should earn our respect, he should earn the trust from us." (P6, Snr.software engineer).

Ownership of psychological safety by the leadership
We learn from this finding that psychological safety is not merely a label in the organizational values list but fundamentally a matter of integrity.The leadership behaviors should be consistent and embody psychological safety values.leadership can act as role models and thereby impact the behavior of all team members.Leaders should translate psychological safety values into actions, i.e., no blame, accepting failures, and openness, which demonstrate safety authentically.Consequently, safety would materialize (i.e., "feeling safe") in the everyday life of the team.
Team strategies.Phase I data suggest that autonomous teams tend to be more psychologically safe.Other intra-team strategies also promote psychological safety, namely collective decision-making, slack time, and a safety net.The team's strategies may originate from within the team itself (collective decision-making), be negotiated with upper management (slack time and autonomy), or be intrinsic to the adoption of contemporary software engineering methods and procedures (continuous integration, testing automation, etc.).
Autonomy, as we inferred it from Phase I data, is having a degree of leeway for the team to be independent, with less or even the absence of interference from outside the team.P15 explained: " ... definitely we are, like, self-organized ... So yeah, people were not pinging you at every time that why you haven't done this.Why?Because you're responsible for yourself and for your work on it.Our management trust we know what we doing and we can meet their expectations" (P15, QA analyst).Autonomy is established with an informal contract with management and the team, with two sample clauses: trust and meeting expectations.While management is expected to trust the team's competencies and capabilities, the team, on the other hand, is "responsible" for meeting the "expectations." Autonomy is owned and sustained by the team, once the "freedom" is granted by management according to P10 account.He explained: "... we are a bit like free to do this together... we kind of agree on that ... with our managers ... we completely built this team together, and all the new members were hired, and no internal member, like to enter a member and the rest of the team was hired later.And we built our culture [psychologically safe] internally, like, we decided how to do things.Or, for example, no one told us to use this process or do like this, or we did whatever suits to our team, like we have different approaches, or etc.Our company was only interested in our output, not our how we work, they gave us total freedom ... and that's the culture should be built in the team" (P10, Snr.software engineer).When asked: "you took that self-governance opportunity and you created this culture of safety?", he replied: "yes, exactly."In this instance, psychological safety has emerged (i.e., "built" by the team) subsequent to having "freedom" to "decide how to do things." To test this finding, we proposed H2.We hypothesized a positive relationship between team autonomy and psychological safety.As the results show, the relationship was not significant (beta = 0.08, p>0.05); thus, H2 does not hold.As per P10 and P15 accounts, this team-level trait is negotiated and not always granted, or an inherent feature of psychological safety, which explains Phase II tests results.We can infer from these results that some agile teams, even though psychologically safe, they are not necessarily autonomous.Team autonomy is an antecedent of psychological safety when successfully negotiated by the team and its clauses (trust and meeting expectations) are established.
Collective decision-making, as we understood it from our data, occurs when the team makes decisions, which are not attributable to a single individual but to the entire group.This inherently inclusive process contributes to the feeling of safety.P4 explained that his team felt safe to challenge his design decision because it would not scale."... usually my suggestions are incorporated in some way, or they are modified and then incorporate it in some way.But in certain times, my suggestions ... might be totally rejected from the start ... my suggestions might be over, might be totally rejected from the start.And I'll share an example.So we basically had to implement a quiz interface in the application for the users to take assessments.And my initial proposed suggestion was that we use something like typeform ... So that was outright rejected [by my team].And it was not just rejected, because the team lead didn't feel like it, it was rejected on solid grounds that it wouldn't scale nicely on various devices and in various orientations of the devices ... and I actually, you know, the reason that they gave me was very solid.And because of that, I then suggested some other techniques.And we mutually agreed on using the horizontal stepper because that was something that didn't only satisfy the problem, but it also enhanced the issue, and we had a very beautiful UI eventually made that was fine.So yes, speaking up is very important, because the team is safe, then you can speak up", P4 said.This account shows that when P4 engaged his team in the process of decision-making, team members felt safe to contribute.Taking part in the decision process is an outcome of being psychologically safe, but also a practice to sustain this safety.P7 (a team lead) explained that irrespective of his leader status, decisions are made collectively: "people are first listen to we have certain conversations we point out the problem And the columns and also the constraints on the project.And based on that we agree on certain one certain outcome ... For example, we had a change for going from dotnet, three, one to dotnet, five, and then dotnet, six, and we had some risks there because we needed to update the code base on a lot of components.But the benefits were ability to host the project on Linux containers, and that also reduce the costs and improve the performance ... that is usually part of is done by consulting with key members.It's not done in isolation by me or because I say so" (P7, lead software engineer).
To test these findings, we proposed H3, which suggests a positive relationship between collective decision-making and psychological safety.We found a positive and significant relationship (beta = 0.21, p<0.01); i.e., H3 is, thus, supported.The significance of this finding is explained in P16 and P10 accounts."Since we are all a team, and the entire responsibility of the product comes down to us, we should take decisions in a joint meeting to actually still keep the quality high.The product working.",P16 said.P10 echoed the oneteam and shared responsibility values; he stated: "we have this rule, we shouldn't have different approaches for different things ... Either I should agree for your idea, or you should agree with my idea.We must be consistent.And always discuss in the team" (P10, Snr.software engineer).Collective decision-making fosters inclusiveness and shared responsibility; consequently, individuals become invested in their team.
Another potential antecedent of psychological safety that emerged from Phase I was slack time, defined as the extent to which participants can dedicate time to tasks outside the scope of the team core development activities of software development.Several informants mentioned that time pressures made it risky for them to dedicate time to interpersonal activities, such as discussing issues in the team, asking for help, and working out improvement plans with the team.For example, when asked whether it is difficult to ask other team members for help, P7 said "[t]he only problem is finding a time slot to discuss in-depth about problems sometimes" (P7, lead software engineer).P4 said the workplace became more psychologically safe after the hectic initial development phase was over and more time was available for: "I would say that now it is a lot more safe, and a lot more structured.In the beginning, since things are moving very fast, I would say that usually a lot of discussions, and a lot of frustrations were discussed related to deadlines or related to, you know, the quality of the work, because we didn't have enough time.But now I would say since the MVP is launched, and we are actually moving towards more of a stable product.So now things are relatively safe" (P4, senior software engineer).
H4 proposes that allowing agile teams to have Slack time is associated with higher psychological safety.Phase II results show that this hypothesis does not hold, i.e., beta = -0.01(.05), p>0.05.Similarly, to team autonomy, this hypothesized antecedent is negotiated by the team; P4 explained that his team engaged in a dialogue with senior management to establish trust and gain control of their work and processes."So now [after talking to management] things are relatively safe ... So I would say it's not really that much of a situation where a person cannot speak up he can, but it depends on how much time we have for the task and how things were rolling back in the day back in the past, but now as I said, it's a lot more structured and safe ... We now also feel safe because we have time to invest in developing ourselves and our technical knowledge and capabilities.We feel safe to schedule time for this", P4 stated.While Phase I data suggest that agile teams proactively negotiate to have slack time in their schedules, Phase II data show that is not always the case.
We understood from our Phase I data that a safety net is the adoption of software engineering practices to safeguard the development process against possible and unexpected problems or adversity.P10 and P17 explained allocating a "buffer" to do more testing or to mitigate the risk when the test coverage does not include all possible scenarios, "but from QA side, we made a decision to cover up all these things in forthcoming sprints.So the estimates were the proper the buffer so that we can test more than achieve better quality" (P17, Snr.QA engineer)."we have a good process to test or to make sure the core features or, etc, is very good.And we have that buffer", P10 said.
To test this finding, we proposed H5.Phase II tests show that the relationship between safety net and psychological safety was not significant, i.e., beta = -0.07(.04), p>0.05.Thus, H5 does not hold.Given this proposition is not supported broadly and taking into consideration the other antecedents, discussed thus far, we suggest that psychological safety is a human need promoted by strategies that exemplify basic human gestures toward each other.For example, while software engineering practices, such as CI/CD pipelines, help the team to mitigate and reduce potential errors, they do not seem to promote psychological safety as they do not pertain to social or human sources.
To recap, we identified two types of team strategies to promote psychological safety, negotiated by the team (i.e., team autonomy, and slack time) and emergent (i.e., collective decision-making), both socially inclined.While the latter emerges from within the team, autonomy, and slack time are negotiated by the team with senior management (external to the team).Although not supported by Phase II data, Phase I participants shared their experiences negotiating these antecedents and experiencing their effects, i.e., "feeling safe." We noted that safety net was not supported as an antecedent for psychological safety.We suggest that the reasons for the lack of support are that a safety net is more of a technical than a social construct.It is not a human gesture but rather a set of software engineering practices for process efficiency and mitigation of potential errors.Below, we sum up these findings.

Collective decision-making
Collective decision-making fosters a buy-in from team members that it is safe.This inclusive process signals psychological safety because it emphasizes collective accountability over individual accountability which carries the risk of committing oneself to a course of action and bearing the consequences alone.The inclusiveness does not only capitalize on the team's diverse perspectives but also conveys that every team member is a valuable asset.
Individual strategies.Psychological safety does not unfold only when the leadership and the team embrace its value; individuals at all levels (in the team and the leadership) must do their part to sustain it by exercising openness and accepting failures without blame.Phase I participants' accounts indicate that openness means the wiliness of team members to share information to ensure transparency and to feel heard.It also means accepting different perspectives, styles of work, criticism and feedback.Openness is collectively promoted and maintained by the team, but also an expectation from each member of the team, once it becomes a team value; P16 explained: "we actually empower the importance of the opened discussion" (P16, Snr.QA engineer)."If you fail to convince everyone and you realize that not exactly your way is better.Please be open-minded and consider also changing yourself.Right.That's the mentality I tried to solve.So yeah, we are open but in exchange, you have to be also open-minded", P3 (software tech lead) stated.
Phase I data shows that "no blame", when mistakes, or failures occur, is at the core of psychological safety.There is no other way to put it than P17's words: "so we don't blame we own the issue together as a team.How we handle this by having lessons learned retrospective meetings ...These are dedicated to what we have learned and how we can avoid it in the future." P15 explained that "no blame" does not equate to avoiding mistakes, to the contrary, they are welcomed, and blaming is not "acceptable"; he stated: "so pointing out mistakes is welcomed in my team and blame is not acceptable" (P15, QA analyst).These accounts are a testimony that psychological safety is nurtured by a constructive approach to problems and a shared sense of accountability."No blame" also appears in the leadership and team strategies in our findings.Equally, the team, leadership members, and team members do not blame.To test these findings, we proposed H6 (no blame), and H7 (openness).Both H6 (beta = 0.26 (.05), p<0.001) and H7 (beta = 0.15 (.06), p<0.01) hold.

Openness
Openness promotes psychological safety because individuals feel heard, accounted for, and valuable to the team.This is not a "one way" street, it is maintained by the team (e.g., "we" (P16, Snr QA engineer)), but is expected to be reciprocated by every team member.The mandate to open up transcends hierarchy and authority, or roles within the team.

No blame
No blame is the currency of psychological safety.The incarnation of this antecedent is underpinned by the belief that mistakes are inherent to the existence of the team and its members.Failures and mistakes are treated by the team as systemic occurrences rather than personnel errors.This antecedent promotes psychological safety because individuals do not fear repercussions.
The results in Table 14 show how psychological safety was associated not only with the hypothesized predictors but also with control variables.As the table shows, the following control variables were not significantly related to psychological safety: QA Role, Scrum, COTS, maintenance, outsourced, multi-team, country, age, gender, experience, agile experience, cross-functional team, and team size.Conversely, there was a positive relationship between years of working together and psychological safety, implying that teams that had been working together for a longer time reported higher psychological safety.Moreover, distributed teams reported, on average, higher psychological safety.
To recap, psychological safety materializes in agile teams when different actors weigh in their support, buy-in and embrace the core values of safety.The tale of our findings is that psychological safety flourishes when a leader takes ownership and follows through on its values.Not only that, but she also has to "walk the talk" to demonstrate integrity.Still, psychological safety does not end there; it's a continuous endeavor to sustain its underlying values by showing support, listening, and advocating for it in the various layers and hierarchies of the organization.Our findings also show that irrespective of the source of psychological safety, one common characteristic of the strategies used by these sources is that they are all social, i.e., pertaining to human behaviors and less to engineering practices.This asserts that psychological safety is a human need fulfilled by strategies and conducts exhibited in human and social behaviors.P9 sums up this conclusion, "we humans are social creatures, right?What we need is a feeling of comfort and safety at the end.So that is why this is like the most important thing for me" (P9, Snr software engineer).
While research in the social sciences has explored psychological safety in various contexts, few studies have examined how psychological safety materializes in ASD teams.Our qualitative data on ASD teams suggest various antecedents of psychological safety at the leadership, team, and individual level.Our quantitative data shows that, out of these antecedents, no blame and collective decision making practices relate most strongly to psychological safety.Openness and management ownership of psychological safety were also significantly related to psychological safety.Conversely, team autonomy, slack time, and safety net did not have significant relationships with psychological safety, even though qualitative data indicated their relevance.
In this section, we compare our findings to the social science literature on psychological safety, while reflecting on the unique aspects of ASD that may surface in our results.The fundamental weight-bearing mechanism of the agile approach does not reside in the prescribed ceremonies or the iterative development planning but in the team's ability to foster successful collaboration using a dialogic process, which involves attaining an in-depth awareness of each other's viewpoints and reaching a mutual understanding [26].If team members are subjected to censorship by either their peers or superiors, they may resort to self-preservation as the act of voicing their opinions becomes a perilous endeavor and their primary objective shifts to ensuring their own survival [19], then collaboration would break.
Findings reported in social sciences failed to acknowledge the significance of psychological safety as a means to leverage intellectual friction, or the presence of conflicting ideas, to effectively carry out interdependent tasks and collaborate successfully on ASD projects.It has demonstrated that the presence of PS in both dyadic relationships and teams can result in increased voice behavior (voicing ideas and concerns to team members) and reduced silence behavior [4,11,43].For example, Tynan's research found that individuals who feel safe in their interpersonal relationships are more inclined to express disagreement, provide honest feedback, and identify mistakes [43].Bienefeld et al. found that speaking up is crucial for the success of aircrew teams, given that these teams are temporary and rely heavily on exchanging critical information during their operations [4].While certain agile teams may have a limited duration, it is noteworthy that ASD projects are considerably longer than missions undertaken by aircrews.The results of our study underscore the significance of individual-level openness, specifically the inclination of team members to exchange information to promote transparency and a sense of being heard.This enduring quality has the ability to sustain psychological safety, regardless of the duration of the team's collaboration.Likewise, in the context of displaying transparency, we found that members of an agile team anticipate that they will not be subjected to blame, thereby constituting another characteristic that persists over time.
Detert and Burris examined PS within a restaurant chain [11].Their findings revealed a positive correlation between the managers' openness and transformational leadership with PS [11].Additionally, both of these factors were also significantly associated with the voice behavior of employees [11].The study highlights the significance of speaking up within the restaurant industry, with the aim of enhancing the transmission and reception of upward communication (communication from employees to managers) [11].In the context of ASD, information flows in multiple directions and is considerably more intricate than the exchange of information that occurs in restaurants.ASD projects entail a significant degree of collaboration and require a substantial amount of specialized knowledge.Therefore, our research findings indicate that openness is a quality at the individual level.Every team member is encouraged to exercise openness to promote safety and a fluid exchange of information across all levels.A comparable inference can be made for Tynan's study [43], as it concentrated solely on upward communication [43].Tynan conducted a study to investigate the factors that contribute to individuals' reluctance to express face-threatening information in organizational contexts.The study utilized a sample of both undergraduate and graduate students.PS has been found to be a valuable predictor and a potent mediator of the impacts of supervisor face giving and threat sensitivity on upward communication [43].Our findings emphasize openness because of the inherent collaborative aspect of agile and information flow in various directions in cross-functional teams.
Agile teams endeavor to achieve continuous improvement through regular feedback and reflection [2].PS fosters an atmosphere in which team members can offer and receive constructive feedback and learning [19].Although numerous social science studies indicate that PS fosters learning behaviors such as feedback seeking, experimentation, and discussion of errors [18,34], its significance in ASD has not been fully recognized.Agile software development involves intricate knowledge that is collaboratively exchanged among cross-functional teams and rapidly evolves.
Edmondson reported that the level of psychological safety within a team has an impact on its learning behavior, which subsequently influences the overall performance of the team [18].The study constitutes a singular case of a company engaged in the production of office furniture [18].The dissemination of knowledge within such a team is likely to be uncomplicated, given that the duties and procedures are frequently established and subject to minimal alteration over time.By contrast, the sharing of knowledge within ASD teams can present greater complexity, owing to the dynamic nature of the process, evolving requirements, and specialized nature of the information involved.While wikis and other similar tools are utilized for knowledge sharing, it is imperative for teams to engage in collaborative efforts to facilitate the comprehension of intricate information.
Likewise, within a team responsible for producing office furniture, feedback typically centers on the tangible qualities of the product and may be conveyed through either interpersonal communication or written notes.In agile team settings, team members may exhibit increased vulnerability when receiving feedback, such as during daily stand-up meetings, retrospectives, or issue tracker discussions.Our results indicate that fostering an environment of openness and collaborative decision-making is critical in such environments.When there is a climate of safety, the team's ability to perceive and comprehend the intentions of others is a crucial factor in determining its receptiveness to feedback.The team's inclination to perceive negative feedback as constructive rather than rejection is heightened by adopting a mindset that presumes others' intentions to be helpful rather than blaming.Furthermore, our research shows that collaborative decision-making holds significant importance for agile teams in establishing PS.The act of signalling an inclusive process and sharing decisions among team members fosters a sense of collective accountability as opposed to individual responsibility.
Carmeli investigated the behaviors related to learning from failure [7].The study's sample consisted of 33 organizations representing a range of industries, including the information systems [7].The findings indicate a positive correlation between learning behaviors based on failure and psychological safety.When individuals experience a sense of psychological safety that enables them to discuss their failures openly, they are better equipped to derive valuable insights from those experiences and subsequently enhance their performance [7].Nonetheless, the research lacks a comparative evaluation across various sectors in the sample.Our findings highlight pertinent nuances pertaining to ASD, specifically emphasizing the significance of avoiding blame in instances of errors.The practice of no blame provides team members with the assurance that they can openly communicate about errors without fear of retribution.
We identified nuances specific to agile software development.Negotiating team autonomy with management is essential for it to materialize and contribute to PS. Post studied research and development team [38].She explains that when individuals perceive that their cognitive styles (i.e., problem-solving approaches and analytical thinking) are compatible with their peers, they feel safe [38].On the contrary, our work did not identify the compatibility of cognitive styles as an important theme in ASD teams but rather emphasized individuals' openness and willingness to accept criticism and rejection.Prior research in the social sciences has also found that an individual's perceived status and professionally-derived status within the team [4,33] leads to outcomes such as willingness to speak up.We did not find perceived status as an important theme.Individuals have to pull their weight to contribute to PS by displaying openness and avoiding blame.Once these two strategies become norms, individuals have to adhere to and promote them to sustain PS and collective decision-making lessens professionally-derived status.Consequently, team members feel they are contributing equally.Our findings suggest that PS should no longer be viewed only as a team-level trait, but rather as a collaborative endeavor toward a common goal, i.e., a PS workplace.

LIMITATIONS & THREATS TO VALIDITY
In this section, we elaborate on potential limitations, assumptions, and threats to validity to our methodology and findings.Below, we highlight some limitations, assumptions, threats to validity, and how we mitigated their effects on our design and execution.
Participant Selection and Data Representation (Phase I & II):.One potential limitation of this study could be related to our participant selection and representation of data.We recruited interviewees through our known network and snowballing.Hence, the findings of Phase I could be skewed towards our conveniently selected sample.However, this limitation is inherent to the exploratory nature of Phase I. Our mixed methods design mitigated this limitation; in Phase II, we surveyed a large sample with different backgrounds (professional, experience and countries of origin, see Tbl. 2).
The use of an external market platform Prolific entails potential risks for the quality of the data of Phase II.However, we took extensive precautions to ensure recruiting suitable participants and high-quality responses.In addition to the quality control measures, we implemented to assure the quality of our survey data (see Sect. 4) during the execution of the survey, we manually checked every response before we approved the submission for payment in the Prolific platform.We relied on free text responses to assess the genuinity of the responses.
In addition, we decided to limit participation to the survey to certain regions (Native English-speaking country or countries where English is the second language, e.g., North America, Australia, India, Europe).This decision might have excluded viewpoints from other regions.However, our mixed methods design, again, compensate this limitation.Phase I sample has five participants outside English as a native language speaking countries, e.g., India and Poland.For example, we observed that Indian participants talked about psychological safety in an equal tone to their British counterparts.
Our Phase I sample gender is biased towards males, only one female (P18) was presented.The risk that psychological safety may be perceived and interpreted by genders in different ways has been mitigated by Phase II of the study, where we had more non-male participants (22% female and one non-binary) and controlled for gender.However, our study did not measure the distribution of gender within the team.Exploring the effects of gender distribution on psychological safety, therefore, remains future research.
Participant Bias (Phase I):.There could be limitations that participants have not remembered all the details (i.e., memory bias), or providing responses biased with social desirability (i.e., providing responses that researchers like to hear) [23].To minimize the effect of memory bias, throughout the interviews, we asked our participants to provide examples from their experiences in their teams.Examples do not only provide high-quality empirical evidence, but they are also sources of reliable accounts from practice.In addition, we emphasized to our participants that all the responses would be anonymized; this may reduce any risk of social desirability bias.
Like in any correlational research, a potential limitation of our Phase II survey lies in its ability to make causal inferences.Correlation does not imply causation because correlation may also result from the effects of unobserved variables, from self-selection, or from other sources of endogeneity [3].However, two aspects of our study mitigate this problem.First, we used an extensive array of control variables to reduce unobserved-variable bias.Second, the claims made in this study are based not only on correlations but also on the insights into causal mechanisms that we gained from our qualitative data, which, together with the quantitative data, provides a stronger basis for causal assertions [21].
Lastly, a potential limitation of our Phase II survey is that we found weak support for the convergent validity of the items measuring psychological safety, even though we used items established in prior research and even though these items met the requirements for discriminant validity and reliability.While we decided to treat psychological safety as a single construct to ensure consistency with prior research, future research could explore a potentially multidimensional structure of psychological safety, such as whether particular facets of psychological safety are particularly important for outcomes such as software quality.
Relationship between psychological safety levels: The synergies between the PS levels were not uncovered by our findings.The inability to propose a unified theory of PS antecedents is a direct result of this situation.The identification and conceptualization of psychological safety precursors into a cohesive paradigm, however, is a potential future work.In a future effort, psychological safety antecedents relations could be identified and conceptualized into a unified model.
PS in no-agile teams: Our research does not suggest that agile teams are the only ones who can benefit from PS.As a result of its widespread use in the software development business today, we have focused solely on ASD in our efforts.This means that our study can only apply to ASD teams, but it provides an avenue for future research to compare and contrast PS in agile and non-agile teams.
We also identified some threats to validity, which we highlight below: One potential internal validity issue is that our questionnaire assesses subjective constructs.Although we did our best to provide clear and thorough statements in the survey, there is still a possibility of respondents misinterpreting the questions.To reinforce the statistical conclusions, we developed the survey statement with the understanding that it must stay atomic, consisting of indivisible units.Our replication package contains anonymized quantitative data that can be examined.
Phase I data is skewed towards high PS.However, the fundamental character of mixed methods, in which the flaws of one phase are balanced by the strengths of the other, helps to alleviate this problem [10].Indeed, the phase II data has greater variance of psychological safety.
A potential external validity issue is that in mixed-methods research, a perfect agreement between qualitative and quantitative data is not always achievable, especially when the issue of interest is social and behavioral.Data gathered through various approaches is bound to differ.We consider that a perfect agreement between both methodologies is especially dubious, given that qualitative data is limited and participants were interviewed in a specific setting.The quantitative component of this study refines the qualitative conclusions.We observed that H2, H4, and H5 were not supported.
Our conclusions for H2, H4, and H5 remain confined to the qualitative data of Phase I. Evidence suggesting these results could be generalizable to other settings, periods, and people cannot be guaranteed.Instead, as researchers, we show how this may be relevant and in what context.

CONCLUSION
Since early work on PS and throughout the last decades, this teamlevel trait has shown to be a catalyst for many desired qualities.To capitalize on this social asset, organizations, their leadership, agile teams and their members have to adhere to and promote values propitious to the feeling of safety.Our study has highlighted several techniques such as ownership of psychological safety and collective decision making that are implemented at different levels of organization (leadership, team, individual) to foster psychological safety.Our study shows that the social context matters; the human needs in the software development environment should be attained to.Our analysis shows that psychological safety is a human need; once contented, agile teams respond with an array of behaviors conducive to improving teams' dynamics.We argue that future research could potentially investigate the effects and benefits of psychological safety on the dynamics of agile teams and their productivity to deliver software products.In this regard, we plan to extend the current work by investigating the effect of psychological safety on software quality.

Table 3 :
Examples of interview questions

Table 5 :
Example of Pattern Codes H1: The ownership of psychological safety by the leadership is positively associated with psychological safety in agile software development teams Team autonomy H2: Team autonomy is positively associated with psychological safety in agile software teams Collective decision-making H3: Collective decision-making in agile software teams is positively associated with psychological safety Slack time H4: Allowing slack time is positively associated with psychological safety Safety net H5: The adoption and consistent use of engineering practices is positively associated with psychological safety No blame H6: Not blaming for mistakes is positively associated with psychological safety in agile software teams Openness H7: Openness is positively associated with psychological safety in agile software teams

Table 6 :
Phase II Hypotheses • Step 3: Table 11summarizes potential quality issues and the mitigation strategies we

Table 7 :
Survey instrument for latent constructs

Table 8 :
Discriminant validity results.Diagonal shows square root of Average Variance Extracted (AVE), all other cells show correlations

Table 9 :
Descriptive statistics #Prescreening Question InstrumentQ1Are you currently working in an agile software development team?Multiple choice (Yes and No) Q2 What is your role in your software development team?Multiple choice (e.g., Software engineer, QA, Tech Lead, etc.) Q3 What agile method do you use in your team?Multiple choice (e.g., Scrum, XP, Kanban, etc.) Q4 Is this statement true or false: Agile is a family of software development methods, inspired by the "Agile Manifesto." Multiple choice (True and False)

Table 11 :
Data Quality Control Techniques

Table 12 :
The Characteristics of the Sample

Table 13 :
Control Variables ü Openness ü No blame ü Collective decision-making ü Ownership of psychological safety

Table 14 :
Regression Results