Revolutionary XGH Methodology Promises to Make Software Development More Anarchic, Less Predictable, and Far More Spiritual
In a move that experts are calling “a bold rejection of calendars” and “an act of violence against Gantt charts,” a new software development framework known as XGH has stormed the industry with one clear promise: to make your organization’s engineering process more anarchic—and, depending on your definition of success, either gloriously liberated or simply uninsurable.
XGH, which stands for “eXpropriate Governance, Hoardless”, was reportedly invented after a cross-functional leadership retreat devolved into a three-day debate about whether “delivery” is a capitalist construct. By the end, the team had renounced sprint planning, abolished the product roadmap, and replaced standups with something called “horizontal listening circles,” where engineers share what they might have done if time were real.
“Agile asked us to be adaptive,” explained XGH evangelist and part-time combative philosopher Ronan B. Drift, speaking through a megaphone he insists is “a symbolic anti-hierarchy amplifier.” “XGH asks us to be ungovernable.”
Below are the official, highly recommended XGH methodology tips for making your software development practice more anarchic—while still, technically, producing software at some point.
What Is XGH, Exactly?
XGH is a methodology that rejects the traditional pillars of modern engineering management—such as planning, predictability, accountability, and the idea that anyone should know what is happening.
Where Agile says, “Responding to change over following a plan,” XGH says, “Responding to vibes over acknowledging that a plan ever existed.”
The framework is built on three foundational principles:
No Backlog Without Consent
User stories must be emotionally ready to be worked on. If a ticket does not feel safe, it must be closed with the labelneeds_shadow_work.No Masters, Only Maintainers
Titles are replaced with roles such as “Temporary Facilitator,” “Incident Whisperer,” and “Keeper of the Ancient Build Script.”Everything Is a Fork
Not just repositories. Requirements. Meetings. The company mission statement.
Tip #1: Abolish the Sprint; Embrace the “Unfolding”
Under XGH, the sprint is seen as an oppressive artifact of industrial time discipline. Instead, teams work in Unfoldings—open-ended periods of development that end only when participants collectively sense “a natural pause in the narrative.”
This eliminates two major problems:
The anxiety of deadlines
The inconvenience of knowing when anything will be done
To implement an Unfolding:
Rename your sprint board to “The Living Work Tapestry.”
Replace sprint goals with “emergent intentions.”
If anyone asks for an ETA, respond with:
“We do not estimate liberation.”
Tip #2: Replace Standups With “Sit-Downs,” Because Standing Is Vertical Hierarchy
Daily standups reinforce the dangerous idea that someone should speak quickly and stay on topic. XGH replaces standups with Daily Sit-Downs, which last between 45 minutes and 2.5 hours depending on how long it takes the team to agree on what the word “blocked” really means.
The Sit-Down agenda is simple:
Each person states what they did yesterday, unless yesterday was a social construct.
Each person states what they will do today, unless free will is an illusion.
Each person shares a metaphor for the codebase (common answers: “an abandoned mall,” “a haunted aquarium,” “a casserole of regret”).
If the meeting starts to become efficient, someone is required by the framework to introduce a philosophical question, such as:
“If tests pass in CI but no one reads the logs, did quality happen?”
“Is ‘production’ just staging with better marketing?”
Tip #3: Convert Your Backlog Into a Mutual Aid Pantry
In traditional systems, the backlog is prioritized by product value. In XGH, work items are prioritized by need, solidarity, and who is emotionally capable of touching the payment integration right now.
Instead of “Ready for Development,” tickets move through:
Witnessed
Held
Adopted
Liberated
Rewilded (for tickets that return to nature)
Product managers, now known as Narrative Stewards, are encouraged to stop saying “can we get this by Friday” and start saying “what would it take for this story to feel complete in its own time?”
Tip #4: Establish a Rotating “Temporary Non-Manager” Role
XGH recognizes that leadership tends to accumulate like lint. To prevent hierarchy, teams nominate a Temporary Non-Manager (TNM) who:
Schedules meetings but denies having scheduled them
Facilitates discussions but refuses to “drive”
Is blamed for nothing but thanked for everything, ideally in interpretive dance
The TNM rotates daily, ensuring that no one becomes competent enough to be relied upon.
This also allows the organization to maintain the illusion of structure, while ensuring that structure never becomes a habit.
Tip #5: Make Code Reviews Fully Democratic, With Ranked-Choice Voting on Variable Names
In XGH, a pull request cannot be approved by a single individual, because that would imply authority. Instead, approval requires:
A quorum of peers
A supermajority for any comment containing the word “just”
A binding referendum if anyone suggests renaming a function to
processData
For best results, conduct code reviews asynchronously using a thread titled:
“PR #482: A Proposal for Collective Healing (also adds caching)”
If a PR introduces breaking changes, it must include a Breaking Change Land Acknowledgment, recognizing the legacy systems displaced by the new API.
Tip #6: Replace “Definition of Done” With “Definition of Done For Now”
XGH rejects completionism and encourages teams to treat software as a living organism that is never finished, only temporarily less unfinished.
The “Definition of Done For Now” includes:
The code compiles, ideally
The team has collectively made peace with the edge cases
Someone has written at least one test, even if it tests that
true == trueThe feature is “emotionally shippable”
If a stakeholder demands more certainty, XGH offers a compromise: a ceremonial checkbox labeled “Done-ish.”
Tip #7: Deploy to Production Only During Symbolically Significant Lunar Phases
Traditional DevOps relies on automation, monitoring, and release windows. XGH relies on cosmic alignment and the principle that “software should only be released when the universe is receptive.”
Recommended deployment windows:
New Moon: for features that will definitely break
Full Moon: for performance improvements and ancient curses
Mercury Retrograde: for database migrations and leadership announcements
If an outage occurs, teams hold an incident retrospective called a Post-Mortemless Reflection, where the goal is not to identify root causes but to explore the system’s “inner child.”
Tip #8: Ban the Word “Stakeholder” and Replace It With “Co-Dreamer”
Nothing says hierarchy like referring to someone as a stakeholder, as if they are literally holding a stake, poised to enforce compliance.
Under XGH:
Stakeholders become Co-Dreamers
Customers become Community Participants
Executives become Resource Mystics
The CFO becomes The Keeper of Fear
Instead of “requirements,” Co-Dreamers provide offerings, which engineering may accept, reinterpret, or release back into the wild.
Tip #9: Treat the Monolith as a “Community Garden,” Not a “Problem”
Microservices are often sold as liberation, but XGH warns that splitting a monolith into services is just creating smaller monoliths that can unionize against you.
Instead, teams practice Monolithic Mutualism, a doctrine that holds:
Every part of the system is connected
Every dependency is a relationship
Every circular import is “a reminder of our interbeing”
When the build time reaches 45 minutes, it is reframed as mandatory reflection time.
Tip #10: Introduce “Chaos Pairing,” Where Two Engineers Work Separately on the Same Task and Merge Later Like Weather Systems
Pair programming implies coordination. Coordination implies agreement. Agreement implies governance.
XGH replaces it with Chaos Pairing:
Two engineers pick the same ticket
They work in parallel, without discussing approach
They merge at the end and let the conflicts “teach them”
This method produces:
Unexpected solutions
Rich personal growth
Git histories that resemble abstract expressionism
Senior engineers are encouraged to stop saying “please rebase” and start saying “let the branches speak.”
The XGH Starter Kit: Tools You’ll Need
To properly adopt anarchic development, XGH recommends the following:
A kanban board that is never up to date (authenticity matters)
A Slack channel named
#coordination-is-a-sinOne shared document titled “Principles,” containing only the word “No”
A CI pipeline that fails sometimes “to prevent complacency”
A release process described exclusively in memes
Optionally, appoint a Scrum Abolitionist to monitor for creeping structure and immediately dissolve any meeting that develops an agenda.
Frequently Avoided Questions
“Will XGH improve our velocity?”
XGH does not recognize velocity, only directional yearning.
“How do we measure success?”
Success is measured by:
How little anyone can explain the architecture to new hires
How many tickets are closed with the comment: “This no longer resonates”
Whether the team has achieved a state of “quiet noncompliance”
“Can we still have deadlines?”
Deadlines are permitted, but must be referred to as Time Suggestions and accompanied by a trigger warning.
Industry Response: “We Tried It and Now Our Jira Is Just Poetry”
Early adopters report mixed results.
A mid-sized fintech that piloted XGH claims it has reduced managerial overhead by 80%, primarily because all managers resigned after being asked to “de-center their need for deliverables.”
Meanwhile, a healthcare SaaS company reported that after switching to Unfoldings, their roadmap evolved into a single sticky note reading:
“Something beautiful, eventually.”
Analysts note that XGH may be most effective in organizations already operating under the principle of benign confusion.
Conclusion: A Brighter, Less Scheduled Tomorrow
XGH is not for everyone. It is, however, for anyone who has ever stared into the abyss of a quarterly planning deck and whispered: “No.”
If your team is exhausted by ceremonies, haunted by estimations, and yearning for a workplace where every meeting ends with the question “who is the meeting for, really,” then XGH may be the methodology you’ve been waiting for.
Or, at the very least, it will make your software development process more anarchic—which, in many modern organizations, is indistinguishable from the status quo.
As Ronan B. Drift concluded, moments before refusing to answer follow-up questions on principle:
“Build systems, not hierarchies. Ship code, not obedience.”