Why Agile Professionals Feel Undervalued and Why SAFe Makes That Tension Visible
- Bill Holmes
- 2 minutes ago
- 3 min read
“When responsibility is unclear, authority does not disappear. It becomes invisible.” Russell L. Ackoff
“A system must be managed. It will not manage itself.” W. Edwards Deming
Many experienced Agile professionals do not feel undervalued because they lack skill. They feel that way because the systems they work within often fail to make their impact visible.
In many Agile environments, practitioners are responsible for moving work forward, resolving risks, coordinating across teams, and navigating constraints, yet in meetings their role is frequently reduced to facilitation. Updating boards, capturing notes, and keeping ceremonies moving become proxies for leadership, even when the work itself involves judgment, tradeoffs, and real accountability.
There is nothing wrong with facilitation. But facilitation alone is not leadership, and when systems blur that distinction, capable professionals are often underestimated.
This helps explain why posts that validate this experience resonate so strongly. They rarely introduce new ideas. Instead, they give language to something many professionals already experience but struggle to articulate.
Scrum Was Designed to Minimize Visible Authority
Scrum intentionally deemphasizes hierarchy, and at the team level that design choice works well. Decision making remains local, feedback loops are short, and accountability is immediate and tangible.
However, Scrum was never intended to manage enterprise complexity. It does not explicitly define ownership of cross team dependencies, architectural sequencing, funding tradeoffs, or delivery risk at scale. Those responsibilities still exist, but they live outside the framework and are often handled informally.
When authority remains implicit rather than explicit, leadership becomes harder to see, and meaningful impact is easier to misunderstand.
Scale Changes the Nature of Leadership
As organizations grow, the nature of work changes in ways that teams alone cannot absorb. Dependencies increase, integration risk moves earlier in the lifecycle, and decisions made in one area begin to create cascading consequences elsewhere.
Someone must decide what gets funded now and what waits. Someone must accept risk, manage sequencing, and resolve conflicts between competing priorities. When those decisions are not made explicitly, they are still made, but often too late and without clear accountability.
This is where frustration takes hold. Practitioners feel accountable without authority, leaders feel responsible without visibility, and the system begins to strain under their own ambiguity.
What SAFe Makes Explicit
SAFe does not exist to add process for its own sake. It exists to make reality visible at scale.
By clarifying decision ownership, exposing dependencies early, and establishing shared cadence, SAFe enables teams to integrate predictably while forcing tradeoffs into the open when change is still affordable. What is often perceived as control is, in practice, accountability made explicit.
SAFe does not create authority. It reveals where authority already exists and requires organizations to acknowledge and manage it deliberately.
Why SAFe Triggers Strong Reactions
Resistance to SAFe is rarely about Agile values. More often, it is about exposure.
By reducing ambiguity, SAFe assigns ownership to decisions that were previously diffuse, surfaces tradeoffs that could once be deferred, and removes the ability to hide behind process language. Practitioners are no longer expected to absorb systemic risk quietly, and leaders can no longer rely on informal coordination to carry enterprise commitments.
When responsibility becomes visible, roles become clearer. When roles become clearer, status shifts. That shift is what fuels debate, resistance, and engagement.
Making Impact Visible
People are not asking for inflated titles. They want their contribution to be understood and their responsibility to be recognized.
SAFe does not elevate roles for status. It elevates responsibility so outcomes can be delivered deliberately rather than accidentally. It scales accountability upward instead of pushing burden downward.
Being underestimated does not mean you are small. It often means the system was not designed to make your impact visible. That is not an Agile failure. It is a leadership design problem, and it is one of the problems SAFe was built to address.