Building Psychological Safety in a Scrum Team: Lessons from a Realistic Scenario
Psychological safety, as described in the research of Harvard Business School professor Amy Edmondson, is the belief that the work environment is safe for interpersonal risk-taking -- that you can speak up, ask questions, make suggestions, and raise concerns without fear of punishment, embarrassment, or marginalisation. In Scrum teams, psychological safety is foundational: the framework's inspection and adaptation cycles (Sprint Reviews, Retrospectives) only work if team members are willing to be honest about what is not working, what they do not understand, and what they are concerned about.
Here is a realistic scenario based on common patterns in Scrum team dynamics, with identifying details removed.
The Scenario
A Scrum team of seven people at a public-sector technology organisation had been operating for eight months. The Scrum Master was technically experienced and well-regarded by management. Sprint Retrospectives were held regularly and produced action items, but the same problems -- unclear acceptance criteria, insufficient testing time, dependencies on a team outside the Scrum team -- appeared in Retrospective after Retrospective without being resolved. The team's velocity had been flat for six Sprints.
What Was Actually Happening
When a new Scrum Master joined for a three-month rotation, she noticed that Retrospective discussions were dominated by two of the seven team members. The others responded to direct questions with short answers and rarely volunteered concerns unprompted. In one-on-one conversations, several team members revealed concerns they had never raised in the Retrospective: they believed the lead developer would dismiss their technical concerns; they were uncertain whether the Scrum Master had the authority to resolve the dependency issue; and one developer said she did not raise issues in group settings because she had been publicly corrected twice in previous Retrospectives.
What Changed
The new Scrum Master restructured the Retrospective format. Rather than open discussion from the start, the team used anonymous written input (sticky notes or a digital equivalent) before any discussion. This gave every team member an equal voice before social dynamics could suppress quieter voices.
The new Scrum Master explicitly named the dependency issue as a blocker that was beyond the team's control to resolve internally, and escalated it formally. Naming the fact that some problems cannot be fixed internally -- and visibly escalating them -- signals to the team that raising problems is worthwhile.
When team members raised concerns, the Scrum Master modelled curiosity rather than defensiveness. She asked questions ('can you tell me more about what you saw there?') rather than moving to solutions immediately. This signalled that concerns were welcome, not inconvenient.
Lessons Learned
Psychological safety is built through consistent small actions, not through a workshop or a declaration. Every time a concern is raised and met with curiosity rather than dismissal, safety increases. Every time a concern is dismissed or the person raising it is corrected publicly, safety decreases.
Retrospective format design affects who speaks. Anonymous input before open discussion levels the playing field for team members with lower confidence or in lower-status roles.
Visibly acting on what the team raises -- even by escalating formally what cannot be resolved internally -- signals that raising issues has consequences. Teams that raise problems and see nothing happen learn to stop raising problems.
XNM provides Scrum coaching and agile delivery advisory services to public-sector organisations. Reach out to XNM's program & project delivery advisory team to discuss Scrum team performance and psychological safety for your organisation.