We’ve enjoyed publishing to Medium. But the experience of both writers and readers has declined substantially over the years due to a monetization push by Medium. We’re going back to a self-hosted Ghost blog. The upside is that Ghost is Fediverse-enabled, gives us full control of how the data is stored and ensures our content remains ours.

We’re leaving Medium was originally published in The Liberators on Medium, where people are continuing the conversation by highlighting and responding to this story.

Three preliminary findings from the ongoing research project by Dr. Karen Eilers and Christiaan Verwijs

What makes Agile Teams effective? Is it the presence of roles like Scrum Masters and Product Owners? Is it the use of concepts such as Product Backlogs or Sprints? Or it something deeper, less tangible?

In this post, we share preliminary findings from an ongoing research project into Agile Mindset by two members of the Columinity Science Team, Dr. Karen Eilers and Christiaan Verwijs. Our core findings are:

1. Agile Mindset is a useful concept at the team-level, and consists of shared beliefs about learning spirit, collaborative exchange, customer co-creation and empowered self-guidance.
2. Teams with an Agile Mindset seem to be more effective.
3. Cross-functionality, psychological safety and value focus contribute to Agile Mindset.
4. Management Support creates a foundation for Agile Mindset.

Below, we expand on how we arrived at these findings. You can also scan the Agile Mindset in your team right now to get a detailed evidence-based report for free now.

Agile, behaviors and attitudes

Agile is first and foremost the ability to learn and adapt quickly. This can be a response to changing market conditions, customer needs, emergencies or other needs. Within organizations, Agility can manifest at different levels. Teams are agile when they learn and adapt quickly about the work they need to do. In turn, organizations are agile when their structures, processes and culture allow them to learn and adapt quickly to their environment.

While agility may be encouraged through the introduction of roles, events and concepts, such structural changes alone rarely seem sufficient. Not surprisingly, many Agile transformations fail to achieve their aim (e. g. Dikert et al. 2016, Sutherland 2020; Digital.ai 2023).

Scientific studies have investigated why this is so. One study by Verwijs & Russo (2023) considered behavior typical to agility, and found that behaviors relating to stakeholder concern, responsiveness, continuous improvement and team autonomy explained up to 76% of the effectiveness of agile teams. This is now the “Agile Team Effectiveness” model in Columinity.

However, behavior does not occur in a vacuum. Psychologists like Ajzen and Fishbein (1980) have pointed out that behavior is shaped in a large part by personal beliefs or attitudes. In other words, it is not enough to tell teams it is important to collaborate with stakeholders — they have to believe it to be important.

An interesting perspective on this is offered by research into the Agile Mindset. Eilers, Peters, and Leimeister (2022) focused their research on demystifying the Agile Mindset. Based on previous literature and expert interviews, they identified four dimensions of the Agile Mindset to make this attitude more tangible for practice. The Agile Mindset, therefore, represents a positive attitude towards:

1. Learning Spirit,
2. Collaborative Exchange,
3. Customer Co-Creation, and
4. Empowered Self-guidance.

They developed a scale to measure the Agile Mindset at the individual level. Other researchers built on their work and found that the Agile Mindset predicts higher innovative work behavior and performance, as well as lower emotional exhaustion (Augner & Schermuly, 2025). Further studies have provided insights showing that creating suitable environments can help people develop an Agile Mindset based on their positive experiences when they act in accordance with this mindset. These environments include:

1. Knowledge impulses for continuous learning and openness,
2. Work design that supports, for example, reflection through retrospectives and enables people to choose their own way of achieving goals, and
3. Leadership that fosters collaboration, ownership, and learning.

Research Project: Agile Mindset at the team-level

Previous studies focused on Agile Mindset of individuals. Because most work in modern organizations happens in teams, we wanted to adapt it to the team-level. This recognizes that behavior in teams is shaped by the extent to which such beliefs are shared by members, and members are aware of this. This requires open and honest conversations in teams. Therefore, the aim of this research project is to empower teams to become more effective by continuously developing their Agile Mindset through meaningful conversations.

“The aim of this research project is to empower teams to become more effective by continuously developing their Agile Mindset through meaningful conversations.”

How we analyzed the results

We began our collaboration by developing a set of survey questions to measure Agile Mindset at the team-level. These questions were deployed through Columinity as part of the “Agile Mindset”-model.

The collected data was cleaned of low-quality responses, resulting in 133 respondents of 55 discrete teams. In this first validation, scales were evaluated with Confirmatory Factor Analysis (CFA), reliability analysis, Heterotrait-Monotrait analysis (HTMT) and content analysis. We used Structural Equation Modelling (SEM) in IBM AMOS to test the measurement model. Missing data was imputed and we controlled for social desirability bias in the answer patterns. Finally, a path model — an advanced form of multivariate regression analysis — was developed to test direct and indirect effects.

Does Team-Level Agile Mindset Consist of 4 Dimensions?

A first test was whether or not we could indeed find four distinct dimensions for Agile Mindset in the data. We started with data from 20 questions from 4 scales, one for each proposed dimension. After removing questions that overlapped too much between dimensions, we arrived at a set of 13 questions that resulted in four discrete, but correlated, dimensions. The resulting fit was good (CMIN=103.828, Df=59, CFI=.966, TLI=.955, RMSEA=.076). The modified scales also showed excellent measurement reliability, exceeding .80 (Cronbach’s Alpha).

In practice, this means Agile Mindset manifests in teams through four separate, but connected, factors.

Preliminary Finding #1: Teams with an Agile Mindset seem to be more effective

Our first hypothesis is that teams with an Agile Mindset are more effective than teams without. This appears to be the case. We analyzed responses from 133 teams (55 teams) and found that team effectiveness goes up by .69 points for each increase of 1 point for Agile Mindset (on a scale from 1 to 7). This effect was statistically significant.

This means that teams that value Customer Co-Creation, Collaborative Exchange, Self-guided learning and Empowered Self-guidance are generally more effective than teams that do not. They show higher performance, higher team morale and higher stakeholder satisfaction.

Preliminary Finding #2: Factors that contribute to Agile Mindset

What contributes to the formation of an Agile Mindset? Insights into such factors can help us better understand why some teams develop an Agile Mindset, and become more effective, while others don’t.

We hypothesized several factors. Of these, three showed a statistically significant direct effect on Agile Mindset. First, teams that are cross-functional show a higher Agile Mindset. For each increase of cross-functionality by 1 point (on a 7-point scale), Agile Mindset increased by .33 points. Second, teams that perform work where the value is clear to them showed a higher Agile Mindset. For each increase in value focus by 1 point (on a 7-point scale), Agile Mindset increased by .31 points. Finally, Agile Mindset is higher in teams where members can take interpersonal risks without repercussion (i.e. psychological safety). For each increase of psychological safety by 1 point (on a 7-point scale), Agile Mindset increased by .56 points.

Of the factors we hypothesized, the presence of shared goals, high autonomy (self-management) and the presence of clear learning opportunities did not statistically contribute to Agile Mindset with this sample.

Preliminary Finding #3: Management Support creates the foundation for Agile Mindset

What role can management play in the formation of an Agile Mindset? Although management support does not directly influence Agile Mindset in our sample, its effects are indirect.

In our results, we can see that management support positively influences cross-functionality, value focus and psychological safety, and thereby increase Agile Mindset indirectly. In this way, each increase of management support by 1 point (on a 7-point scale), contributes to an increase of .38 points in Agile Mindset. This clearly shows that management support helps establish the foundation for teams to thrive.

Limitations

Our research project is in the early stages. We are openly sharing our preliminary results here to show the value of such research. However, there are several limitations to take into account:

1. Our dataset is still modest in size with 133 participants. Small samples have more statistical noise, which makes it harder to detect effects.
2. Stakeholder satisfaction is important aspect of team effectiveness. We are currently relying on self-reported measures by teams, which may be biased. However, we are collecting feedback from stakeholders directly. This sample is still too small to meaningfully analyze though.
3. We are still learning how to best measure Agile Mindset on the team-level. The scales we developed will change as we learn how to more accurately measure it, which may change the results.

Next Steps

This post reflects the first step in a three-step validation process. We’ve used insights from this step to make changes to the survey. The next validation will be performed on a larger sample, hopefully 500+ participants. The final validation will be performed on the largest sample, hopefully 1.000+ participants and result in an academic paper that will be submitted for academic peer review.

Help Us Continue This Research

If you find research such as this valuable, please contribute to it yourself or encourage others to do so. The best way to contribute is to scan the Agile Mindset of teams in your organization through Columinity. You can participate with full anonymity. No account and no payment is needed. We use anonymized data for our scientific research.

Once we have more results, we will report back here with the findings.

Authors

Christiaan Verwijs, Organizational psychologist at the Lucid Institute of Organisational Research, and developer and co-founder of Columinity.

Dr. Karen Eilers, Business psychologist at BSP Business and Lawschool in Hamburg, with a Ph.D in Information Systems.

How A Team-Level Agile Mindset Shapes Team Effectiveness was originally published in The Liberators on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why is higher management increasingly reaching to AI-supported tools that analyze individual productivity?

I am deeply worried about the future of work. As the founders of Columinity, Barry Overeem and I frequently talk to people in leadership positions across large (European) enterprises about how they use data to support teams and their business.

A disturbing trend in the use of AI and productivity metrics

We’ve noticed a disturbing trend in recent months. More and more, higher management is pursuing tools that use Artificial Intelligence (AI) to analyze mostly individual-level productivity metrics (git pulls, code commits, code reviews, lines of code, work items completed, emails sent/answered, lead time, bug count, engagement in online meetings) over holistic value-oriented, team-based metrics.

I can understand this to some extent from a business perspective. The Return on Investment (ROI) of individual-level productivity metrics comes down to “pushing individuals to work harder and produce more”, which is an easier business case to make to management and their shareholders than the fluffier notion of investing in teams and individuals and hoping they’ll produce better outcomes. It is rational from a capitalist perspective.

A return of scientific management, with AI as its stopwatch?

It feels like we’re revisiting the concept of scientific management that was spearheaded by Frederick Taylor during the later parts of the industrial revolution. But instead of the productivity observers with stopwatches as a form of middle management, we now get AI pattern recognition to analyze individual productivity patterns. Just like scientific management, the various AI-based tools cleverly emphasize “workflow optimization” and “work efficiency” as their aim, and cleverly mask the elephant in the room: individuals will be singled out based on their productivity.

Haven’t we learned from everything that came after scientific management that such a cold, rational and mathematical approach only dehumanizes the workplace, destroys motivation, burns people out and harms teamwork? My field of study, organizational psychology, emerged in response to scientific management and put emphasis on human factors in the workplace. Through a myriad of empirical works, it showed how our social work context shapes high-quality outcomes through factors such as motivation, teamwork, leadership, engagement and autonomy. A relentless focus on individual productivity, now encouraged at scale by AI-assisted tooling, completely ignores this inherently human part of the workplace and undermines trust, teamwork and cohesion.

How to counter this?

Honestly, I don’t know. I don’t see a strong modern counterweight to this disturbing trend. Labor unions were able to mitigate some of the negative effects of scientific management when they emerged during the 18th century, and strong protection of employees and their privacy was enshrined in law in many countries — particularly in Europe. But the power of labor unions has diminished and the protections by laws are increasingly loosened under the lobbying of powerful companies and ever wealthier business owners.

All I can do is provide more ethnical alternatives on a smaller scale. Our company The Liberators has offered Liberating Structures and other forms of employee engagement strategies as better ways to improve the workplace. Columinity is built on the notion that being effective— happy employees, happy stakeholders — is more important than being productive — at any level of the organization. Columinity also begins any analysis at the team-level, and simply does not track individuals. But I admit that we’re also struggling to get higher management to see why this is so important compared to productivity-focused alternatives.

I have to admit, it is disheartening for Barry Overeem and me to see how fast this is changing and how easily scientific management is re-entering the workplace under a new, high-tech guise.

P.s. I wrote the above as a personal reflection on a number of recent experiences. This is not at all a scientific piece.

Are We Returning To Scientific Management, But With AI As Its Stopwatch? was originally published in The Liberators on Medium, where people are continuing the conversation by highlighting and responding to this story.

A scientific investigation of the experience of psychological safety, the factors contributing to it, and the consequences on members — for online and face-to-face interactions.

How psychologically safe is the Agile community for its members? What does it look like when psychological safety is low? And how do members react to it?

We—Christiaan Verwijs and Evelien Roos—set out to answer these questions with help from Professor Daniel Russo. This post reflects the results of this study and provides an in-depth, detailed overview of our results and their implications.

We are in the process of preparing this study for peer review in an academic journal. This typically takes 1 to 2 years.

TLDR: Summary of Key Results

• We define the Agile community as a global knowledge-sharing community with many smaller subcommunities. Research has shown that psychological safety is an essential predictor of members’ intent to continue contributing to virtual communities.
• For in-person interactions, most participants (N=160) experience a moderate to high level of psychological safety (3.9 on a scale from 1 to 5). For online interactions, most participants experience a low to moderate level of psychological safety (2.9).
• The behaviors that participants typically experience are the rejection of (new) ideas (37.1%), tribalism (24.5%), and not feeling heard (19.6%). 4.2% reported no experience with behavior that lowered their psychological safety. The most common strategy for dealing with this is for participants to stop contributing or withdraw from the community (55.2%). A tenth of participants reported lowered emotional well-being (9.8%). 11.2% of participants report no effect on them.
• We found no significant difference in reported psychological safety by gender. However, women report substantially more dismissal of their views and tend to withdraw more from further interactions. A significant difference was found when comparing between age groups. The youngest cohort (26–36) reported a high level of psychological safety, which then dips to the lowest level (36–45) and trends up from there to the highest level for the oldest cohort (66+). We also found significant differences between roles, with facilitators and trainers reporting the lowest level of psychological safety.
• Participants identified three primary factors contributing to lower psychological safety: poor debating skills (36.4%), dogmatism (30.8%), and self-promotion (16.1%).
• According to participants, the three primary strategies to improve psychological safety are more community engagement and leadership (21%), improving the quality of dialogue (19.6%), and personal coping strategies (10.5%).
• Future studies can replicate this study to analyze trends and compare psychological safety between different communities.
• We identified several limitations to our research, which primarily impact the degree to which the findings can be generalized to the global Agile community.
• Whether the level of psychological safety is too low or good enough is a normative one that is up to the community. However, research shows that the intention to share knowledge is lower when psychological safety is low. If we combine this with observed differences in gender, role, and age, knowledge sharing may be harmed, lowering the diversity of those contributing.

Psychological Safety in (online) communities

We define the Agile community as a global community of people interested in Agile and participating to share knowledge and learn from others. Interactions can occur face-to-face at conferences, workshops, and meetups or virtually, mediated through platforms such as LinkedIn, Medium, Zoom, Substack, Discord, etc. It is not a monolithic community and is instead composed of many smaller communities that are loosely connected. This aggregation of individuals, businesses, and subgroups around a shared interest is similar to how Porter & Donthu (2008) define virtual communities.

Several studies have explored the factors contributing to knowledge sharing in virtual communities. Zhang et al., 2010 identify psychological safety as a significant predictor of the intention to continue sharing knowledge. Amy Edmondson (1999) popularized psychological safety as “a shared belief held by members of a team that the team is safe for interpersonal risk-taking”, which draws on earlier work by Edgar Schein (Edmondson & Lei, 2014). It is important to emphasize that a climate of high psychological safety is not akin to a “conflict-free zone.” Edmondson and Schein emphasize the need for healthy and constructive conflict to facilitate shared learning, though not in a way that aims to ridicule, harm or otherwise single out individuals or reduce their social standing in a group.

This study aims to assess the level of psychological safety in the Agile community, both in online and in-person interactions. This distinction is important because we expect online settings to evoke different behaviors and responses. Nonverbal cues play an important role in creating and evaluating psychological safety (Kostovich, O’Rourke & Stephen, 2020; Hayashida et al., 2024; Nillson & Norström, 2024), and this is hard to replicate online. Furthermore, we want to learn what the experience of low psychological safety looks like in practice, what factors contribute to it, and how it can be improved.

Research design

To answer our research questions, we designed a multi-phasic study. The first phase aimed to assess the level of psychological safety, the factors that contributed to it, and its effect on participants. Because the study concerns the Agile community, we felt it was essential to involve that community in making sense of the results and testing the credibility of our findings. Thus, the second phase aimed to report the results and perform member checking to assess credibility and develop more insights.

Both phases featured online survey studies. Such studies have drawbacks, like selection bias, but they are also convenient for quickly building larger samples. We purposefully included quantitative questions—Likert scales—and qualitative questions—open essay questions—to get numeric data and actual experiences. The survey order was also randomized by area to counter order effects.

The survey studies for both phases were advertised through various social media platforms well-used in the Agile community, particularly LinkedIn, Discord, Slack, and podcasts. We also approached well-known members of the Agile community to help us spread the word and participated in several industry podcasts to raise awareness. The survey for the second phase presented the results objectively, identified three core findings per area, and asked participants to share their feedback (see Figure 2).

The quantitative data from the first and second phases were analyzed with SPSS. To analyze the essay questions, we used the Gioia approach (Gioia, Corley & Hamilton, 2012) to classify and code the behaviors into 1st order concepts rigorously, 2nd order themes, and aggregate dimensions. In other words, a grounded theory describes the experiences of, the factors that influence, and the effects of low(er) psychological safety. We then counted how often participants reported the various dimensions. Each participant could provide examples from one or more dimensions.

The essay questions from the second phase were categorized using ChatGPT. Large Language Models (LLM) such as ChatGPT are ideally suited for objectively analyzing and classifying textual data (Tai et al., 2023; Chew, 2024). Such an approach is less time-consuming than the Gioia approach. Moreover, the second phase aimed not to develop a grounded theory but to identify broad textual response themes.

Sample

For the first phase, we received 160 responses. After removing careless and fake responses, our sample contained 143 participants. The distribution in our sample (by gender, age group, content creatorship, role, and seniority) is shown in Figure 3:

Phase 2 Sample

For the second phase, a survey was distributed across the same channels as the first phase. We wanted to include both previous participants and people new to the research. We received 31 responses. One case was removed because most questions were left empty. See Figure 4 for sample composition.

Where do people interact with the Agile community?

This study investigates the level of psychological safety in the Agile community for online and face-to-face interactions. So, we asked participants to indicate how often and where they share something with the Agile community on social media (see Figure 5). LinkedIn is the most popular social medium in our sample, followed with some distance by forums and YouTube.

We also asked participants to indicate where and how often they meet members of the Agile community for face-to-face interactions (see Figure 6). This included both physical interactions and video face-to-face interactions. Workshops or training are the most popular, followed by in-person and online meetups.

We performed a power analysis with G*Power. Our sample size was large enough to detect actual differences, with a chance of 99.99% for differences between in-person and online interactions. For comparison between age groups, roles, and gender groups, our sample was large enough to detect actual differences with a chance of 99.85%.

Level of psychological safety in the Agile community

This brings us to the core questions of our study. Participants were asked to evaluate the level of psychological safety they experienced in the Agile community. We used a psychometric Likert scale (1–5) consisting of 4 modified items from Edmondson’s measure of psychological safety (1999). This scale included items such as “Members of the Agile community are open to different perspectives and opinions”, “I frequently observe or experience behavior that lowers psychological safety” and “Members of the Agile community foster an environment where is easy to ask for help”.

Each participant answered the scale twice: once for face-to-face interactions (e.g., meetups, conferences) and once for the online social medium they used most frequently (LinkedIn for most). The order was randomized between participants to counter order bias. The measurement reliability for this scale was high for face-to-face interactions (α = 0.84) and online interactions (α = .85).

Psychological safety was evaluated with a mean average of 3.88 for face-to-face interactions (N=141) and 2.91 for online interactions (N=143). The means and standard deviations are shown in Figure 7. The difference is significant (p < .001). This means that psychological safety is relatively high in face-to-face interactions and much lower for online interactions.

Phase 1: What behaviors lowered psychological safety, specifically?

The quantitative and numerical data in the previous section indicate patterns, but it does not tell us what kind of experiences people have with low psychological safety. So, we also asked participants for written examples of behaviors they experienced or observed that lowered psychological safety. This resulted in 14 pages of open text. We coded these responses into 1st order concepts, 2nd order themes, and aggregate dimensions. This resulted in the following dimensions (see also Figure 8):

• Rejection or dismissal (reported by 37.1% of participants): The dismissal of ideas, contributions, or suggestions by others. This includes ridicule, gatekeeping, patronizing, sexism, bullying and mobbing.
• Tribalism (reported by 24.5% of participants): This covers highly dogmatic interactions in which specific frameworks, approaches, or practices are bashed or discredited without evidence or clear argumentation.
• Not feeling heard (reported by 19.6% of participants): This factor reflects situations where participants don’t feel heard by others. For example, others do not try to understand (no questions, interrupting). It also includes marginalization when no room is made for discussion or debate.
• Not feeling respected (reported by 9.8% of participants): Interactions in which participants do not feel that others respect their view or person. This includes gossip, depersonalization, and other behaviors that show a lack of respect in the participants' eyes (e.g., not showing up to meetups when signed up, revisiting discussed topics, and focusing only on what is negative about a contribution).
• Harassment (reported by 7.7% of participants): This factor covers more overt behaviors that lower psychological safety. It includes personal attacks, sharing personal details to make the participant look bad, and sexual harassment.
• Other behavior (reported by 6.3% of participants): Not all the examples provided by participants fit neatly into one of the above categories. The remaining examples were grouped into an “Other” category.
• No experience (reported by 4.2%): Not all examples fit neatly into one of the categories, and this factor reflects that.
• Unethical behavior (reported by 2.1% of participants): This factor includes violations of ethical norms, violations of conference safety agreements, and when others take work done by a participant and pass it off as their own.

The most frequently experienced behavior is “Rejection or dismissal” (37.1%), followed by “Tribalism” (24.5%) and “Not feeling heard” (19.6%). 4.3% of participants did not observe or experience such behaviors at all.

Phase 1: How did those behaviors affect participants, specifically?

The prior section describes what behavior participants experienced or observed that lowered their psychological safety. We also wanted to learn how this affected participants personally. So, participants were asked to write down how it affected them with an essay question. We received 143 responses, totaling 12 pages of text. We coded these responses into 1st order concepts, 2nd order themes, and aggregate dimensions. This resulted in the following dimensions (see also Figure 9):

• Withdrawal or disengagement (reported by 55.2% of participants): This covers all behaviors that indicate withdrawal or disengagement, such as exiting the community, existing social media or lowering overall engagement with others in the community through filtering, speaking up less frequently and lower motivation to post.
• No effect (reported by 11.2%): Not all participants experienced the impact of lowered psychological safety. This category reflects those responses.
• Lower emotional well-being (reported by 9.8% of participants): This factor covers emotional responses to low psychological safety. It includes anger, sadness, and annoyance, as well as emotions associated with mental health (anxiety and loneliness).
• Restrict interactions (reported by 9.1% of participants): This factor addresses attempts by participants to filter out those who lower their psychological safety, e.g., by not responding to them anymore, by avoidance, and by restricting who can comment or follow them on social media.
• Other behavior (reported by 5.6% of participants): Not all examples fit neatly into one of the categories, and this factor reflects that.
• Create safety for others (reported by 4.2% of participants): This includes behaviors and strategies to increase psychological safety for others, such as calming the waters, seeking to include others, and talking about other topics.

55.2% of participants reported withdrawing from further interactions or the community. 11.2% reported no effect on them. 9.8% reported lower emotional well-being.

Phase 2: To what extent did participants recognize the results?

In the second phase, we evaluated the degree to which members of the Agile community recognized the results. This allows us to test credibility and develop further insights.

Thirty participants rated the match between their expectations and the reported psychological safety in online and face-to-face interactions. On a scale from 1 (“The results strongly differ from my expectations”) to 5 (“The results strongly match my expectations.”), The mean average was 4.17 (st. dev: .91), which indicates moderate to high recognition of the results.

Gender differences in psychological safety

We also compared various subgroups in our sample to determine differences in the experience of psychological safety. The first such comparison was by gender. Our sample consisted of 90 participants who identified as men, 43 as women, and 10 who identified otherwise or did not want to disclose this information. The group differences (mean averages) are shown in Figure 10.

Although men typically scored psychological safety higher than women and people who identified otherwise, gender differences were not statistically significant at p = .05.

We also analyzed differences in the qualitative experience of behaviors that participants personally encountered that lowered psychological safety (Figure 11). Women reported a substantially higher rate of “Rejection or dismissal” than men (resp. 53.5% and 32.3%). More minor differences were observed elsewhere, with women reporting more “Tribalism” (resp. 27.9% and 23.3%), and men reporting “Not feeling heard” more often (resp. 21.1% and 16.3%). 7% of women reported no experience with behavior that lowered psychological safety compared to 3.3% of men.

Finally, we also compared the effect of low psychological safety by gender. The differences are shown in Figure 12. The most substantial difference was observed for “Withdrawal or disengagement,” which was higher for women than for men (resp. 60.5% and 52.2%).

Phase 2: To what extent did participants recognize the results?

To evaluate our findings, we shared our results with 30 community members for validation, see Figure 13. On a scale from 1 (“The results strongly differ from my expectations.”) to 5 (“The results strongly match my expectations.”), the mean average varied between 3.93 and 3.67, indicating moderate recognition of the results.

We also asked participants to interpret the results for gender differences in overall psychological safety, factors contributing to low psychological safety, and effects on persons. The anonymized text responses were analyzed and classified by the LLM behind ChatGPT. It showed:

• 23–30% attributed the differences to broader societal gender biases and 17–10% to the dominance of men in the Agile community.
• 27% noted the universality of reactions to low psychological safety, regardless of gender. However, 20% also highlighted gender differences in responses.
• 13–10% of participants desired more contextual information or raised questions about the results and our interpretation. For example, one participant noted that they did not observe significant differences in the graphs.

Age differences in psychological safety

We also compared the experience of psychological safety in the Agile community by age group. Participants were categorized into 10-year buckets, starting with 26–35 as the first bucket participants. The group differences are shown in Figure 14.

Psychological safety is about the same across age groups for face-to-face interactions, and observed differences are not statistically significant at p = .05. However, the differences between age groups are statistically significant for online interactions (p < .001). Psychological safety starts at 3.31 for the youngest age group, then dips to the lowest level in the age group 36–45 (2.66, N=44) and trends up from there to 3.72 for the group of 66+ (N=5).

When we break down the actual behaviors experienced by age group, we observe that the youngest group (26–35) reports the highest level of “Rejection or dismissal” (50%) and “Not feeling respected” (21.4%). The age group of 36–45 reports the highest level of “Harassment” (6.8%) and “Not feeling heard” (27.3). The oldest age group (66+) reports the most “Tribalism” (42.9%). The results are shown in Figure 15.

Regarding the effects of low psychological safety, we also observe some differences between age groups (see Figure 16). Here, “Withdrawal or disengagement” is the most reported effect in the age group 36–45 (59.1%). Furthermore, this age group also reports the highest incidence of “Lower emotional well-being” (13.6%).

Phase 2: To what extent did participants recognize the results?

To evaluate our findings, we shared our results with 30 community members for validation, see Figure 17. On a scale from 1 (“The results strongly differ from my expectations.”) to 5 (“The results strongly match my expectations.”), the mean average varied between 3.07 and 3.80. The results for the level of psychological safety by age group were least expected, whereas age differences for the factors and effects were mainly expected.

We also asked participants to interpret the results for gender differences in overall psychological safety, factors contributing to low psychological safety, and effects on persons. The anonymized text responses were analyzed and classified with ChatGPT:

• 30% noted the universality of how people experience psychological safety, regardless of age. However, 13% also noted age differences in how people interpret and respond to situations.
• 10–22% noted curiosity about the categories of factors and effects and wanted to learn more about them.
• 22% identified a wording issue in one of the categories. “Withdrawal or disengagement” was erroneously listed as “Withdrawal or engagement,” which understandably resulted in questions about why such disparate behaviors ended together.

Role differences in psychological safety

Finally, we compared the psychological safety experienced by different roles. We distinguished between Scrum Masters (N=35), Agile Coaches (N=49), Trainers and facilitators (N=17), Consultants (N=21), and a group of other roles (N=18). The reported level of psychological safety is reported in Figure 18.

We observe some variation in reported psychological safety between roles for face-to-face interactions, although differences are not statistically significant at p = .05. The differences in online interactions are significant, however (p < .01). Trainers and facilitators report the lowest level of psychological safety (2.66) and the highest is reported by Scrum Masters (3.23).

When we analyze the psychological safety-reducing behaviors reported by the various respondents, we note that trainers and facilitators report the highest level of “Rejection or dismissal” (58.8), followed by Scrum Masters at some distance (42.9%). Agile coaches report the highest level of tribalism (34.7%). Scrum Masters are the only group where some members report no personal experience with behavior that reduces psychological safety (8.6%). See Figure 19 for a visualization.

Finally, we compared the effects of low psychological safety by role (see Figure 20). “Withdrawal or disengagement” is the most often reported effect by Agile Coaches (59.2%), Trainers and facilitators (58.8%), and Consultants (61.9%), and the lowest by Scrum Masters (42.9%). Scrum Masters, on the other hand, report “Lower emotional well-being” more often (20%) or report no effect at all (20%).

Phase 2: To what extent did participants recognize the results?

To evaluate our findings, we shared our results with 30 community members for validation, see Figure 21. On a scale from 1 (“The results strongly differ from my expectations.”) to 5 (“The results strongly match my expectations.”), the mean average varied between 3.33 and 3.60. This indicated that the results were mostly as expected, to varying degrees.

We also asked participants to interpret the results for gender differences in overall psychological safety, factors contributing to low psychological safety, and effects on persons. The anonymized text responses were analyzed and classified with ChatGPT

• 30% noted role-specific challenges. For example, some participants argued that Scrum Masters are expected to point out impediments but may also be seen as obstructive.
• 25% wondered if the psychological safety they experienced was related to role-specific experiences. Some roles may be more sensitive to psychological safety than others, and coaches may be more attuned to it than consultants.
• 20% reported curiosity or surprise with the differences between roles. For example, several participants wondered why trainers and facilitators report so much more rejection and dismissal.
• 50% reported confusion at the visualization we provided for the effects of psychological safety by role. We discovered that the image was indeed incorrectly replicated from a previous slide.

Factors that contribute to low psychological safety

In the previous section, we reported the level of psychological safety among practitioners in the Agile community, both in face-to-face and online interactions. We also asked participants to speculate on the causes of low psychological safety. 137 participants responded to the essay question, “In your experience, what behavior or factors decrease psychological safety in the Agile community?” This resulted in 11 pages of open-text responses.

We coded these responses into 1st order concepts, 2nd order themes, and aggregate dimensions. This resulted in the following dimensions emerged:

• Poor debating skills (reported by 36.4% of participants): The inability to articulate one’s views reasonably and logically in a discussion with others. This includes poor listening skills, not trying to understand other views, and using flawed arguments (e.g., arguments from authority, logical fallacies). It also includes aggressive language (bashing, ridiculing, personal attacks) to sidestep debating differing views.
• Dogmatism (reported by 30.8% of participants): This factor concerns rigidity in personal views and the resulting rejection of opposing views in discussions.
• Self-promotion (reported by 16.1% of participants): This factor covers all behavior that aims to promote or protect one’s services and commercial interests to the detriment of others. This includes polemics about frameworks and the creation of controversial content optimized for exposure (click hunting).
• Lack of diversity (reported by 4.2% of participants): The degree to which the setting in which interactions take place promotes diverse viewpoints or is very homogenous instead. This includes lack of minority views, lack of visibility of minority groups, lack of women, and behavior that inhibits diversity, such as racism and sexism.
• Community dynamics (reported by 2.1% of participants): The dynamics in a given Agile community and how they influence psychological safety. This includes whether or not people stand up for each other and the presence of work agreements, clear norms, and gossip.

Each participant could report one or more potential factors. Figure 22 summarizes the five core factors and their response percentages.

Strategies to improve psychological safety

Finally, we asked participants to suggest strategies or measures to improve psychological safety. 110 participants responded to the essay question, “What measures or strategies could improve psychological safety and encourage more respectful and constructive discussions within the Agile community?” This resulted in 10 pages of open-text responses.

We coded these responses into 1st order concepts, 2nd order themes, and aggregate dimensions. This resulted in the following dimensions emerged:

• Community engagement and leadership (reported by 21% of participants): The use of clear community agreements to set norms about what is acceptable and what is not. This factor also includes moderation (if possible) and standing up to norm violations together.
• Improve the quality of dialogue (reported by 19.6% of participants): This factor focused on educating people on debating skills and techniques, such as active listening, asking questions before sharing one’s view, using scientific evidence when available, and keeping discussions professional. Many participants also pointed at the Scrum Values or the values in the Agile manifesto as guideposts.
• Increase diversity in perspectives (reported by 7.7% of participants): Being more sensitive to diversity in designing meetups and interactions. This includes more diverse panels (with women, minorities, and outside views), explicit invites to people with other views, and being more empathic to different views.
• Personal coping strategies (reported by 10.5% of participants): This strategy covers personal actions to increase one’s sense of psychological safety. This includes unfollowing or blocking people who lower one's psychological safety, leaving social media altogether, prioritizing in-person interactions, and building resilience.

Each participant could report one or more potential factors. Figure 23 summarizes the five core factors and their response percentages.

The usefulness of Phase 2 for participants

Our study consisted of one phase, where we collected data about psychological safety from the Agile community. The second phase was when we shared the results with community members to get their thoughts. Because such a two-step approach is rarely practiced, we wanted to learn how useful this was to participants. This was assessed with a 5-point Likert item (“To our knowledge, this is the first time the community actively contributes to the sense-making of scientific evidence. Did you find this process interesting?”). Figure 24 shows that the mean average varied between 4.13 and 4.38, reflecting answers between “Very interesting” and “Extremely interesting”.

We also asked participants to elaborate on their scores with an open-text question. The responses were analyzed with ChatGPT, which resulted in six categories. 23% made suggestions for improvements in future studies. 20% expressed interest and engagement. 17% found the experience useful for self-reflection. 17% raised questions about certain study aspects or criticized some classifications. 15% expressed appreciation of the second phase, and 8% wished to know more about the data and the context.

Follow-up research questions generated by participants

Finally, participants were asked to suggest future research topics based on these results that were of interest to them. The responses were categorized with ChatGPT into six themes:

• 23% of participants wondered how these results applied and compared to other contexts beyond Agile.
• 20% of participants desired more practical and improvement-focused research. Which evidence-based approaches improve psychological safety, particularly in online settings?
• 17% of participants expressed interest in learning more about which factors shape psychological safety online and in face-to-face interactions.
• 15% of participants desired to explore differences and similarities between psychological safety in communities and teams.
• 15% of participants wanted to explore the distributions of scores more specifically or raised specific questions about this study.
• 10% of participants suggested more methodological approaches or asked for clarifications.

Discussion

We now turn to a discussion of the findings as reported above. The results clearly show that psychological safety is substantially lower for social media interactions than for face-to-face interactions in the Agile community. This is not surprising, as nonverbal cues play an important role in creating and evaluating psychological safety (Kostovich, O’Rourke & Stephen, 2020; Hayashida et al., 2024; Nillson & Norström, 2024), which are hard to replicate on social media.

The types of behavior that participants primarily associated with lowered psychological safety were rejection or dismissal of their views, no effort from others to understand their opinions, and tribalism. Most participants reported that they withdrew or disengaged from further interactions, or even the community altogether, as a consequence.

This brings to a question underlying this research. What level of psychological safety can be expected in online interactions compared to face-to-face interactions? The mean average for online interactions is 2.91 on a scale from 1 to 5, just below the halfway point. Let's consider the questions that were asked (i.e., “members make an effort to understand each others’ views” and “members of the Agile community foster an environment where it is easy to ask for help”). Most people don’t observe behaviors consistent with psychological safety in their interactions on social media such as LinkedIn, forums, and YouTube. Our qualitative analyses underscore that this manifests primarily in the rejection of (new) ideas, not feeling heard, and tribalism. Whether this is acceptable is not a scientific question but one the community must answer for itself. What is clear from the results is that the reported level of psychological safety causes more than half of the participants to withdraw or disengage from interactions or the community in general and that emotional well-being is lowered for a tenth of the participants. This undermines the ability of a community to facilitate knowledge sharing, as Zhang et al. (2010) also reported as a consequence of low psychological safety in online communities. A minority report no experience with low safety (4.2%) or no effect on them because of it (11.2%).

This study also investigated how psychological safety is impacted by diversity in gender, age, and role. We found no significant difference in gender in reported psychological safety. However, women reported substantially more rejection and dismissal (53.5%) than men (32.2%) and indicated withdrawal from community interactions more often than men (60.5% vs 52.2%). For age groups, our data suggests that psychological safety starts high in the youngest cohort (26–35), then dips sharply (35–46) and recovers over time. Our data does not explain why this happens. It might be an example of the “honeymoon-hangover” effect (Boswell, Boudreau & Tichy, 2005) where the initial enthusiasm for a new job dissipates as reality does not always match expectations.

Regarding role diversity, trainers and facilitators reported the lowest level of psychological safety, whereas Scrum Masters reported the highest. Surprisingly, Scrum Masters are less likely to withdraw or disengage due to lower psychological safety than the other roles. While our data does not tell us what causes these differences, it is clear that psychological safety is experienced differently by different groups within the Agile community and has different effects. However, our results also show that those who experience low psychological safety are also most likely to withdraw from (further) engagements or leave the community entirely. In the long run, this may harm the diversity of opinions and impact the learning ability of a community (Zhang et al., 2010).

Our study presents one point in time. It is unclear how psychological safety has evolved from the origin of the community in the 1990s and will evolve from here on. With the proliferation of Agile in the early 2000s, many have flocked to the Agile community in search of shared learning, curiosity, and business interests. It would be interesting to track psychological safety as it changes over time and responds to changes in the profession. There are signs that the adoption of Agile in businesses is in decline (Lin, 2023) and market saturation of Agile and its methodologies. Such changes will impact the Agile community in different ways. It may increase competition between members and encourage more self-promotion to remain visible. Self-promotion was one of the primary factors that participants identified as lowering psychological safety.

Finally, this study used a two-phase approach to collect data on the Agile community in the first phase and then involve members of that community in disseminating that data in the second phase. This allowed us to assess the credibility of the research and develop more insights. Participants evaluated this process of shared sense-making between “Very interesting” and “Extremely interesting.” As researchers, we also found this process useful. Participants discovered some errors in the visualizations, helped generate more insights, made suggestions for improvements, and generated helpful follow-up questions for future research. This type of member checking proved a valuable way to ground research in the practical experience of professionals.

Practical recommendations

We now turn to practical recommendations based on this study. The first recommendation is to raise awareness of psychological safety and why it is essential for shared learning. A good start is the work by Edmondson (1999), although it is focused on work groups rather than communities. The current study shows that low psychological safety makes people withdraw from further engagements, may harm their mental well-being, and cause tribalism. It is also true that a portion of participants are either unaffected by low psychological safety or don’t experience it as such. However, this is a minority in this study.

A second recommendation is to invest in two factors suggested by participants of this study. First, the quality of dialogue can be improved by a commitment to keeping interactions professional and on-topic, asking questions before questioning views, using scientific evidence to support arguments, and practicing Agile values. Second, community engagement and leadership, as practiced through creating work agreements, applying moderation where possible, and standing up to behavior that lowers psychological safety together, are important.

Finally, psychological safety is higher in face-to-face interactions. Content creators and contributors do well in keeping this in mind. While it is easy to post a comment on LinkedIn or reply to a thread on a forum, a face-to-face interaction — in person or virtually — may make such interactions much more pleasant and fulfilling. Our study also suggests that if shared learning is the aim of a contributor, social media does not seem to be as suitable as low(er) psychological safety, which may diminish weaker voices.

Limitations

In this section, we discuss the limitations of this study. First, we do not know to what extent our sample of 143 respondents reflects the total population. For example, 30.1% of our sample consists of women. It is unclear how accurately this reflects the true percentage of women in the Agile community. The same uncertainty exists for the other properties in our sample: role and age. We addressed this limitation by using many different venues to reach potential participants. This includes several Agile conferences, posts by well-known thought leaders in the Agile community, blog posts on several well-known Agile blogs, and two industry podcasts.

Second, survey studies such as this are susceptible to self-selection bias. This causes the participants in the sample to be (more or less) different from people in the total population. This reduces the generalizability and the validity of the findings. In our study, we cannot conclusively rule out that the people who participated have experienced more examples of lowered psychological safety and were thus more likely to participate. While 4.2% of participants in our sample reported no experience with behaviors that lowered psychological safety, we do not know how accurately this reflects the number of people in the Agile community without such experiences.

Third, we defined “Agile community” as “the global group of people interested in Agile and discussing it, online or in-person.” This group with open, permeable boundaries consists of many smaller, more-or-less connected communities, but at least on a shared topic of interest. Our sample primarily consisted of people who contribute to the Agile community via LinkedIn, followed by some distance through forums and workshops, meetups, and conferences for face-to-face interactions. Because we do not know the true size of the Agile community — every place where people meet to discuss Agile — nor all the communities that make it up, we do not know if this sample is a good reflection of where most people with an active interest in the discussion of Agile can be found.

Conclusion

We defined the Agile community as a global knowledge-sharing community consisting of many smaller subcommunities. Research has shown that psychological safety is an important predictor of members' intent to continue contributing to virtual communities.

Most participants experience a moderate to high level of psychological safety for in-person interactions. For online interactions, most participants experience a moderate to low level of psychological safety. The behaviors that participants typically experience are the rejection of (new) ideas, tribalism, and not feeling heard. A small group reports no experience with behavior that lowered psychological safety for them. The most common strategy for dealing with this is for participants to stop contributing or withdraw from the community. A tenth of participants reported lowered emotional well-being. A similar-sized group reports no effect on them.

We found no significant difference in reported psychological safety by gender. However, women report substantially more dismissal of their views and tend to withdraw more from further interactions. A significant difference was found when comparing age groups, where the lowest results are reported by the age group 36–46. We found substantial differences between roles, with facilitators and trainers reporting the lowest level of psychological safety.

Participants identified three primary factors contributing to lower psychological safety: poor debating skills, dogmatism, and self-promotion. According to participants, the three primary strategies to improve psychological safety are community engagement and leadership, dialogue quality, and personal coping strategies.

Future studies can replicate this study to analyze trends and compare psychological safety between different communities. We identified several limitations to our research, which primarily impact the degree to which the findings can be generalized to the Agile community.

Whether the level of psychological safety is too low or good enough is a normative one that is up to the community. However, research shows that the intention to share knowledge is lower when psychological safety is low. If we combine this with observed differences in gender, role, and age, knowledge sharing may be harmed, lowering the diversity of those contributing.

Performing this two-phase study, analyzing the data, and writing this report took 143 hours or 17.8 full work days. While that is a lot of time, it aligns with our mission to bring more evidence-based discussions to our professional community. If you believe research like this is important, please contribute to our Patreon at https://www.patreon.com/liberators.

We are in the process of preparing this study for peer review in an academic journal. This typically takes between 1 and 2 years. The anonymized data will be published alongside the academic publication.

References

Boswell, W. R., Boudreau, J. W., & Tichy, J. (2005). The relationship between employee job change and job satisfaction: the honeymoon-hangover effect. Journal of applied psychology, 90(5), 882.

Chew, R., Bollenbacher, J., Wenger, M., Speer, J., & Kim, A. (2023). LLM-assisted content analysis: Using large language models to support deductive coding. arXiv preprint arXiv:2306.14924.

Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative science quarterly, 44(2), 350–383.

Edmondson, A. C., & Lei, Z. (2014). Psychological safety: The history, renaissance, and future of an interpersonal construct. Annu. Rev. Organ. Psychol. Organ. Behav., 1(1), 23–43.

Hayashida, T., Nakamura, Y., Choi, H., & Arakawa, Y. (2024, March). Privacy-aware Quantitative Measurement of Psychological State in Meetings based on Non-verbal Cues. In 2024 IEEE International Conference on Pervasive Computing and Communications Workshops and other Affiliated Events (PerCom Workshops) (pp. 433–436). IEEE.

Kostovich, C. T., O’Rourke, J., & Stephen, L. A. (2020). Establishing psychological safety in simulation: faculty perceptions. Nurse education today, 91, 104468.

Lin, B. (2023). Capital One job cuts signal trouble for IT labor market. The Wall Street Journal. https://www.wsj.com/articles/capital-one-job-cuts-signal-trouble-for-it-labor-market-11674251823

Nilsson, L., & Norström, W. (2024). Understanding Psychological Safety in Hybrid Work Teams: Experiences of Barriers and Facilitators.

Tai, R. H., Bentley, L. R., Xia, X., Sitt, J. M., Fankhauser, S. C., Chicas-Mosier, A. M., & Monteith, B. M. (2023). Use of large language models to aid analysis of textual data. bioRxiv.

Zhang, Y., Fang, Y., Wei, K. K., & Chen, H. (2010). Exploring the role of psychological safety in promoting the intention to continue sharing knowledge in virtual communities. International Journal of Information Management, 30(5), 425–436.

Psychological Safety In The Agile Community was originally published in The Liberators on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post is an opinion piece. While I discuss some scientific studies, the core argument is an opinion—and opinions change. I’m sharing this post because it's useful to challenge myself and others in certain beliefs. This is why the title contains a question mark.

Have we become arrogant as Agilists? I used to believe simplicity is always better than complex solutions. So, like many others, I dislike(d) SAFe for its complexity. I used to believe frameworks were a good way to initiate and guide change, so I favored applying something known (LeSS, FAST, etc) instead of rolling your own. I don’t think I’m at all alone in this, as I see these beliefs reflected in most of the discourse around Agile. But the more I learn about teams, people, and their organizations, the more I’m inclined to see these as fairly naive beliefs that riskily verge on arrogance.

An Example of Agile Arrogance

As I’ve written before, I’m skeptical of frameworks as a way to introduce, teach, and guide change. One big issue I have with them is that they implicitly, and sometimes explicitly, say: “Stop what you’re doing right now and implement this instead. Things will get better if you do”. If I look at the discourse around Agile, this is what most of us seem to believe when we walk into organizations and tell them what roles, events, artifacts, and procedures to implement because the framework tells us to. It's what we often signal in training, workshops, and coaching. Unfortunately, we often extend this with “And you’re lazy if you don’t.” This type of thinking was recently captured well in a well-meaning comment someone made about SAFe (I have the utmost respect for the author, and I wanted to pick an example that wasn’t over-the-top as some of them are):

“If you were given the choice of an expensive pill to lose weight or an annual gym membership, many people would take the pill […] Sometimes people don’t really want to lose weight. They just want to try this fancy pill.”.

The author was talking about the Scale Agile Framework (SAFe). The problem with this argument is that it only works if you assume that the pill doesn’t work. If the pill does work, even partially, a person who is low on cash and short of time would be pretty clever to go for the pill and not the expensive, time-consuming gym membership. Moreover, there is a clear judgment in this line of reasoning about people who don’t go for the annual gym membership. While this example is one of the more modest and well-meaning ones, there are plenty of examples in the online Agile discourse with much more colorful language and much stronger judgments (“SAFe isn’t Agile!”). All of this feels quite arrogant to me.

The general dislike of complex Agile frameworks, like SAFe and Disciplined Agile Delivery (DAD), is a great microcosm for this mindset. This dislike only makes sense if we assume that simple frameworks always trump complex ones or even that complex frameworks never work. A simpler framework like Large Scale Scrum (LeSS) or vanilla Scrum is preferred over the complexity of SAFe with all its layers, roles, and hierarchy. But what evidence do we have that simpler frameworks are better than more complex ones? How do we know with certainty that SAFe is nothing more than an Agile placebo?

Data might help. First of all, customers prefer SAFe over its simpler alternatives. In the most recent State of Agile, SAFe held a 53% majority market share, followed by 28% for Scrum@Scale, 6% for LeSS, and 3% for Nexus. While SAFe may be the VHS to the Betamax offered by other approaches, VHS gained market dominance because it was cheaper and more convenient. Second, a peer-reviewed study I published recently with Daniel Russo, Ph.D. analyzed data from 4.013 Agile teams. Our analyses did not yield meaningful differences between scaling frameworks on core indicators of team effectiveness nor in terms of stakeholder satisfaction with quality, responsiveness, or release frequency. Third, the academic studies that have compared scaling frameworks conclude that no framework is best in all situations (Almeide & Espinheira, 2021, Edison, Wang & Conboy, 2022). Instead, the authors recommend that organizations pick a framework that suits their needs. This reflects the notion of goodness-of-fit.

Goodness of Fit

The notion of goodness-of-fit leads to a more nuanced conversation because it considers the size of the gap between the desired state and the organization's current state. It isn’t based on the maxim that simple is always better regardless of the gap size. Instead, what will work best fits best with what is already there.

An organization that looks at the SAFe framework may recognize more of itself and its internal processes than in something much simpler, like LeSS, FAST, or vanilla Scrum. So, the gap is much smaller. For a complex organization with complex needs—like governance, legal requirements, and regulations—a more minimalist framework like LeSS or Scrum may be assumed to lead to chaos and, thus, a huge financial risk. From that perspective, isn’t it rational to go for the less risky approach that SAFe offers?

“An organization that looks at the SAFe framework may recognize much more of itself and its internal processes in it than something much simpler, like LeSS or vanilla Scrum.”

Many Agilists cynically conclude that SAFe’s popularity is entirely due to its sales and marketing. This is only true when we assume SAFe doesn’t work at all. But the scientific evidence we have for this doesn’t seem to support such a strong claim. Could those organizations that pick SAFe see or understand something that we don’t yet see or understand? Yes, it is easier to make blanket statements like “SAFe isn’t Agile”, but perhaps the truth is more nuanced and there is something valuable to learn.

A metaphor might help. Imagine a fitness coach who believes 20,000 steps a day is the only way to live healthily. While that may be fine for an already reasonably fit person, it won’t work for a 70-year-old with bad knees. A fitness regimen needs to account for the person's current situation if it wants to be effective. If an unfit 70-year-old with bad knees must walk 20,000 steps a day, they will give up because the gap is too great. All those Agilists who boldly state that “SAFe isn’t Agile” or even “Waterfall is horrible” are acting like this fitness coach. They ignore goodness-of-fit entirely.

So what determines goodness-of-fit? Honestly, I don’t have a clear picture of this, but the following factors seem important to me:

• The size of the organization. Smaller organizations may be more easily adaptable to organize work along a simpler framework, like LeSS or Scrum.
• Existing belief systems about leadership and management. Leaders in some organizations already intuitively grasp democratic leadership and how to let teams take control and resolve problems. However, in some organizations, teams and management aren’t used to this yet.
• Existing belief systems about Agility. For me, Agile is about reducing the risks of complex work by collaborating closely with stakeholders and by releasing them frequently. While this paradigm is crystal clear to me, it often isn’t in organizations.
• Existing governance and budgeting structures. How money is allocated and monitoring how it is spent varies wildly. Some organizations are used to annual budgeting cycles at the team level. Others are much more flexible in allocating money to where it is needed.
• Domain. A company operating in a fast-moving market that relies heavily on technology and software has different needs than a financial institution responsible for ensuring that money is always available to its customers.

Considering such factors, I believe there are many cases where a complex framework like SAFe or Disciplined Agile Delivery is probably a better fit than simpler alternatives. A simple framework like Scrum (with Scrum of Scrums), Nexus, or LeSS may offer a better fit for other organizations. If you’re reading this and noticing a judgment like “Well, those organizations that use SAFe are just lazy for not aiming higher”, think of yourself as saying to a 70-year-old with bad knees that they’re just lazy for not walking 20,000 steps a day. Maybe a regimen of 2000 steps a day already makes this person healthier, and they may eventually be ready for more.

Down The Rabbithole

This line of thinking can also be extended into frameworks. I won’t develop this fully here, but I’ll offer a summary for your consideration. What if we also use a goodness-of-fit approach for something like the Scrum framework? Instead of doing it all at once, which may be a huge culture shock, why not begin with what already fits a little and expand from there? If you start requiring “Sprint Goals” in organizations not used to working with team-level goals, it will create resistance because it doesn’t fit. Here, too, I believe we often arrogantly create our own resistance (and then blame teams and their organizations for not going all the way).

Closing Words

I believe a certain arrogance permeates much of the online Agile discourse. I believe it stands in the way of its own mission. We are not ”uncovering better ways of [working] by doing it and helping others do it” by diminishing SAFe or particular approaches. Yes, it is fine to have an aesthetic preference for simpler frameworks (I certainly do). Still, until there is strong and unequivocal evidence that “simple frameworks always trump complex ones”, it remains nothing more than a belief.

In the meantime, I believe we can learn much from how the Scaled Agile Framework (SAFe) is much more successful at reaching organizations at their level. While it may be much sexier to think of ourselves as fitness coaches who spur our clients on to take 20,000 steps per day, perhaps we should accept that most organizations are still like 70-year-olds with bad knees who are already making progress if they’re at 2000 steps a day. Let's aim for goodness-of-fit and embrace more nuance. Our profession will be better for it.

Are Agilists Arrogant? On Frameworks And Goodness-Of-Fit was originally published in The Liberators on Medium, where people are continuing the conversation by highlighting and responding to this story.

Do you remember the best team you’ve been part of? What about that team made it the best team for you? Chances are, your list will include things like “There was a sense of pride in what we did,” “We really felt like a team,” and “We had each other’s back.” Those are certainly things I would say about the best team I’ve ever been part of. As psychologists, such statements are examples of social identification, one of the defining characteristics of high-quality teamwork.

In this post, I want to dig deeper into social cohesion. The background for this post is that Barry Overeem and I are on a mission to unleash teams through an evidence-based approach. So, I will first begin with a brief overview of the scientific consensus around this phenomenon. Then, I will dive into all the practical things you can do with your team to boost social cohesion. We hope it will create experiences similar to those we had with the best teams we’ve been part of.

Note: This post is agnostic to your team's type. It applies equally to Agile teams, non-Agile teams, and other workgroups. You can also self-diagnose your team's teamwork quality with our new tool (free for individual teams) and use our feedback to improve.

Overview of scientific research on social cohesion

Group cohesion is a key variable of effective work teams (Hackman, 1987, Carless & De Paola, 2000). It is often conceptualized as consisting of social cohesion, task cohesion, and individual attraction to the group (Carless & De Paola, 2000). We generally speak of teamwork when all three of these are clearly present. Otherwise, it is just a group of people occupying the same (virtual) space.

Social cohesion and individual attraction to the group are conceptually quite similar (Carless & De Paola, 2000). They reflect the social realities of a team. Do they identify with each other? Do they identify as members of that team? Do they like being part of the team? More simply put, it reflects to which extent the team fulfills people's social needs, such as being recognized by others and being part of something greater.

Task cohesion, on the other hand, is present when members acknowledge that the work they do is highly related (Carless & De Paola, 2000). This reflects the more informational, functional realities of teamwork. Do members rely on members to complete their own work? Do they need to collaborate on tasks because they can’t do them alone? Do they seek and offer task-related help to each other?

Most people intuitively pick task cohesion as the most important one for teamwork. It is indeed most closely linked to actual team performance (Mullen & Copper, 1994; Zaccaro, 1991). However, task cohesion probably follows social cohesion and individual attraction to the group (Zaccaro & Lowe, 1988). This suggests that if the members of a group achieve social cohesion, task cohesion is likely to follow.

Although this is only a cursory overview of the concept of social cohesion, I hope it shows how important the social realities of teams and teamwork are. One reason many teams struggle with teamwork is that there is no social tissue between the members. As psychologists, we know how vital this is and why it is worth the time and effort to invest in it (through teambuilding, social activities, and so on).

But let’s change gears from theory into practice and explore some super practical ways to work on social cohesion.

Strategy 1: Create a team identity

Simply putting a group of people together doesn’t make them a team. The scientific evidence I shared above supports that and explains why this is so. We need more for high-quality teamwork.

In my experience, creating a compelling team identity is a great first step toward social cohesion. If social cohesion concerns members wanting to be and remain part of a group, an attractive team identity is a good place to start. Fortunately, this is easier than you think. Because we evolved to be social animals, something as simple as a “team color” or a “team name” can already evoke pride — especially if there are other teams. This phenomenon is called “minimal group membership” in social psychology.

We like to ask new teams to pick a team name and create at least a first version of their team purpose. We like to start with the latter, and this is one way to do it with your team (it’s called Nine Whys):

1. (5 min) Invite everyone to silently and individually make a list of all the things they do in their work. These can be small or large activities.
2. (5 min) Invite people into pairs. One of the members will become the interviewer, and the other will be the interviewee in the first round. The member who joined the company most recently starts as the interviewer. The interviewer asks the interviewee to share the activities on their list. The interviewer then channels a child's curiosity and asks: “Why are these things important to you?” or “What deeper need do they serve?”. After every response, the interviewer repeats the question gently and with a genuine interest in the answer. Repeat until you reach the deep purpose of why the interviewee does what they do.
3. (5 min) In the pairs, the roles of interviewee and interviewer now switch, and the previous round repeats.
4. (5 min) Pull everyone together. If it’s a large team, you can do an intermediate step with groups of two pairs each. Ask: “What did you notice about our individual purposes? What seems important to us and why?”
5. (5 min) Finally, ask the whole team to reflect together on the question: “How do our individual purposes combine into a purpose for our team? Why do we need to exist in this organization?”. If the statement comes easily, capture it on a poster. Otherwise, you can run a 1–2–4-ALL to create the first version.

What we love about Nine Whys is that it always begins with the purposes of individual members and then creates a collective purpose from that. This is a hugely powerful step towards increased social cohesion, as it helps members to see how they contribute to the whole.

We’ve learned that it’s important not to aim for the perfect team purpose. It will evolve anyway. At the least, the first version of the purpose should clarify why this team exists. It doesn’t even need to be a sentence. A group of 3–5 keywords also suffices.

Once you have a team purpose, you can work together to pick a suitable name that conveys that purpose succinctly. A simple 1–2–4-ALL is a great way to do this. You can also run a poll and pick the one with the most votes. We’ve seen teams with all sorts of hilarious names, like “Team Cevitam”, and “Team Rubber Ducky”, but also more serious ones like “Laser Focus”. Always leave open the option to pick a new name later.

Once you have a team purpose and a team name, you can create all sorts of nice “artifacts” for the team. For example, how about a poster with member avatars, like the one below? You can also print the team name on mugs, and mouse mats, create a team poster, computer wallpapers, etc. Go crazy, and do it together.

Strategy 2: Establish shared norms and values

Begin by helping a team to establish their identity. We like to do this by collaboratively defining the purpose of the team, its values, mission, and goals. Don’t go for perfection; a rough first version is enough to iterate one together later. Doing this often already creates a sense of belonging and unity. You can strengthen this further by encouraging all members to identify how they are part of the team, how the team can help them, and what they will contribute. By fostering a shared team identity, team members are more likely to identify and connect — the essence of social cohesion.

One exercise we like for this is “Worst Team, Best Team”, a mix of the Liberating Structures TRIZ and 1–2–4-ALL. It’s a fun, energetic way for teams to think about what they want to be. We do recommend first doing another exercise to clarify the purpose of the team (like Nine Whys). Here is how to do “Worst Team, Best Team”:

1. Set the stage by asking the team to jump into a time machine and travel to a not-too-distant future where they encounter their dark variant (like in Back to the Future II).
2. (3 min) First, individually, ask everyone to silently write down all the characteristics of their dark variant. What does the team do or not do? What do they believe? How do members act towards each other? Having fun with this one is okay, but encourage people to remain realistic.
3. (6 min) Invite people to pair up and ask them to share their ideas and expand their lists.
4. (12 min) Invite the pairs to share their lists. Work together to create one shared list on a shared surface. Group and deduplicate items, where possible, into themes.
5. (20 min) Repeat the above steps for an alternate future where the team is incredibly successful. Again, collect as many characteristics as possible.
6. (2 min) Individually, ask everyone to pick three characteristics from the “Best Team”-list that they think this team should invest in now to achieve that positive future.
7. (4 min) Ask people to form pairs and ask them to share their ideas.
8. (10 min) As a team, debrief together. What did the pairs come up with? Where is there overlap? Where are the differences? Make a third list together of the characteristics that the team should invest in now.
9. You can follow up with 15% Solutions, WINFY, or 1–2–4-ALL to dig deeper into what is needed to invest in this now. You can also do this later.

Strategy 3: Promote shared experiences and rituals

Many people frown at team building. Granted, we’ve had our fair share of wonky teambuilding events that didn’t feel all that useful. But it is also a matter of setting expectations.

One of the reasons why teambuilding helps is because it creates shared social experiences for teams. That alone increases the sense of belonging and identification. It can also give reasons for members to be proud of their team. For example, we’ve experienced good times when we had to build a (real) catapult as a team and compete against other teams to see who could throw a ball the furthest. It can also be laser gaming, bowling, casual gaming on consoles, a treasure hunt in the park, or visiting a museum together.

Another aspect of this is the rituals that teams develop over time. Rituals are recurring actions, gestures, or procedures that have symbolic meaning to those who participate in them and convey values, norms, or beliefs. This can be as simple as “Friday drinks” to review the week together or just to blow off steam. Rituals are also relevant to how teams deal with failure and stress. For example, one team I worked in had a ritual where the developer who broke the build had to wear a funny hat for a while (which was me on more than one occasion). That company also created a picture wall of team building and other social events. Incidentally, you can also see me wearing an orange octopus in one of the pictures as I had broken the building that day.

However, rituals may be the most important in those areas where new members join or members leave. What happens in those situations? The point of the strategy is not to create rituals forcibly. However, you can encourage them through team building by gently encouraging their formation and by helping teams stick to them over time. We’ve always found it helpful to ask teams questions like the ones below to begin forming rituals:

• Ask: “How do we want to celebrate when something happens that delights us as a team?”
• Ask: “When a new member joins, how do we want to welcome them? What happens? Who does what? What should the experience of the new member be like?”
• Ask: “When someone leaves our team, how do we say goodbye to them? What is important for the team and the person leaving?”
• Ask: “When something goes wrong in our team, how do we want to reflect and deal with those situations? What happens next?”
• Ask: “How do we want to pay attention to someone’s birthday?”

Closing Words

In this post, I discussed how social cohesion contributes to high-quality teamwork. Social cohesion is high when members identify with their team and want to be and remain part of it. This also contributes to other desirable team characteristics, like higher task cohesion and an increased sense of interdependency. In this post, I offered three practical and concrete strategies to improve social cohesion in your team. Give it a try and see what happens!

You can self-diagnose the quality of teamwork in your team with our new tool (free for individual teams) and use our feedback to improve. This tool also measures other areas of high-quality teamwork, such as task cohesion, psychological safety, task interdependency, etc. It’s really cool.

In-Depth: How Social Cohesion Shapes Teamwork And How To Improve It was originally published in The Liberators on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our mission at The Liberators is to unleash teams all over the world from outdated, old-fashioned, and ineffective ways of working. We give most of our materials away for free, like our weekly blogs, podcasts, research initiatives, our facilitation posters, and many of our facilitation guides.

We also developed a series of physical kits with powerful exercises to drive change in and around your team. The revenue we generate from selling these kits is used to create more free content. So, in this post, we will offer a quick tour of our best kits and hopefully convince you to get your hands on one or more if you haven’t already done so.

You can also check out our online shop at shop.theliberators.com. We ship across the globe, except to Russia and the United Kingdom (Brexit made exporting to the UK difficult, sorry!).

Zombie Scrum Survival Kit

We created the Zombie Scrum Survival Kit to celebrate the launch of our book, the Zombie Scrum Survival Guide, several years ago. The kit is ideal if your team is struggling to improve, and in need of some inspiration.

The kit comes with a ton of materials:

• A copy of the Zombie Scrum Survival Guide. In contrast to most books about Scrum and Agile, we tried hard to make this book as practical as possible while also providing strong arguments to improve. The book features over 40+ super-practical experiments to run with your team to improve stakeholder collaboration, release more frequently, expand your autonomy, and improve all the time.
• A stack of 50+ Powerful Questions to invite curiosity in your team, to spark conversation, and to challenge unproductive ideas. The questions are organized into categories, such as “Create better Sprint Goals”, “Break down Product Backlog Items”, “Encourage double-loop learning”, and so on.
• The Ecocycle Planning for Scrum Teams exercise. It is built on the powerful Liberating Structure Ecocycle Planning. It allows you to engage everyone in and around your team to create transparency around the status of activities that prevent Zombie Scrum. For example: “We celebrate our successes, both large and small”, “We decide what is on the Product Backlog and in what order, without requiring approval from people outside the team” and “We improve our tools and technologies to make it easier to ship faster and safer”.
• A deck to capture your team’s 15% Solutions (with explanation cards). Initially coined by the economist Gareth Morgan, 15% Solutions reminds us to start with the things we do control rather than all the things we don’t. The deck provides 50 template cards for your 15% Solutions.
• A large Zombie Scrum First Aid Banner to decorate your team room with. This colorful banner is printed on cotton fabric, so it's very durable. It lists the steps to start overcoming Zombie Scrum.
• A set of Liberating Structures Visual Design Cards. We love the power of Liberating Structures to break open systems that are stuck. So they’re very useful for teams that are completely stuck in Zombie Scrum and want to get out. The set contains explanations for all 33 Liberating Structures, including nice illustrations created by Linda van Sinten.
• A set of Zombie Scrum-themed stickers to decorate your laptop, books, or team room.

The kit comes with facilitation guides for each of the exercises, as well as a digital version. All materials are printed on 100% recycled paper to reduce the impact on the planet. Get the physical kit for 125 euros (ex VAT).

Scrum Team Starter Kit

Another kit we love is the Scrum Team Starter Kit. We designed it with a set of exercises that are ideal when you’re starting a new team (or joining one). We developed the materials in this kit as part of the Professional Scrum Master II Class we designed for Scrum.org, and have extended and updated the cards since to account for changes to the Scrum guide.

It comes with a ton of materials:

• The Definition of Done exercise offers a powerful opportunity to talk about what “Done” actually means for your team, and how a Definition of Done that covers everything up to the actual release is your best way to reduce the risks inherent to complex work.
• The Scrum Events & Activities exercise gives teams an opportunity to refresh their understanding purpose of the various events in Scrum. It is not a theoretical exercise but rather focused on why you’re doing something like a Sprint Review in the first place.
• The Management in Scrum exercise allows teams to uncover how management isn’t left to a single person (manager) in Scrum but rather distributed over the roles of Scrum Master, Product Owner, and team.
• The Scrum Mythbusters exercise consists of a pack of 38 common myths and misunderstandings about Scrum. You can use the cards in a variety of ways to playfully explore why certain statements are true and why others aren’t.
• A pack of 15 Seconds of Scrum, which is a fun energizer-like exercise that we created to get started with new teams. Each card contains several terms related to Agile and Scrum, and it is up to one participant to explain it without naming the term.
• A deck of Liberating Structures Designs Cards (extended edition). We love these “facilitation techniques” to create conversation and to ensure that everyone has the opportunity to have their voice heard. This deck contains explanations for all 33 Liberating Structures and also several structures that are still in development.
• Optionally, you can also get four banners on large cotton fabric canvas. This includes a poster of the Scrum Framework, a poster that explains the Why of Scrum / Agile, a worksheet to identify your stakeholders, and an Improvement Canvas.

The kit comes with facilitation guides for each of the exercises, as well as a digital version. All materials are printed on 100% recycled paper to reduce the impact on the planet. Get the physical kit for 125 euros (ex VAT). We also offer a digital-only kit (which is cheaper).

Unleash Scrum In Your Organization Kit

Our third kit, the Unleash Scrum In Your Organization Kit, is focused on organizations that want to facilitate change across multiple teams. The exercises in this kit are ideal to identify impediments and obstacles that are shared by multiple teams and invite the creative energy to collaboratively overcome them.

It comes with a ton of materials:

• The Panarchy exercise is the core of this kit. It allows you to diagnose your development process across several levels: your teams, your stakeholders, and management. The exercise comes with a stack of factors that are important to effective teams (based on research). It also includes a number of Impediment Cards to mark identified impediments visually.
• The What I Need From You exercise is an excellent follow-up once you have identified team-spanning impediments. This exercise allows teams, management, and stakeholders to ask each other what it is they need from each other in order to work more effectively. It is a very no-nonsense exercise.
• A stack of over 102 Quick Tips, categorized into areas like stakeholder collaboration, team autonomy, continuous improvement, management support, and responsiveness. Each tip offers a super practical and simple way to improve in a particular area.
• A block to capture your team’s 15% Solutions. Initially coined by the economist Gareth Morgan, 15% Solutions reminds us to start with the things we do control rather than all the things we don’t. The deck provides 50 template cards for your 15% Solutions.
• Two large banners printed on cotton fabric canvas. The first poster offers a nice, visual overview of the core findings from our scientific investigation into what makes Scrum teams effective. The second poster offers an overview of the 20+ factors that determine a Scrum team’s effectiveness from our research.

The kit comes with facilitation guides for each of the exercises, as well as a digital version. All materials are printed on 100% recycled paper to reduce the impact on the planet. Get the kit for 125 euros (ex VAT). We also offer a digital-only kit (which is cheaper).

Liberating Structures Immersion Workshop Kit

We love Liberating Structures Immersion Workshops. They are the best way to experience how powerful Liberating Structures are. Over the years, we’ve developed a set of posters and materials to simplify the materials we need to bring. We’ve now made this available as a facilitation kit. It's a great starting point for your own (internal) Immersion Workshop.

The kit contains:

• 5 decks of Liberating Structures Designs Cards (extended edition). We love these “facilitation techniques” to create conversation and ensure that everyone can have their voice heard. This deck contains explanations for all 33 Liberating Structures and also several structures that are still in development.
• 1 deck of Liberating Structures Visual Design Cards. These are larger than the regular design cards and come with a great illustration of the structure. The smaller ones are great for participants, and this deck is great for the facilitators.
• 5 blocks to capture your team’s 15% Solutions. Initially coined by the economist Gareth Morgan, 15% Solutions reminds us to start with the things we do control rather than all the things we don’t. The deck provides 50 template cards for your 15% Solutions.
• 4 large durable banners on cotton fabric canvas to illustrate elements of Liberating Structures. This includes the 10 Principles of Liberating Structures, Liberating Structures vs Conventional Structures, The 5 Design Elements of Liberating Structures, and What Makes A Good Invitation.
• 1 deck of What I Need From You Cards.
• We also offer a larger kit that also contains a set of Tingsha Bells, 3 notebooks for participants, and 7 more durable banners for specific Liberating Structures (e.g. Wicked Questions, Ecocycle Planning, Open Space Technology)

The kit comes with a facilitation guide. Get the kit for 200 euros (ex VAT). The durable banners are expensive to produce, so you can download them free from our webshop and print them yourself.

What Is Keeping You?

We love creating kits that actually help teams solve actual problems. Each kit contains exercises and materials to do this with your team and in your organizations. Each exercise guarantees powerful conversations. And you don’t have to spend time preparing the materials yourself. So, give our kits a try!

You can also check out our online shop at shop.theliberators.com. We ship across the globe, except to Russia and the United Kingdom (Brexit made exporting to the UK difficult, sorry!).

Drive Improvement In And Around Your Team With Our Facilitation Kits was originally published in The Liberators on Medium, where people are continuing the conversation by highlighting and responding to this story.

A while ago, I appealed to the Agile community to rely more on scientific research and less on personal opinions. I’m worried that the overreliance in our community on authority arguments, biased personal experience, hearsay, and wishful thinking is part of why Agile is in decline. Our profession is actively damaged by those who make strong claims without sufficient evidence or sell solutions without proof that they work. How do we know that what we’re peddling to teams and customers isn’t snake oil? The bar for what we consider “true” in our profession is quite low.

I’m not alone in this appeal. I also see it in the work of people like Nico Thümler, Karen Eilers, Luxshan Ratnaravi, Takeo Imai, and Joseph Pelrine. Since my appeal, I’ve worked to bring more scientific research into our profession. This consists of my research projects, and a series of blog posts to summarize scientific knowledge about a range of topics related to Agile. At the same time, there is a surprising amount of pushback from our community. Moreover, many people have approached me personally to wonder how this affects their work.

In this post, I will respond to the most common criticisms and questions about incorporating more scientific research into our field and clarify what my appeal doesn’t mean.

Why is scientific research important to me?

The Agile profession is relatively young and vibrant. It is also deeply idealistic. A cursory look at LinkedIn or news aggregators like Serious Scrum shows many deeply held beliefs about what is and isn’t right. Most of us are in this game because we feel strongly about lofty purposes like “delivering value,” “creating human workplaces,” “enabling empiricism,” and so on. We also have a lot of beliefs about what is required to do so. For some, this is answered with specific frameworks (like Scrum, Kanban, XP) or the dismissal of others (SAFe).

It also manifests in beliefs about how teams should be formed (diverse versus homogeneous, fluid versus stable, technical versus non-technical), what roles are needed, what specific practices teams should use, and what cultural traits must be established in organizations. In other words, there are many things that each of us believes to be true about how teams and organizations should work. However, with the many lively debates on social media, it is also clearly true that there is a lot of disagreement on what is true. Some argue fervently that product managers and product owners are the same, whereas others don’t. Some argue for estimation; others are vehemently against it. And so on. Such questions are empirical, so they can be robustly answered with sufficient data, yet this is rarely attempted in the onslaught of opinions.

“There are a lot of things that each of us believes to be true about how teams and organizations should work. However, as the many lively debates on social media show, it is also clearly true that there is a lot of disagreement.”

Scientific research is important to me because it is the best systematic approach we have developed to determine what is true in the natural world. When practiced properly, it is the least prone to biases and the most likely to approximate how things work in the world around us. As a professional, I feel it is my ethical responsibility to practice what works and discard what demonstrably doesn’t. I also feel my ethical responsibility is to back up claims with evidence proportional to the claim's strength. If I make a generalized claim like “All Scrum Masters need technical skills,” I need to bring evidence from a large sample of Scrum Masters with and without technical skills and correlate to the effectiveness of their teams.

If that evidence doesn’t exist or I’m not aware of it, I should dial back the strength of my claim to be proportional to the evidence: “Based on my experience with X teams, I’ve noticed that Scrum Masters with technical skills seem to have more effective teams.” This is clearly where scientific research comes in. As the best method to determine what is true, we should primarily use scientific evidence to back up our claims about certain practices and do’s and don’ts. We can also use such evidence to challenge claims it doesn’t support.

Is there value in individual experiences?

Many Scrum Masters, Agile Coaches, and others share their personal experiences on blogs and social media. Does my appeal imply that those experiences are useless in uncovering what truly works (or not)?

Not at all. There is always space for individual experience. The scientific method is built on the notion that the experiences we derive through our senses should be the primary source of knowledge. Our individual experiences in our work with teams and in organizations can inform us how things might work. For example, you may experience that large teams are less effective than smaller ones. You may also observe that pair programming leads to better code.

The problem with individual experience is that it is prone to many biases. Our brains are wired to remember those instances that confirm our beliefs and ignore those that don’t (confirmation bias). If I believe that all teams need to be as stable as possible, I’m more likely to remember those instances where this was true. Furthermore, selection bias can easily lead me to experience cases that match my beliefs. For example, I‘ve grown into Agile in small organizations. I’ve long believed that Agile works better there than in large organizations. However, my sample is highly biased. Moreover, more objective data doesn’t seem to support my belief. A more extreme version is the “N=1 bias,” where we extrapolate a single experience to cover all cases. This is typical for many “best practices”-posts in our industry. This leads some people to discard estimation entirely because it doesn’t work in their organization. People argue that “product ownership” and “product management” should be discrete fields because this was the case in their company.

The gist of this is that individual experience can inform us about potential patterns. But we can’t generalize those patterns with confidence to other settings.

In summary, our individual experiences can certainly inform us about potential patterns (e.g., “SAFe wreaked havoc in my organization” or “Pair programming improved our code quality”). But those observations can’t be turned into generalized claims that are true for everyone without stronger evidence. Generalization is only feasible when we can pool many people's experiences from a representative sample and confirm that the pattern is also present there. If this is the case, we can confidently make our claim.

This is essentially what many scientific fields aim to do; they identify potential patterns from individual experiences (qualitative research) and test if those can be generalized to the population (quantitative research). This is why we can say with quite some confidence that teams learn more effectively when there is psychological safety (Edmondson, 1999). We also know that teams that release more frequently tend to have more satisfied stakeholders (Verwijs & Russo, 2023). And so on.

Should we only consider evidence from experiments?

Another line of reasoning is that people agree that scientific evidence is useful but then raise the bar to such a degree that nothing qualifies. In effect, one can make all sorts of claims without grounding them in scientific evidence because it isn’t possible to collect such evidence anyway.

One example is when people argue that only evidence derived through double-blind, controlled experiments is acceptable. These are studies where the researchers modify one variable while keeping everything else equal (“controlled”) and then measure certain outcomes. If the results change because of this modification, it can be attributed with high certainty to the modified variable. Ideally, both the participants of the study and those performing it don’t know what is being tested, making it “double-blind.” While it is true that such studies give a high degree of confidence, it is unreasonable to require it for all sorts of scientific evidence and domains. It often doesn’t even make sense. Let me explain.

Experimental studies are viable in scenarios where the researchers can keep all other variables equal. This is possible in some branches of the natural sciences, like physics, chemistry, and medicine. However, experimental designs are impossible in most other fields, or at least highly unfeasible or unethical. A historian can’t modify something in the past to see how it affects the present. An astrophysicist can’t make one star explode while keeping an identical one intact to see how it interacts with an identical planetary system. A developmental psychologist can’t raise the same kid twice in two settings to see how it affects development. An organizational researcher can’t force everything to remain the same while implementing a certain methodology.

For all their strengths, experimental designs are not suited for every research question or possible in every context. The system under study is often too complex to control all potential variables, like in the social sciences, climate science, and ecosystems, where a thousand variables can influence what happens (culture, personality, personal beliefs, events. etc.). There are also ethical reasons not to use experiments. We can’t expose teams to extreme stress or psychological unsafety to see how they react. Instead, scientists develop evidence with various methodologies, including observational studies, theoretical models, case studies, meta-analyses, and more, to comprehensively understand various phenomena. Each method has its strengths and limitations, and the choice depends on the nature of the research question and the available resources.

Instead, we should weigh the evidence from diverse methodologies (qualitative, quantitative, survey study, correlational, and so on) to inform how true a claim is. Academic communities often publish meta-analyses and literature reviews to weigh the scientific evidence around psychological safety, effective leadership styles, team stability, and scaling frameworks. You can find those on Google Scholar (select “Only reviews” as a filter).

In summary, the argument that we can only rely on evidence from experimental, double-blind studies is unreasonable. It would effectively discard most scientific evidence and disqualify the scientific method altogether for most domains. Instead, we should inform ourselves about the scientific consensus around relevant areas and use that to decide which claims are grounded in evidence and which are just snake oil.

“We should inform ourselves about the scientific consensus around relevant areas and use that to decide which claims are grounded in evidence and which are just snake oil.”

What does this mean for your practice?

With my appeal, I do not expect everyone to engage in scientific research themselves. While I applaud more community-driven research, performing proper scientific investigations is a profession in its own right.

It's useful to look at how more mature professions do this. For example, psychologists have non-commercial institutions like the APA that educate, train, and license psychologists. They also fund research projects and inform their members about scientific studies. Similarly, engineers have the IEEE; architects have the AIA, and project management has the PMI. Such professional institutes exist to protect their professions. In our profession, the Agile Alliance is the closest to what these institutes do. Other institutes in our industry are for-profit, like Scrum.org, Scrum Alliance, Scaled Agile Inc., and others. While they may invest in research, their priority lies in selling commercial services rather than improving the profession.

“Since we don’t have strong non-profit institutions in our profession like the APA, IEEE, PMI, or AIA, the responsibility to protect our profession is more up to the professionals themselves.”

Since we don’t have strong non-profit institutions like the APA, IEEE, PMI, or AIA to provide independent guidance, protecting our profession is more up to the professionals themselves. Here is what you can do:

1. Don’t make bold claims to customers or on social media without presenting strong evidence that supports them. A bold claim is something like “SAFe is the worst thing that happened to Agile.” You can still share this as an opinion but demarcate it as such (“In my experience …”). Anything less is unprofessional, in my view.
2. To assess the strength of the evidence for a claim, consult the scientific consensus around it. Google Scholar is a great starting point. I recommend searching for “review articles” that are fairly recent (like the last two decades). I wrote much more about how to do this here. Academic articles aren’t always easy to read. However, those articles' summary, introduction, and conclusion can usually help. I’m trying to summarize the scientific consensus around several Agile-related topics, like the optimal size of teams, the benefits of pair programming, whether Scrum works better in small organizations, the effects of scaling on team effectiveness, the effects of stress and motivation, and so on.
3. You can contribute to scientific research by connecting with academics like Daniel Russo, Nils Brede Moe, Maria Paasivaara, Margaret-Anne Storey. They are often looking for participants or participating organizations in their studies.
4. You can gently challenge others who make bold claims on social media to present their evidence. If their evidence is based solely on their own experience, the hearsay of others, or even their business interests, we can disregard their claim until actual evidence is provided. If we do more of this as a community, we can continue to improve the professionalism of our profession.

Closing Words

In this post, I respond to some comments made when I appealed to our community to rely more on scientific research and less on personal opinions. I wanted to highlight the continued need for more scientific research in our field. This will bring more professionalism and allow us to deliver more value to the teams and organizations we work with (and less snake oil). This won’t be easy, and it isn’t helped by the lack of independent non-profit institutes that can help in this area. But we must start moving in this direction as a community. I outlined some things you can do in your practice to support this.

Why Science Is Essential To Professionalize Our Community was originally published in The Liberators on Medium, where people are continuing the conversation by highlighting and responding to this story.

Many years ago, I wrote a provocative post that argued that separate testing and acceptance environments (DTAP or OTAP) are wasteful. Many people loved it; others hated it. My view on the post has mellowed a bit over the years. However, I still greatly prefer simplicity over complexity, and DTAP pipelines can be home to gargantuan complexity.

In this post, I want to take a more personal perspective. I will explore how we deploy features for the Columinity (formerly “Scrum Team Survey”). I've been developing this software-as-a-service (SaaS) for the past years with Barry Overeem. It's grown quite a bit over time and matured into a professional platform with many customers. Since I believe you have to “eat your own dog food”, the question is: what does our deployment pipeline look like?

Recap: Why I Dislike DTAP/OTAP

My post was based on my observations of teams and clients that I worked with at the time. I noticed that their extensive DTAP environments created (long) queues, production releases that batched many smaller releases, and reduced actual responsiveness. It also led to team confusion as they determined which features had been deployed to which environment. Was the feature from their previous Sprint already running on “Acceptance,” or was it still in “Testing”? Here is how I visualized the issue with DTAP flows:

So, I described DTAP as an anti-pattern to Agility. Instead, I argued for a much simpler setup where — ideally — each feature is deployed directly to staging if it passes all the necessary tests. This removes much of the need for separate environments for testing and acceptance, which all need to be maintained, kept in sync, and coordinated. Such a deployment strategy also reduces the risk inherent to batched releases that include many features and changes, thus presenting more vectors where things can break unexpectedly. I visualized this like so:

I painted the picture of what such a team looked like:

Imagine a team that can reliably deploy a single feature to a live environment without disrupting it. They develop new features in a development environment. The team integrates work through version control (e.g. Git). Features are developed on a feature branch in their version-control system.

When a feature is done, it is merged or pulled into a ‘main’-branch in their version-control system. A build server picks up the commit, builds the entire codebase from scratch, and runs all the automated tests it can find. When there are no issues, the build is packaged for deployment. A deployment server picks up the package, connects to the webservers, creates a snapshot for rapid rollback, and runs the deployment.

The web servers are updated one server at a time. If a problem occurs, the entire deployment is aborted and rolled back. The deployment takes place in such a manner that active users don’t experience disruptions. After deployment, a number of automated smoke tests are run to verify that critical components are still functioning and performing. Various telemetry sensors monitor the application throughout the deployment to notify the team as soon as something breaks down.

I still support this message. However, I realize it's probably not feasible for larger-scale products in most settings. My experience with the simpler approach was based on a few product development teams I’d been part of. I shouldn’t have made generalized statements based on a small and biased sample. I lacked proper evidence to support them.

But do we practice what we preach if our money depends on it? Let's now dive into the Columinity.

A bit of background on Columinity

Over the three years, we have built Columinity to help teams drive continuous improvement based on data. We created the tool because we know from experience how difficult this can be. Where is improvement most important? What kind of improvements make sense? How do you track improvement over time and know when to celebrate? Here is a quick tour of the platform:

To date, over 28.000 people have used the tool, with 11.329 teams. We have over 50 paying customers across all time zones, many participating with 10 teams or more. Our largest customers use our platform with 50 or more teams.

Our ecosystem comprises 13 micro- and macro services and 7 support services (MariaDB, Redis, RabbitMQ, Exim, etc.). Whenever a new version of a service is released, it is built into a new Docker Container, pushed to our Docker Repositoritory, and deployed from there. Our codebase has over 8.000 unit tests, 300 integration tests, and 100 UI tests.

At the time of writing, our platform has had a 100% uptime for the past 90 days. We haven’t experienced major disruptions in the three years we’ve been online (fortunately!).

Our Deployment Pipeline

So what does the deployment flow look like for Columinity? Funnily enough, I did start with a separate staging environment to review features with Barry Overeem and other stakeholders before deploying them to production.

As I should’ve known, this staging environment started forming queues. I kept expanding the number of features in staging before deploying the whole package to production. This was risk-avoidance behavior on my part. I wanted to stabilize a little more, add one nice tweak, or add one adjacent feature now that I’m at it anyway. Before I knew it, I had two or more weeks of work running on staging but not production. It gave me an excuse to mark a feature as “Done” when deployed on staging. I also started to postpone releases to production because I worried about how those larger batched releases could break something that slipped through the tests, which made things worse. This wasn’t responsive. It wasn’t Agile.

I removed the staging environment, leaving me with only a local development and a production environment. So, what does the deployment flow look like for Columinity?

1. On my development desktop, I run a Docker Host with a core selection of services that comprise our ecosystem. The containers I run are identical to those running on production but with a “debug” flag to increase logging and prevent outbound interactions (external API calls, emails, etc.). For the new feature I’m developing, I open the associated Visual Studio Project and let it connect to local services it needs (like RabbitMQ, secure token API, etc.).
2. For each new feature, I usually start a new branch in GitHub named after that feature. I do my work there and pull the results back to the main branch when all automated tests pass, and both Barry Overeem and I are satisfied with it. Ideally, I try to implement a feature in 2 days or less, but I accept up to 5 days. Beyond that, I refine the feature to make it fit and push the rest of the work into the next iteration. If I really can’t do it within 5 days, I put the feature behind a feature flag.
3. I release low-impact features to production as soon as all tests pass after I merge the code back into the main branch. This is as simple as pulling the latest version of the Docker Container and restarting the associated Docker Service. Features with a larger risk profile (like database migrations and multiple impacted services) are deployed during low-traffic hours on the weekend, so I don’t have to worry that a deployment issue disrupts active users too much. Deployment issues are fortunately very rare and quickly resolved.
4. We run our Sprint Reviews on production. The upside of this is that participants of our Sprint Reviews can immediately use a new feature after they participate. It also allows us to see what it looks like with production data.
5. The new week usually starts with a blank slate. I select a new feature I want to add and repeat the process.

Typically, it takes between 15 and 30 minutes to build a new release from our “main” branch and publish it to production.

Benefits And Caveats

What I like about this approach is that it has very little overhead. The main branch in Github always has a running version identical to production, except for a brief period when I merge my work back in. I can easily switch between features by switching branches (although I believe that multiple active feature branches are an anti-pattern). Furthermore, I’m always running a selection of production services on my local machine (just not with production data and a “debug”-flag), making replicating issues easy.

This flow also allows me to respond quickly to emerging bugs and issues. I only have to create a branch for the bug from “main,” fix the issue, and merge it back into “main.” Then, I pull the changes into the feature branch and continue work. It makes us very responsive to user needs, and I love that. It also saves me a lot of time because I don’t have to keep separate environments in the air and coordinate releases.

A downside of this approach is that I occasionally experience queuing when I complete more than one feature with a higher risk profile in a week. In that case, the deployment makes me more nervous because I have to keep track of multiple changes deployed simultaneously. Fortunately, I’ve never had significant issues with deployments, so I probably should be more confident than I feel. I greatly prefer many small incremental releases (like multiple a week) over a larger one during the weekend. For now, this is manageable, though.

So overall, it‘s pretty close to the ideal scenario. But with these caveats:

• I essentially develop Columinity alone. To use this approach with more developers, you need strong Git and branching discipline. You also need a high degree of cross-functionality so that all members contribute to (preferably) one feature. I’ve used a similar approach with some teams I’ve been part of, and it worked well there, but it requires a lot of practice.
• The local development environments require some set-up. I have one running on my desktop and one on my laptop (for on-the-road work or emergency support). I’ve scripted much of the setup in Powershell. But you must install Docker locally, run the script, and seed the necessary data to run the services.
• If non-developers want to review or test a feature, they also need a local development environment. This will require further scripting to simplify the process. Another option is a shared development environment to which such users can access. However, if teams don’t work on a single feature together, it will be hard to keep that environment stable.

Closing Words

Several years ago I wrote a provocative post that argued that teams are better off without DTAP and OTAP. In this post, I shared how we deploy features for Columinity, a software-as-a-service platform I’ve been developing with Barry Overeem for the past three years. In short, I think we stick quite closely to the ideal scenario. But I also realize it isn’t reasonable to expect this at a much larger scale.

How We Deploy Features For Columinity was originally published in The Liberators on Medium, where people are continuing the conversation by highlighting and responding to this story.

And 3 strategies for how to improve it in your teams

What makes great teamwork? If you’ve been a member of more than one team, you’ve probably noticed that the members of some teams put their motivation and energy together, but it feels more like “loose sand” in other teams. One aspect of this is “team goal commitment” in team research. It indicates to what extent individual members feel committed to achieving the team's goals. And I find it wildly interesting.

Barry Overeem and I are on a mission to unleash teams through an evidence-based approach. In this post, I will briefly overview research on (team) goal commitment. I will then translate those insights into highly practical recommendations and actionable tips you can use to improve the quality of teamwork in your team right away. If you’re curious, you can also self-diagnose your team with our new tool and use our extensive feedback in many other areas of teamwork to improve.

Overview of scientific research on goal commitment

Organizational psychologists have long studied goal commitment (see Locke & Latham, 2002 for an overview). In its simplest form, goal commitment is defined as “one’s determination to reach a goal” (Locke & Latham, 1990). The interest in goal commitment emerged as it became clear in the 1950s and 1960s that the command-and-control style of management from the Industrial Revolution didn’t work well for knowledge workers. It also reflected a general shift in psychology from focusing on disorders and mental illness to a more humanistic, positive psychology interested in improving mental health through motivation and self-actualization (Morgan, 2006).

Edwin Locke and Gary Latham developed the Goal-Setting Theory based on data from earlier decades (Locke & Latham, 1990). They argue that people are motivated by challenging and attainable goals given their skills. When goals are clear enough, they provide a directive function on what to spend time on. If they are ambitious enough (but not overly), they provide an energizing function by creating energy and motivation. Finally, if they are challenging enough (but not too challenging), they provide a persistence function by encouraging people to keep trying.

Goal-setting theory is one of the most robust theories in organizational psychology. Locke & Latham (2002) report that “specific difficult goals have been shown to increase performance on well over 100 different tasks involving more than 40,000 participants in at least eight countries, working in a laboratory, simulation, and field settings”. The weight of the evidence removes doubt that clear, specific, and ambitious goals motivate and increase performance (see also Kanfer, Frese & Johnson, 2017). This body of work informed the concept of SMART goals by George Doran (1981). It was also adapted into “Management by Objectives” (MBO) by Peter Drucker. The degree to which people feel committed to the goals of their team is a critical factor in teamwork research (Klein et. al., 2001).

So now that we know about (team) goal commitment, how can we increase it in teams? Let me begin by emphasizing that the strategies below have been helpful to us. That doesn’t mean they’ll be helpful to you too. Every team is different and has different needs. However, the strategies provide a nice starting point.

Despite the strong evidence that goals are motivating for teams, we observe in our with teams that remarkably few teams actually use goals at all. This also appears to be supported by harder data. Of the 10,000+ teams that have used our online diagnostic tool, “Shared Goals” receives an average rating of 64 on a scale from 1 to 100. There appears to be a lot of room for improvement. What we notice in teams is that goals are often missing altogether or are non-specific (e.g., “Finish all the work” or “Do X, Y, Z and B”). Goal Setting Theory helps us understand why such examples don’t help. Their goals don’t provide a directive function, an energizing function, or a persistence function. So, the net result is low teamwork quality, low overall productivity, and low motivation.

Strategy 1: Set clear goals together

The most effective strategy for improving the quality of goals is to set them collaboratively with your team. While this is an obvious strategy, many teams struggle with it when they lack sufficient autonomy. Team-level goals often have to fit into an overarching goal for the department, value stream, or product.

However, we’ve also noticed that many people think that goal setting is really complicated, but it isn’t all that hard. The only thing you’re trying to do as a team is answer the question: “What is our focus for this iteration, week or month?”. It can even be set daily if the work varies very frequently. The point is that a goal should bring a sense of direction and focus. A goal like “This week, we agree to deliver Feature A and prepare Feature B” is a fine goal. Similarly, “The aim this month is to reduce the number of support calls by 25%” is also fine.

Goals don’t need to cover all the work a team does. While there is great value in a laser focus, the nature of teamwork in most cases means that unpredictable stuff will pop up — like a bug or a support issue — that wasn’t anticipated when the goal was set. There may also be recurring work, like administration and invoicing. The point of goals is that they create a “decision moment” every time work that doesn’t align with the goal could be picked up. You can then decide not to do the work right now because it isn’t important enough — a decision you probably wouldn’t have taken without that goal.

Questions to test the quality of goals

We’ve found the following questions to be helpful to test if a goal meets the three functions of Goal Setting Theory:

• “Of all the activities that we normally do as a team, will this goal help us distinguish between those we should invest time in and those that aren’t important (right now)?”
• “Does this goal give us enough flexibility to be creative at the moment while giving us enough direction to avoid getting lost?”
• “Would we feel a sense of accomplishment as a team upon achieving this goal? Or is it too simple for us or too ambitious?”
• “Does this goal feel ambitious enough for our abilities as a team? Should we make it slightly more ambitious or dial back a bit?”
• WRITE: “For each person individually, does this goal provide you with a sense of shared purpose or direction?”

A simple goal-setting exercise to do with your team

The simplest exercise to set a collaborative goal uses the Liberating Structure 1–2–4-ALL and 15% Solutions. This “mini-string” begins with what is on each member’s mind. It also helps them think about how they can contribute to the shared goal. A good moment to run this string is right after you have collaboratively reviewed the work delivered by the team in the current iteration (pick what makes sense: day, week, Sprint, month, etc.):

1. (2 min) Individually and in silence, each member makes a short list of activities they think are the best way for the team to spend their next iteration.
2. (4 min) Invite people to form pairs. Ask them to share their lists and notice underlying themes and overlapping activities.
3. (15 min) Now as a whole group, each pair briefly shares what they noticed. If any clear themes jump out, you can collaboratively use those to set a goal in the template: “In our next iteration, we will work together to …. so that …”. It's okay if the sentence contains two sub-goals, but fewer is always better. If no clear themes emerge, you can repeat 1 and 2 with the invitation, “What would make a great goal for us next iteration?”.
4. (2 min) Individually and silently, ask each member to identify one or more 15% Solutions. Ask: “Identify one or more concrete steps you will undertake to contribute to achieving the team goal that makes good use of your skills and abilities.”
5. (4 min) Invite people to share their 15% Solutions in small groups (2 or 3). Encourage their partners to help make the 15% Solutions more concrete.

Don’t worry if this process feels like a struggle the first few times. It tends to get progressively easier as members start thinking more about goals and less about all the things that need to be done.

If you want to set long-term goals, a Liberating Structure like Ecocycle Planning is a great idea to first reflect on your activities to date and then identify what needs work.

Strategy 2: Make goals visible

Setting goals collaboratively is great. But it doesn’t help if the goal disappears in someone’s drawer as a sticky. For goals to serve the three functions set out in Goal Setting Theory, we like to keep it as visible as possible for the team. For example:

• Write the goal on a big banner and hang it in the team room.
• At the start of every day, briefly meet with your team to talk about how everyone plans to use today to work towards the goal. Some teams like to do this at the end of the day.
• Every time work is picked up that doesn’t align with the goal, challenge the team gently to reconsider. Ask: “What would be lost if we remain focused on the goal and do this later?”.
• At the end of your iteration (day, week, month, Sprint, etc.), reflect on how you worked together to achieve your goal.

Strategy 3: Redesign the team and its work

Even with the above strategies, some teams can still not formulate goals to create a motivating, energizing environment where members persist even when it gets tough. This often points at deeper structural issues in how teams and the work to be done by them are designed:

• It's not really a team. Everyone mostly works on their tasks. There is no cohesion in the work or a desire or need for it. It is effectively a group of people doing their own things.
• Teams don’t have any autonomy. In some organizations, work is handed to teams in such a detailed fashion that they can’t make any decisions of their own (i.e. work items are assigned to members by a manager). This lack of autonomy makes it hard for members to connect personally with the goals set for the team.
• The nature of the work doesn’t suit teamwork. The notion of teamwork was developed in response to complex tasks that can’t be done by individuals and require multiple minds instead. Not all work suits those criteria.

If you recognize this in your team(s), we recommend redesigning the teams and their work if you are serious about increasing team goal commitment. One of the best ways to do this in our experience, is the Liberating Structure “Purpose to Practice” for the new team or teams. It starts by involving the members directly in reshaping their work, increasing autonomy, and fostering teamwork. Check out this blog post for examples of how to run it.

Closing Words

Collaborative goal setting is a great way to create more motivating environments for teams. It is one of the ingredients of high-quality teamwork and high-performing teams. Despite the robust scientific evidence for the value of shared goals, many teams and organizations still don’t recognize their potential.

In this post, I provided a brief overview of scientific research on goals. More importantly, I provided three practical strategies to make better use of shared goals with your team. Give them a try and see how the quality of your teamwork will benefit from it.

You can self-diagnose the quality of teamwork in your team with our new tool (free for individual teams) and use our feedback to improve. This tool also measures other areas related to high-quality teamwork, such as task cohesion, psychological safety, task interdependency, and so on. It’s cool.

In-Depth: How Goal Commitment Shapes Teamwork was originally published in The Liberators on Medium, where people are continuing the conversation by highlighting and responding to this story.