I am finding that blocker is an emotionally loaded word. Impediments and dependencies are not much better.
Invariably there is always a person at the end of a blocker and no-one wants to be "accused" of being a blocker. I've found this erodes psychological safety even in well functioning teams.
Does anyone have any suggestions for phrasing blockers differently ?
This is more of a team or organizational culture thing. In healthy teams and organizations, words like "blocker", "impediment", and "dependency" do not erode psychological safety.
Dependencies are just connections between work. A needs to start before B can start. A needs to finish before B can start. A needs to finish before B can finish. A needs to start before B can finish. Understanding dependencies is just a way to understand how to order work for a team to be efficient at getting things done.
Impediment and blocker are similar, almost identical in meaning. Something has some up that is slowing or stopping progress on work. However, there is rarely a person as the root cause for an impediment. For example, if you find that your team is waiting on X to provide information or take action, there are other questions to ask. Why hasn't X provided the information? Maybe they don't know about the request. Maybe the backlog of work is very long. Maybe they are the only one who can do the work and they are overwhelmed with work. In some cases, maybe they are being malicious and stalling the request.
Instead of using non-standard terms, which will only cause confusion if you or the team trys to seek help outside the team, make sure that everyone understands exactly what dependencies, impediments, and blockers are and how to get to root causes of problems, not stopping with a person but getting to fundamental process issues.
Neither Scrum nor the Agile Manifesto currently uses the word "blockers." However, this term is often seen in Kanban or other queue-based systems where work-in-progress (WIP) limits can create stop-the-line situations when a queue is full or when a work item can't continue its journey through the process because it is constrained or currently unserviceable.
This is generally a resource or process issue. Any finger-pointing is an organizational culture problem, not one of nomenclature. Ultimately, you will only be able to resolve the underlying issues by reframing them as process issues rather than people problems, and even people problems often turn out to be process problems when you dig down far enough.
Invariably there is always a person at the end of a blocker[.]
This assumption is the root cause of your issue here. You're assuming ab initio that a blocker is a person. Agility is based on processes, and while you often find people attached to a function or performing roles within a process, a process can also be:
Effective agility, both in Scrum and in Lean-based methodologies, is generally based on removing friction by limiting touchpoints and hand-offs to the maximum extent possible. You may also hear the term "waste" applied in this context. The Kanban and Lean methods define muda, mura, and muri as three top-level categories of inefficiency within a process. Other frameworks address different types of inefficiency, but they all do so in one way or another.
Blockers are simply things that prevent a process from continuing. While it could be that Joe in procurement or Alice in finance are the people within the process that are blocking something from being done because they haven't ordered a part or paid the vendor yet, it is still a process problem, and the team should consider:
In other words, while one could assume bad intentions on the part of someone involved in the process, it's more often the case that there is waste within the process that should be addressed through the project's continuous improvement process (kaizen).
As an arbitrary example, if the problem is that Joe isn't able to order parts fast enough because he's overburdened or because Alice needs more lead time to onboard a new vendor that the company hasn't worked with before, then this is a process problem that should be accounted for during Backlog Refinement and Sprint Planning in Scrum, or through changes in the planning and working agreements of any other framework. Solving the problem means solving the underlying process issue and building a culture of honest and continuous inspection and adaptation.
If you approach this right, everyone becomes invested in collaborating on creative solutions to fix any identified process issues. There isn't a silver bullet for preventing a blame culture. Still, by framing "blockers" (or whatever you decide to call them) as process issues that require collaboration and brainstorming then you'll sidestep a natural human inclination to blame-shift.
Reframing is a potent tool. Maximize its use.
Your definition of "Blocker" seems strange to me. A "Blocker" is something that blocks the team, not a single person.
If in a team of Alice, Bob and Charlie, Alice is waiting for Bob, that is not a Blocker or an Impediment. That is just regular teamwork. They sit together, they find the best way to collaborate, the team continues to produce output. A Blocker is Alice waiting for approval from marketing. Now the team is blocked. Because the team itself cannot do anything to progress.
There will always be flow and steps where a task has to wait. For example being Code Reviewed. Or being Tested. Or whatever else your Definition of Done may contain. Waiting on the normal flow of events in a team is not "blocked". It's normal work. If you designate anything that has to wait as "Blocked", every single of your tasks will be blocked at some time and the tag will completely lose it's meaning.
Nobody on the team can be on the end of a "Blocked" ticket. The very definition of "Blocked" is that the team cannot continue on it's own.
"A good topic for the next retro"
My main suggestion is not to change the word used, but to ensure that it's never used to refer to a person - Jane from Accounting isn't the blocker, the blocker is the lack of data you asked her to provide.
Not only does this framing reduce the "blame game" issue, it also gives you a better understanding of the real problem and hence potential alternative solutions. Can you source the data from somewhere else? Can you refactor the work so that you can still progress parts of it while you're waiting for the data? Can you use a proxy for the data for now?
