Agile methodology Gaslighting 101
- Dec 4, 2025
- 4 min read
"We need to be more agile."
This phrase has become a weapon. Not against rigid processes or bureaucratic overhead, but against anyone who dares suggest that maybe, just maybe we should actually plan something before doing it.
Here's how it works: A stakeholder changes their mind for the third time this week about what the product should do. When the team expresses concern about constantly shifting requirements, they're told: "That's not very agile of you. Agile means being flexible and embracing change."
The development team asks for two days to design the architecture before starting implementation. Response: "We don't have time for big upfront design. We're agile; we'll figure it out as we go."
Someone suggests documenting the decisions made in yesterday's planning session. Answer: "Documentation? We're agile. Working software over comprehensive documentation, remember? As long as we get the results the process does not matter"
This isn't Agile, it's a slow burning downfall of effective project planning.
Real Agile embraces changing requirements while maintaining discipline about how changes are incorporated. There are sprint boundaries. There's a product backlog prioritization process. There's a definition of done. Changes don't just happen randomly; they go through refinement and planning.
Gaslighting term refers to the act of convincing oneself or others that their actions/thinking are at fault when in reality that is not the case. Agile Gaslighting uses "being agile" to mean "accept whatever chaos leadership creates, and if you complain, you're the problem."
Real Agile plans iteratively; short planning cycles with frequent adjustment. Agile Gaslighting rejects planning entirely as "not agile," then blames the team when random execution produces random results.
Real Agile values working software over comprehensive documentation, not over all documentation. Agile Gaslighting treats any documentation as bureaucratic waste, then wonders why new team members can't get up to speed and critical decisions get forgotten.
The gaslighting patterns:
Pattern One: Change without consequence Stakeholders change requirements mid-sprint, expecting immediate incorporation without timeline adjustment. When the team pushes back, they're accused of being "inflexible" or "not truly agile."
Reality check: The Agile Manifesto says "responding to change over following a plan." It doesn't say "random changes with no consideration for impact or timing." Even Scrum - the most popular Agile framework works in alignment of the sprint scope. Changes are welcome, but they go in the backlog for the next sprint.
Pattern Two: Planning is bad Any attempt at thoughtful design or upfront analysis gets dismissed as "waterfall thinking." Teams are pressured to start coding immediately because "we'll refactor later" and "we're agile, we'll adapt."
Reality check: Agile emerged from software development, where smart developers realized that some upfront thinking prevents costly mistakes. The Agile Manifesto doesn't say "no planning." It says continuous planning in small increments. The difference matters.
Pattern Three: Process criticism equals resistance to change When team members suggest that the current process isn't working; perhaps retrospectives don't lead to action, or sprint planning takes four hours for a one-week sprint. They're told they're "fighting against agile transformation."
Reality check: Agile explicitly values "inspecting and adapting." Retrospectives exist precisely so teams can criticize and improve their process. If you can't criticize how Agile is being implemented, you're not doing Agile- you're doing dogma.
How to spot Agile Gaslighting:
Ask these questions. If you get defensive responses instead of thoughtful dialogue, you're dealing with gaslighting, not genuine Agile practice:
"How do we handle changes that affect work already in progress this sprint?" "What's our process for deciding which changes are important enough to disrupt current work?" "How much time should we spend on design before implementation?" "What documentation do we need to maintain and why?" "How do we know if our Agile process is working?"
If the answers are all some variation of "trust the process" or "that's not how agile works," warning bells should ring.
The consequences:
Teams operating under Agile Gaslighting burn out. They work in constant chaos, never achieving the sustainable pace that real Agile emphasizes. Quality suffers because thoughtful design gets branded as "not agile." Projects miss deadlines because unmanaged change creates thrash. Meanwhile, leadership points to "agile transformation" as the solution, never recognizing they're implementing chaos and calling it Agile.
You can't call out Agile Gaslighting directly without risking your career. Instead, redirect conversations to specific practices:
Instead of debating whether planning is "agile," ask: "What's the right amount of planning for this specific decision?" Ground the conversation in practical trade-offs, not ideology.
Instead of arguing about documentation, ask: "What information do we need to capture to prevent future problems?" Focus on value, not compliance with Agile principles.
Instead of accepting every change immediately, ask: "What's the impact on current sprint goals? Should this replace something currently planned, or wait for the next sprint?" Force explicit trade-off discussions.
The Real Agile:
Genuine Agile implementation has discipline, structure, and boundaries. It welcomes change within frameworks that prevent chaos. It values planning, just in smaller increments. It reduces documentation to what's valuable, not to zero.
If your "Agile" process feels like chaos filled with constant disruption, no boundaries, no ability to push back on unreasonable demands; you're not experiencing Agile methodology. You're experiencing organizational dysfunction with Agile terminology.
The solution isn't rejecting Agile. It's distinguishing real Agile practices from chaos disguised as flexibility. Know the difference, and you can advocate for one while resisting the other.
Sources:
