A retrospective should improve the team’s system, not judge individuals. The retrospective prime directive (also called agile prime directive) sets a shared agreement: we’re here to learn, not to blame.
If your retrospective has ever felt tense, political, or personal, start by reading the agile retrospective prime directive out loud, then structure the session to support a blameless retrospective (including optional anonymity when trust is still forming).
If you want a quick retrospective refresh beyond the Prime Directive, start here: Agile Retrospective for Beginners.
Gathering your team to discuss how the past work cycle went is excellent. But it can quickly turn into a blaming game. That drains the value of the retro and can damage trust and team health.
Retrospectives often go wrong not because the team “doesn’t care,” but because the environment doesn’t feel safe. That’s why every attendee should understand the retrospective prime directive before the discussion starts.
Keep reading to learn more about this cornerstone and enhance your Retros.
Topics to check
- What is the Prime Directive?
- Who is Norman Kerth?
- The Blameless Retrospective
- The Anonymous Retrospective
- What is the Agile Prime Directive in Practice?
What is the Agile Retrospective Prime Directive in Agile?
The agile retrospective prime directive exists to make the retro constructive. It clarifies that reviewing the past work cycle is not about attributing mistakes or identifying who failed. It’s about improving the team’s process, constraints, and collaboration.
Here’s the core idea in Norm Kerth’s words:
"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
--Norm Kerth, Project Retrospectives: A Handbook for Team Review
In plain terms, people acted with the information, skills, time, resources, and constraints they had then. The team’s job in a retro is to improve the system so “doing the best you can” gets better outcomes next time.
Norman Kerth included this phrase in his 2001 book Project Retrospectives: A Handbook for Team's Reviews, where he digs deeper into the art of performing Retros. But why would you listen to Kerth's advice?
Who is Norman Kerth?
He is a consultant based in Portland, Oregon, and has over 20 years of experience working with companies to develop specification and design methodologies, emphasizing object-oriented technologies. He has helped organizations like Microsoft, IBM, American Express, Nike, and the US Army. In case you want to learn more about his resume before trusting him.
Sadly, the expert suffered a disabling accident some years ago. You can learn more about Norman Kerth's situation.
The Blameless Retrospective
A blameless retrospective isn’t a “no accountability” meeting. It’s a meeting where the team can speak honestly without fear, so you can identify the real causes of problems and commit to improvements.
Step one is to start the session by reminding everyone of the retrospective prime directive. But a blameless retro also requires active facilitation: if the discussion starts to turn personal, anyone (especially the facilitator) should redirect it back to facts, constraints, and next actions.
Respect is not only about being polite. It’s also about ensuring all voices are heard. Catapult Labs references advice attributed to Sverrir Tynes (Atlassian Solutions Partner): facilitators and outspoken teammates can actively support quieter members to participate.
A practical facilitation move: when blame language appears (“X didn’t do…”), reframe to a system question:
- “What conditions made that outcome likely?”
- “Where did the process or handoff break?”
- “What would have made the right action easier?”
If your retrospective produces insights but no follow-through, this is the fix.
The Anonymous Retrospective
In an ideal world, teams always feel safe enough to share openly. In reality, trust builds over time. When trust is still developing, anonymity can help people share hard truths without fear.
Some practitioners worry that anonymous participation reduces transparency. But anonymous input can still be Agile-aligned if it helps the team uncover reality, learn faster, and improve. The goal is to understand what’s working, what isn’t, and what to change, especially early in a team’s lifecycle.
Anonymous retros can be naturally “more blameless” because they reduce identity and status pressure. When names are removed, you’re left with ideas and patterns instead of defensiveness.
If anonymous retros could help your team, consider running retros inside Jira or Confluence. Catapult Labs’ tools support anonymous input and voting to reduce fear and increase participation. Start your free trial here.
When should we use an anonymous retrospective?
Use anonymous input when:
- The team is new or recently restructured
- There’s a power gap (manager present, cross-team politics)
- You’re tackling sensitive topics (conflict, workload, quality issues)
Then, as trust grows, gradually reduce anonymity for healthier direct feedback. Use anonymity as a bridge to trust.
How to Apply the Prime Directive in Practice
Teams often say the agile prime directive, but still run retros that feel unsafe. Here’s a simple way to operationalize it:
1) Prime the room (2 minutes)
- Read the retrospective prime directive
- Remind: “We’re improving systems, not judging people.”
2) Use neutral data
- timelines, incident notes, cycle time trends, ticket flow
- avoid “who did what” storytelling
3) Convert complaints into experiments
- “What’s one change we can test next sprint?”
- “How will we measure if it helped?”
4) Assign ownership
- Every action item has an owner + due date
This is how a prime directive retrospective becomes a real improvement instead of catharsis.
What’s the difference between the retrospective prime directive and a “no blame” culture?
The Prime Directive is a meeting-level agreement that creates safety for reflection. A no-blame culture is broader and shows up in how teams handle mistakes daily. The Prime Directive helps you practice blamelessness consistently, especially during tense retros.
In conclusion
-
The Prime Directive’s purpose is to set the right environment to review the past work cycle, without apportioning blame. It promotes the idea that everyone did their best, given the circumstances.
-
Running anonymous Retrospectives can almost ensure your sessions are blameless. They can be a great tool to build trust between people, especially in recently formed teams.
