By Ernesto Custodio, PhD, Editor in Agile Pulse — 28 Jul 2026

The Problem with Agile Is HIM: The Human In the Middle

There is a pattern in Agile failure that does not appear in retrospectives and is almost never named in coaching conversations. The pattern is a person: the Human In the Middle.

Good intentions and structural centrality are not the same thing. HIM is usually trying to help. The dependency that creates is the problem.

There is a pattern in Agile failure that does not appear in retrospectives, does not get named in sprint reviews, and is almost never addressed directly in coaching conversations.

The pattern is a person.

Not a bad person. Not a malicious person. Usually someone who is hardworking, well-intentioned, experienced, and deeply invested in the team's success. But structurally positioned in a way that prevents the team from functioning as Agile principles require.

The Human In the Middle. HIM.

What HIM Does

HIM is the person through whom all significant information and decisions must pass.

HIM might be the Scrum Master who is so present in every ceremony that team members wait for them to speak before forming their own opinions. HIM might be the Product Owner who manages stakeholder relationships so tightly that the team never develops its own understanding of business context. HIM might be the tech lead who is the only person who understands the architecture, making them the bottleneck for all technical decisions.

In each case, HIM is not trying to create dependency. HIM is trying to help. HIM is good at the job. HIM solves the problems that present themselves, and it works -- right up until the team cannot function without them.

How HIM Emerges

The conditions that create HIM are structural:

Teams that reward individual heroics. If organizational culture celebrates the person who solves the problem rather than the team that builds the system to prevent the problem, you will produce HIMs.

Complex organizational environments. When stakeholder navigation, political awareness, and cross-team coordination require significant skill and relationship capital, experienced practitioners hoard those capabilities rather than distributing them.

Time pressure. Coaching takes longer than doing. Under continuous delivery pressure, it is always faster for the experienced person to handle the problem than to develop the team's capacity to handle it.

Good intentions without systems thinking. HIM almost always believes they are helping. They are not wrong that the team would be worse off without them today. They are missing that they are also preventing the team from developing the capabilities that would make them better tomorrow.

What HIM Costs

The cost of HIM is not visible until HIM is gone.

When the Scrum Master who runs every ceremony leaves, the team does not know how to run a retrospective. When the PO who manages all stakeholder relationships goes on leave, the team cannot make a decision without escalating. When the tech lead who holds all the architectural knowledge moves to another team, delivery slows to a crawl.

HIM-dependent teams are fragile. Their delivery capacity is bounded by one person's availability.

The other cost is less obvious: HIM-dependent teams stop developing. When the answer always comes from the same person, team members stop developing the judgment that would let them answer it themselves. Capability stays concentrated rather than distributing across the team.

Getting Out of the Middle

The work of removing HIM is not removing the person. It is changing the structural conditions that created the dependency.

Make implicit knowledge explicit. If team members are waiting for HIM to explain the architecture, the business context, or the stakeholder dynamics, the first step is documentation. HIM writes it down. The team accesses it without asking.

Transfer facilitation to the team. Scrum Masters who run every ceremony should start handing ceremonies back to the team, one at a time. The first time the team runs a retrospective without the Scrum Master leading it, the output will be different. That is fine. Different is not the same as worse.

Create direct access. If HIM is the only channel to stakeholders, open other channels. Invite team members into stakeholder conversations. Let them develop their own relationships and understanding of business context.

Name the pattern. In coaching conversations with HIM, use language that makes the structural problem visible: "The team performs at the level you allow them to perform at. If you are the ceiling, the team cannot grow beyond you." This is not comfortable. It is necessary.

The Hardest Part

The hardest part of this work is that HIM often does not want to be moved out of the middle. Being necessary feels like security. Expertise feels like value. The person who holds all the knowledge is hard to let go -- by themselves and by the organization.

The coach's work is to help HIM find value in team capability rather than individual indispensability. That reframe is possible. It is not easy.

Recognizing HIM in Yourself

Every practitioner has been HIM at some point. The question is whether you recognize it.

Signs that you are currently HIM on your team:

The team asks you before making decisions they should be able to make themselves
You are the first person stakeholders contact about team matters
You are in the critical path for most significant information flows
Your absence would measurably reduce the team's effectiveness in the short term
You have been in the same team role for more than 18 months without consciously reducing your dependency footprint

Recognizing the pattern is the prerequisite for changing it.