When Agile Became What It Promised to Kill
A familiar piece of Agile coaching advice circulates frequently on LinkedIn: how Scrum Masters should respond when teams say their work doesn't fit a fixed sprint.
The advice is well-structured. It typically references established Agile thinkers, uses accessible analogies, and offers practical frameworks for managing scope within time-boxes. As a piece of coaching content, it is competent.
But it raises a question that deserves more attention than it usually gets: what happens when a methodology designed to liberate teams becomes the very thing those teams need liberating from?
A Brief History of a Rebellion
In February 2001, seventeen software developers met at a ski lodge in Utah and signed what became known as the Agile Manifesto. The document was remarkably short — four value statements and twelve principles. Its essence was a rejection of heavyweight processes, excessive documentation, rigid planning, and the assumption that managers know better than the people doing the work.
It was, in every meaningful sense, a rebellion. Against bureaucracy. Against command-and-control. Against the idea that process compliance equals quality.
Twenty-five years later, Agile has become a global industry. Certification programmes charge hundreds — sometimes thousands — of euros per credential. Consulting firms offer "Agile transformation" engagements that run into the millions. Frameworks have been built on top of frameworks: SAFe, LeSS, DAD, Nexus — each adding layers of structure, roles, ceremonies, and governance to a movement that was born from the desire to strip those things away.
The rebels won. And then they built an empire that looks remarkably like what they overthrew.
The Ceremony Trap
Consider a typical Scrum implementation in an enterprise environment.
There's a sprint planning meeting. A daily stand-up. A sprint review. A retrospective. A backlog refinement session. These are the prescribed ceremonies — and in many organisations, they've become exactly that: ceremonies. Performed because the process requires them. Attended because absence is noticed. Facilitated because someone holds the title that demands facilitation.
The stand-up that was meant to be a quick coordination pulse becomes a fifteen-minute status report to management observers who weren't supposed to be there. The retrospective that was designed for honest reflection becomes a theatre of carefully worded feedback where what actually went wrong stays unsaid because the Jira board is projected on the wall and everything is traceable. The sprint review becomes a demonstration for stakeholders whose priorities were already locked in before the sprint began.
The rituals survive. The purpose behind them quietly erodes.
This isn't a failure of the people performing the ceremonies. It's a structural outcome of industrialising something that was designed to be adaptive. When a practice becomes mandatory, it stops being a choice. When it stops being a choice, it stops being agile — by definition.
The Autonomy Paradox
The post that triggered this newsletter made an important point: fixed deadlines only thrive with team autonomy. This is correct. It's also, in most enterprise implementations, fiction.
Genuine team autonomy means the team decides what to build, how to build it, and how to organise themselves to do it. The sprint boundary provides the constraint; the team provides the solution.
What actually happens in most organisations is subtly but fundamentally different. The Product Owner arrives at sprint planning with a list that was shaped — sometimes dictated — by management priorities, stakeholder pressure, or roadmap commitments made months earlier. The team "estimates" using story points — a unit of measurement so abstracted from reality that entire conference talks are dedicated to debating what it means. The sprint is "planned" collaboratively, but the outcome was largely predetermined before anyone entered the room.
The team has autonomy over how to implement. They rarely have meaningful autonomy over what to implement or whether the work is appropriately scoped for the time-box. And when the sprint ends and the work isn't done, the conversation tends to focus on estimation accuracy or team velocity — not on whether the scope was reasonable or the constraints were realistic.
Autonomy within a predetermined scope, measured against externally set expectations, facilitated by someone whose performance is evaluated on the team's adherence to the framework. That's not autonomy. That's delegation with monitoring.
The Role That Lost Its Purpose
The Scrum Master role, as originally conceived, was genuinely valuable. A servant-leader who removes impediments, facilitates collaboration, shields the team from external interference, and helps the organisation understand where its own processes are creating friction.
In practice, the role has drifted. In many organisations, the Scrum Master has become an administrator of ceremonies — ensuring the stand-up happens, the board is updated, the velocity chart is current, the retro actions are logged. The value is measured by process adherence: are the sprints running on time? Are the ceremonies happening? Is the team following the framework?
This isn't what the role was designed for. But it's what the incentive structure produces. When an organisation measures "Agile maturity" by how closely teams follow prescribed practices, the person responsible for that maturity naturally gravitates toward enforcing the practices rather than questioning whether the practices are serving the team.
The Scrum Master who says "maybe this team shouldn't be doing two-week sprints" is challenging the framework they were hired to implement. The Scrum Master who says "these ceremonies aren't adding value" is questioning the rituals they're responsible for facilitating. The Scrum Master who says "this team actually works better with a different approach" is undermining the standardisation that management wanted from the Agile transformation.
The role was designed to be a catalyst for change. The structure has made it a guardian of conformity. Not through malice, but through incentive alignment.
The Certification Economy
It's worth pausing on the economics.
A Certified Scrum Master course typically runs to a four-figure fee for a two-day programme. SAFe certifications cost more. Renewal fees apply. Advanced certifications require additional courses. The market for Agile training, coaching, and consulting is, by any plausible measure, substantial.
None of this is inherently wrong. Professionals in every field invest in credentials. But it creates an ecosystem where a significant number of people have a professional and financial stake in the continued adoption and expansion of these frameworks. When someone with a SAFe Program Consultant certification evaluates whether an organisation needs SAFe, the answer is structurally predictable.
This is the same self-validating loop that exists in enterprise architecture. The methodology is promoted by the people certified in the methodology, evaluated by the people trained in the methodology, and measured by the metrics the methodology defines. At no point does an independent voice enter with the authority to ask: is this framework actually producing better outcomes than what it replaced?
The uncomfortable answer is that in many cases, the answer is unclear. Because the metrics being used — velocity, sprint completion rate, ceremony compliance — measure adherence to the process, not the value delivered by the process.
When the Team Pushes Back
This brings us back to the original trigger: teams saying their work doesn't fit a fixed sprint.
The standard coaching response is to treat this as a skills gap. The team needs to learn better slicing. Better estimation. Better scope management. The framework isn't the problem — the team's adaptation to the framework is the problem.
Sometimes this is accurate. Work can often be decomposed more effectively than teams initially believe.
But sometimes — and this is the part that rarely gets explored — the team is right. Some work is genuinely exploratory. Root cause analysis on a twenty-year-old system doesn't decompose neatly into two-week increments. Research, investigation, and complex diagnosis have rhythms that are inherently unpredictable. Forcing them into fixed time-boxes doesn't sharpen focus — it creates artificial pressure to produce premature conclusions.
The Agile Manifesto's first principle is "individuals and interactions over processes and tools." When a team of experienced professionals says the process doesn't fit their work, responding with "you need to adapt to the process" is the opposite of agile.
Listening to that feedback, genuinely investigating whether the framework serves the work rather than the other way around, and having the courage to adapt the process to the people — that's agile. Everything else is methodology compliance wearing agile clothing.
The Conditions That Recover the Original Values
The organisations that recover the original values, when they do, tend to share three structural properties. They measure outcomes rather than ceremonies — asking what the work delivered rather than whether the rituals were performed. They treat team resistance as diagnostic data rather than a problem to overcome — recognising that when experienced professionals say a framework doesn't fit their work, the objection contains information. And they allow the framework itself, not merely execution within it, to be questioned. Where these conditions are absent, the methodology survives intact while the value it was meant to deliver quietly erodes.
The Bottom Line
Agile, as a set of values, remains sound. Prioritise people over process. Respond to change. Deliver working results. Collaborate. Reflect. Adapt.
Agile, as an industry, has become something its founders would likely struggle to recognise. A certification economy, a consulting market, a set of prescribed ceremonies, and an orthodoxy where questioning the framework is treated as a failure to understand it.
The irony is precise and painful: a methodology born from the rejection of rigid process has become one of the most rigidly enforced processes in modern enterprise. And the people most qualified to point this out — the experienced professionals doing the actual work — are told that their resistance is a misconception that needs coaching.
Perhaps. Or perhaps they're the ones still listening to the original manifesto — the part that says individuals and interactions over processes and tools.
The question worth sitting with is simple: are we still being agile, or are we just doing Agile™?