Psychological Safety in Agile Teams: What It Is and How to Build It

Agile teams depend on people speaking up: raising problems at the Daily Scrum, sharing honest feedback at the Sprint Review, admitting mistakes in the Retrospective and challenging ideas that will not work. None of that happens if people feel it is risky. Psychological safety is the belief that it is safe to take those interpersonal risks. This guide explains what psychological safety is, where the idea comes from, what the research shows, how it relates to Scrum and how leaders and Scrum Masters can build it.

Key takeaways

• Amy Edmondson describes psychological safety as a shared belief that a team is safe for interpersonal risk-taking.
• Her research found that teams with higher psychological safety learn more, partly because they report and discuss mistakes openly.
• Google's Project Aristotle found psychological safety to be the most important of the team dynamics it studied.
• Psychological safety is not about being nice or lowering standards; high-performing teams combine it with high accountability.
• Leaders shape it most, especially through how they respond when people raise problems or admit mistakes.

What is psychological safety?

Amy Edmondson, a professor at Harvard Business School, defined team psychological safety in her 1999 study as a shared belief held by members of a team that the team is safe for interpersonal risk-taking. In practice, it means people feel able to ask questions, admit mistakes, raise concerns and propose new ideas without fear of being embarrassed, rejected or punished.

The idea has earlier roots. Edgar Schein and Warren Bennis wrote about psychological safety in the context of organisational change in 1965, and William Kahn's 1990 research linked it to how engaged people are at work. Edmondson's work brought the concept to the level of teams and showed its connection to learning.

What the research shows

Edmondson's hospital study

Early in her career, Edmondson studied hospital teams, expecting to find that better teams made fewer medication errors. Instead, the data suggested that better teams reported more errors. On closer study, she concluded that the better teams were not making more mistakes; they were more willing to report and discuss them. That openness allowed them to learn and improve. This insight led to her research on psychological safety.

Learning behaviour in teams

In her 1999 study of work teams in a manufacturing company, Edmondson found that psychological safety was associated with learning behaviour, such as seeking feedback, sharing information, asking for help and discussing errors, and that learning behaviour was associated with team performance.

Google's Project Aristotle

Google studied what made some of its teams more effective than others in a research project called Project Aristotle, and shared its findings publicly in 2015. It identified five dynamics of effective teams: psychological safety, dependability, structure and clarity, meaning and impact. Of these, psychological safety was found to be the most important, underpinning the other four.

Psychological safety is not "being nice"

A common misunderstanding is that psychological safety means avoiding conflict or lowering expectations. Edmondson is clear that it does not. She describes a matrix combining psychological safety with performance standards or accountability:

	Low standards	High standards
High psychological safety	Comfort zone: pleasant, but little challenge or learning	Learning zone: people collaborate, learn and do their best work
Low psychological safety	Apathy zone: people disengage	Anxiety zone: people are afraid to speak up and problems are hidden

The goal is the learning zone: high standards and high safety together. In a psychologically safe team, disagreement is common, but it is about ideas, not attacks on people.

The four stages of psychological safety

Timothy R. Clark, in his 2020 book The 4 Stages of Psychological Safety, describes safety developing in stages:

1. Inclusion safety: people feel accepted as members of the team.
2. Learner safety: people feel safe to ask questions, experiment and make mistakes while learning.
3. Contributor safety: people feel safe to use their skills and contribute meaningfully.
4. Challenger safety: people feel safe to challenge the status quo and suggest changes.

Challenger safety is the hardest to reach and the most valuable for improvement, because it allows people to question decisions and ways of working.

Psychological safety and Scrum

Scrum depends on psychological safety throughout:

• Transparency, one of Scrum's three pillars, requires people to show real progress and real problems.
• The Scrum values of openness, courage and respect describe behaviours that psychological safety makes possible.
• The Daily Scrum only works if Developers are honest about impediments.
• The Sprint Review needs honest feedback from stakeholders and honest reporting from the team.
• The Sprint Retrospective needs people to discuss what went wrong without fear of blame.

Many teams open Retrospectives with the "Prime Directive" from Norman Kerth's 2001 book Project Retrospectives. In essence, it asks everyone to believe that, given what people knew at the time, their skills and abilities, the resources available and the situation, everyone did the best job they could. It sets a tone of learning rather than blame. See how to run a Sprint Retrospective.

Signs of low psychological safety

• Meetings are quiet, and the same few people always speak
• Problems are discovered late, often by someone outside the team
• People blame others or external factors rather than discussing what happened
• Status updates are always positive, even when work is struggling
• Questions are rare, especially from newer team members
• Retrospectives produce few real insights

How leaders build psychological safety

Edmondson describes three things leaders can do, in her 2018 book The Fearless Organization:

Set the stage

Frame work as a learning problem rather than an execution problem: in complex work, mistakes and uncertainty are expected. Make clear why people's input matters.

Invite participation

Show humility about what you do not know, ask genuine questions and create structures for input, such as asking each person in turn.

Respond productively

When someone raises a problem or admits a mistake, thank them, focus on what can be learned and what to do next, and avoid blame. How leaders respond to bad news is the single strongest signal of whether it is safe to speak up.

Practices for Scrum Masters and teams

• Start meetings with a quick check-in so every voice is heard early.
• Use silent writing before discussion in Retrospectives and refinement, so quieter people contribute equally.
• Agree working agreements together, including how the team handles disagreement.
• Talk about mistakes as learning. Some teams hold short "what did we learn" sessions after incidents, focusing on the system, not individuals.
• Model vulnerability. A Scrum Master who admits their own mistakes makes it easier for others.
• Protect people who speak up. If someone raises a difficult issue, make sure they are not penalised for it.

For more on the Scrum Master's role, see what does a Scrum Master do?

Psychological safety in remote teams

Remote work can make psychological safety harder: it is easy to stay silent on a video call, and tone is easily misread in writing. Helpful habits include turn-taking in meetings, inviting written input before discussions, checking in individually with quieter team members, and responding to problems raised in chat with the same openness as in person.

How to measure psychological safety

Edmondson developed a short survey that asks team members how far they agree with statements about their team, for example whether mistakes are held against people, whether it is safe to take risks and whether people are able to raise problems and tough issues. Many organisations use similar questions in regular team health checks. The results are most useful as a starting point for conversation, not as a score to judge teams or leaders. Trends over time matter more than a single result.

A worked example: turning around a quiet team

As an illustration, a new Scrum Master joins a team where Retrospectives are short and silent, and problems usually surface only when a stakeholder complains. The Scrum Master learns in one-to-one conversations that, a few months earlier, a team member was publicly criticised by a manager after raising a delay. Since then, nobody has raised bad news.

• First: the Scrum Master talks privately with the manager about the effect of that incident, and the manager agrees to respond differently in future.
• Next: in Retrospectives, the Scrum Master introduces silent writing and anonymous input, so people can raise issues without being identified.
• Then: when a Developer raises a risk at the Daily Scrum, the Scrum Master thanks them publicly and helps the team act on it quickly.
• Over time: the manager attends a Sprint Review and responds calmly to a missed item, asking what the team learned.

After a couple of months, problems are being raised earlier and Retrospectives are producing real improvements. Nothing dramatic happened; consistent behaviour slowly rebuilt trust.

Psychological safety for new team members

New team members often feel least safe to ask questions, even though they have the most to ask. Teams can help by assigning a buddy, explicitly inviting questions in the first weeks, pairing on work, and making clear that nobody is expected to know everything. How a team treats its newest member shapes whether it gains the fresh perspective newcomers bring.

Questions leaders can ask to invite input

• What are we missing?
• What concerns do you have about this plan?
• What would you do differently?
• Who has a different view?
• What did we learn from this?
• How can I help?

Asking is only half the job. Listening carefully and acting on what you hear is what convinces people it was worth speaking up.

Psychological safety during incidents

How a team handles failures, such as a production outage, strongly shapes psychological safety. Many engineering organisations use blameless postmortems, a practice described in Google's 2016 book Site Reliability Engineering. After an incident, the team reviews what happened, why the system allowed it and how to prevent it recurring, without blaming individuals. The assumption is that people acted reasonably with the information they had, and that lasting fixes come from improving the system. Teams that review incidents this way learn faster, and people report problems sooner next time.

Common mistakes

• Treating it as niceness. Avoiding hard conversations reduces learning.
• Announcing it without changing behaviour. Saying "you can tell me anything" means little if bad news is punished.
• Blaming individuals for system problems. This teaches people to hide problems.
• Measuring it and ranking teams. This itself reduces safety.
• Expecting instant change. Trust builds slowly through consistent behaviour.

Learn more

Our complete agile leadership guide places psychological safety within the wider picture of agile leadership, and servant leadership in agile teams explores a closely related idea. Scrum Leader Plus covers coaching multiple teams, cross-team dependencies and organisational change; the exam is taken online on ExamVault by CertExpert with three attempts included, and the certificate and digital badge are valid for two years.