The retrospective summary that named a person three times

Three distinct failures, not one.

1. Consent and transparency. Team members did not know their words were leaving the organisation, and could not have opted out. 'Anonymised' is doing a lot of work in the manager's sentence: a transcript of nine people discussing a specific Sprint against a specific customer is re-identifiable from context even with names stripped. The test is not whether a name appears; it is whether a participant would recognise themselves and each other.
2. Accuracy creating harm. The tool attributed a concern to a person based on frequency, not meaning. An unverified summary about an individual, circulated to a manager, is a performance claim dressed as a meeting note. That is what damaged the room, more than the data transfer did.
3. Purpose and ownership. Retrospective output belongs to the team. Repurposing it as the Scrum Master's productivity gain - and as an input to a manager's view of health - changes what the artefact is for without anyone agreeing to the change.

Immediate actions this week:

• Stop sending retrospective content to that tool. Say so plainly and say why.
• Disclose exactly what was sent, to which vendor, and what the vendor's retention and training-use settings are - if you do not know, find out and report back.
• Correct the record with your manager about Priya, in writing if the health note went out.
• Apologise specifically, not generally: name the concrete harm (people now self-censor) and the concrete change (no tool touches retro content until the team sets the rules).
• Ask the team to define those rules - approved tool or none, what may leave the room, whether summaries happen at all, who validates them.
• Treat the next retrospective as a retrospective on safety. Do not paper over it with an icebreaker.

The accountability does not move. A tool can compress, draft, structure, remind, and generate candidate patterns for the team to test. It cannot hold accountability, and it cannot exercise judgement in the moments where the Scrum Master's value sits:

• Teaching and coaching Scrum. Diagnosing why the team is avoiding a conversation requires reading the room and knowing the history. A draft agenda is fine; the decision about what this team needs this week is not delegable.
• Facilitation. Sensing that someone has gone quiet, choosing to protect a voice, deciding when to stop - these are real-time judgements on human signals a transcript flattens.
• Removing impediments. That work happens through relationships and organisational influence. A tool can help you write the persuasive message; it cannot spend the trust.
• Anything that becomes a judgement about an individual's performance. This is the line the summary crossed. Retrospective themes are about the system; a model's frequency count will happily manufacture a story about a person.

Transparency practices that actually work:

• Disclose before use, not after - name the tool and the data flow at the start of the retrospective, and make opting out costless.
• Publish a short 'how we use AI here' note in the team's working agreement with a named owner and a review date.
• Let the team validate any AI-produced summary before it becomes the record; the team's words are the record, the summary is a convenience.
• Never route tool output into a manager's view of team health without the team knowing it exists and what it says.

The reasoning to give your manager: the forty-five minutes saved is real, but it was purchased with retrospective candour, which is far more expensive to rebuild. A quiet retrospective costs more than forty-five minutes a Sprint, every Sprint.

Do not argue about a definition; reframe the question. 'Anonymised' is a threshold the manager believes has been met. Arguing about whether context re-identifies people turns into a technical dispute you may not win in the room and do not need to win.

Reframe as three things the manager already cares about:

• Risk ownership. Ask who is accountable if the vendor retains or trains on the content, and whether that is a decision the manager wants to make implicitly on the team's behalf. If the organisation has an approved-tool list, this is a procurement question, not a scruple.
• Evidence quality. The summary named a person wrongly. Anything the manager uses to make decisions must be trustworthy; a tool that miscounts speakers will also miscount causes.
• Cost of the alternative. You are not refusing to save forty-five minutes; you are proposing a cheaper way to save them - a team-owned template, an approved internal tool with retention switched off, or the team writing its own three-bullet summary in the last five minutes.

Offer a concrete option, not a veto. Scrum Masters who only say no get routed around. Bring two viable paths and a named owner for each.

If the manager still insists: state the risk once, clearly, in writing, and confirm who is accepting it. Your accountability is to make the risk visible and owned - not to win. Then protect the room: the team can choose what it puts in the transcript, and that choice belongs to them.