Corporate Agile assumes engineers are not smart enough to figure out what their internal customers want. The work gets atomized into “user stories” and “iterations” that strip any sense of accomplishment, any hope of setting a long-term vision. The result is one mindless, near-sighted sprint after another — no progress, no improvement, just ticket after ticket after ticket.
Simple Picture
Imagine a novelist forced to justify every paragraph to a committee of non-writers every two weeks. The committee cannot evaluate prose quality, so they measure page count, completion velocity, and adherence to the outline. The novelist stops writing for beauty and starts writing for metrics. The book ships on time. It is garbage. Everyone declares the process a success because the process was followed.
Violent Transparency
Open-plan offices are the most visible symptom. VC-backed startups that needed to manage up into investors used them to make workspaces look busy. But the deeper form is process-level: Agile systems demand that programmers provide humiliating visibility into their time and work, with no reciprocity. The business side sees everything the engineer does. The engineer sees nothing of the business decisions that determine what they work on.
This is legibility as power in its purest organizational form. The engineer is made maximally visible to whoever sits above the system. The people above remain invisible. Every act of mapping is an act of enclosure — and violent transparency encloses the engineer’s entire working life in a dashboard that someone else reads.
Creative people lose their creativity when asked to explain themselves while they are working. The inner game is precise about why: Self 2 does its best work when Self 1’s interference subsides. Demanding real-time justification for creative work is demanding that Self 1 supervise Self 2 at all times — which is exactly the condition under which Self 2 stops functioning. The play framework maps: distraction is your subconscious voting with its feet when it doubts the meaningfulness of the journey. Agile does not fix distraction — it institutionalizes it.
The violent transparency culture is designed for the most status-insensitive people: young, privileged males who have not been tested or burned at work. Older people, women, racial minorities, and people with disabilities tend to be status-sensitive in the workplace because it is a matter of survival. One-sided transparency hits them hardest — not because they are less capable but because the cost of visibility is structurally higher when your position is already precarious.
Terminal Juniority
The two-week sprint has no exit strategy. There is no “we won’t need this once we achieve X” clause. The process is permanent, regardless of seniority or demonstrated competence. This is the organizational equivalent of telling a senior surgeon they must justify each incision to an administrator in real time — forever.
Projects that programmers want to take on once they master the basics — architectural improvements, long-term technical investments, exploratory research — are ignored because they are annoying to justify in terms of short-term business value. The Theory of Constraints explains the mechanism: estimates push people toward doing work that is estimable, which means low-yield, easy, and predictable. Anything worth doing has too many unknown unknowns for estimates to be useful. Agile’s focus on short-term value pushes people away from work the company actually needs, in favor of each programmer’s real-time reputation management. This is Goodhart’s Law at the team level: velocity becomes the target, and the moment it does, it stops measuring productive output and starts measuring ticket-gaming.
The Expert Beginner thrives in this environment. Terminal juniority means nobody is expected to develop past the Advanced Beginner stage. The system rewards ticket throughput, not depth. Technical debt piles up because the business people calling the shots do not see the problem until it is far too late — or at least too expensive to fix.
The Five Structural Flaws
1. Business-driven engineering. Like a failed communist state that equalizes by spreading poverty, Scrum puts all of engineering at the same low level — below the business people who decide what gets worked on. When people sense all important decisions have been made elsewhere, they are not motivated to do their best work. The Gervais Principle frames this precisely: the engineers are placed in the Loser position — aware of the bad economic bargain, stripped of meaningful agency, told to stay busy.
2. Terminal juniority. No distinction between a first-year programmer and a fifteen-year veteran. Both get “user stories.” Both attend the same standups. Both are measured by the same velocity metrics. This is manufactured scarcity applied to career meaning — the system cannot afford to acknowledge that some people have outgrown it.
3. Dangerous short-termism. Aggressive project management makes sense in an emergency. It does not make sense as a permanent arrangement. Under Agile, every sprint is treated as an emergency. The OSS sabotage manual’s instruction — “hold conferences when there is more critical work to be done” — describes the daily standup perfectly.
4. No career coherency. Saying “I was on a Scrum team” communicates that you were seen as interchangeable. The mask-daemon dynamic applies: the engineer’s professional persona (the mask) must be constantly performing compliance, while the daemon — their actual technical ambitions and creative drive — accumulates unaddressed underneath.
5. False positive identification. Scrum is sold as “removing impediments” — a nice way of saying “spotting slackers.” The problem is that it creates more underperformers than it roots out. People know who the underperformers are. The reason they persist is that no one does anything about them — a people-level management problem, not a workflow-level process problem. The feedback pipe is the right frame: the process cannot substitute for the managerial courage to have a direct conversation.
Dimwit / Midwit / Better Take
The dimwit take is “Agile is great — it keeps teams accountable and ships product.”
The midwit take is “Agile is fine in theory but bad in practice — teams just need to implement it correctly.”
The better take is that corporate Agile is not a methodology failure but a power arrangement disguised as a process. It gives the business side total visibility into engineering while giving engineering no real power. It replaces ownership with compliance. It atomizes work so that no individual can claim credit for anything meaningful. The consulting context where Agile originated — high-risk client projects with existential stakes — genuinely benefits from aggressive short-term iteration. Transplanting that emergency posture into a permanent arrangement for product development is like running a hospital in triage mode every day. Everyone is busy. Nobody is healing.
Main Payoff
The truth about Scrum is that it does not make engineering faster or better. There is no evidence for that claim. What it does is make engineering legible — visible, measurable, and controllable by people who do not understand the work. The trade is autonomy for legibility, and the people making that trade are not the ones paying the cost. The engineers pay in creativity, career coherency, and the slow death of any ambition beyond the next sprint.
peopleware stated the same thesis a generation earlier: a Methodology is an attempt to centralize thinking, implicitly declaring that people are not smart enough to think for themselves. If people did exactly what the Methodology said, process would grind to a halt — which is why malicious compliance is always lurking one frustration away.
The fix is not a better process. The fix is the same one that recurs across the garden: trust. Trust that engineers can figure out what needs to be done. Trust that creative people need slack, autonomy, and the freedom to look unproductive while producing the work that matters most. Trust that the bottleneck is rarely engineering effort and almost always the soft constraints — the policies, the standups, the estimates, the tickets — that consume the constraint’s capacity while appearing to manage it.
References:
- Michael O. Church, Why Agile and Especially Scrum Are Terrible