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.
Analysis and Recommendations
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:
- An externality.
- A role, procedure, or function performed by a tool, group, or sub-process.
- Et cetera and so forth.
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:
- What work is being prevented.
- What the constraint is.
- Where the constraint is within the overall process.
- Whether the process can route around the constraint.
- How to avoid similar constraints in the future.
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.