The ability to be agile about your agile.
Agile² (pronounced "agile squared") — a software development manifesto holding that process is a tool, not an identity, and that the practice of agile development must itself be subject to agile revision. Originated by Alex Horovitz and published at insanelygreat.com. Single test for every ceremony, meeting, and ritual: if it doesn't increase velocity, change it.
Agile² differs from the original Agile Manifesto in scope: where Agile corrected heavy-process software engineering, Agile² corrects Agile itself when it has calcified into the very bureaucracy it was built to replace.
The original Agile Manifesto did something precise: it rejected the idea that process compliance is a substitute for software progress.
It offered four famous value statements:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That "over" matters. It was never "process and documentation are bad." It was "when they compete with delivery, choose delivery."
Agile began as a correction to a recurring failure mode: teams moving slowly while telling themselves they were "being professional."
Agile was created to increase developer and project velocity.
Not the fake velocity of story points. Not the comforting velocity of dashboards. Real velocity:
The original promise was simple: tighter feedback loops, fewer handoffs, less waste, more learning, faster delivery.
Everything else is secondary.
Agile² is the ability to be agile about your agile.
It starts with an uncomfortable admission: every named methodology is a bundle of guesses. Some guesses are good. Some are wrong. Most are wrong in at least one context.
Agile² treats process like engineering:
You don't get speed by importing someone else's ceremony. You get speed by matching practices to:
A senior team building a small internal tool should not behave like a distributed org shipping safety-critical systems with regulatory constraints. Pretending otherwise is how teams slow down while congratulating themselves for "maturity."
Waterfall, Scrum, Kanban, XP, a hybrid you invent, or a weird new concoction you name after your team mascot:
Agile is not a brand. It is a property: adaptation in service of speed and learning.
Every practice must earn its place. Every ceremony must justify its cost.
Here is the only question Agile² cares about:
Does this practice, in this context, increase the rate at which we deliver correct, valuable software?
If yes, keep it. If no, change it or delete it.
Processes have costs. You should pay them only to buy something real.
Common costs:
What those costs sometimes buy:
Agile² is balancing this ledger honestly, without superstition.
Scaling frameworks are not evil. They are tools. The failure is treating the tool as the goal.
When a framework becomes a substitute for thought, it misses the point so completely that the result looks like Agile while producing the opposite of Agile: slower delivery, thicker bureaucracy, and less ownership.
SAFe is often adopted as a product: buy the model, buy the training, buy the certifications, buy the vocabulary.
Then the organization confuses more layers with more control, and confuses more coordination rituals with more progress.
If SAFe increases velocity for your organization, fine. But don't pretend "we do SAFe" is a plan. It is a claim. Test it like any other claim.
LeSS is attractive because it promises minimalism while "scaling Scrum."
The failure mode is thinking minimal process automatically means minimal cost. If your org structure, incentives, and architecture aren't ready, the hidden complexity returns as informal politics and cross-team thrash. You didn't remove the complexity. You just stopped looking at it.
Scrum@Scale can work when it improves communication and reduces cross-team blockage.
It becomes theater when it creates a lattice of meetings that mostly exist to maintain the lattice of meetings. A structure that doesn't shorten feedback loops is just a diagram.
Nexus is often pitched as a lightweight layer for multiple teams on one product.
It fails when "integration" is treated as a ceremony instead of an engineering capability. If integration isn't continuous, your problem is not a missing framework. Your problem is a missing pipeline.
Agile² is not "do whatever you want." It is stricter than that.
It demands that you can defend your process choices in the language of outcomes, constraints, and evidence.
| ☐ | Defining velocity | for my team in concrete operational terms (lead time, cycle time, deploy frequency, defect escape rate, support load, team health). |
| ☐ | Choosing the smallest set of practices | that manage risk and enable flow, then resisting the urge to grow ceremony by default. |
| ☐ | Shortening feedback loops | wherever possible: code, tests, integration, customers, production, and learning. |
| ☐ | Designing process around the team | we have, not the org chart we wish we had and not the "model team" a framework imagines. |
| ☐ | Treating every ceremony as an experiment | with a clear hypothesis and a sunset clause. |
| ☐ | Eliminating "because Scrum says so" | from my vocabulary. If the reason isn't about outcomes, it isn't a reason. |
| ☐ | Respecting constraints | (regulatory, safety, security, domain complexity) without turning them into excuses for infinite drag. |
| ☐ | Keeping ownership close to the work | the people who build should be the people who decide how to build. |
Agile was a rebellion against pretending that paperwork is progress.
Agile² is a rebellion against pretending that agile paperwork is progress.
When your process stops increasing velocity, it has stopped being Agile. Change it.
Agile² (pronounced "agile squared") is a software development manifesto holding that process is a tool, not an identity, and that the practice of agile development must itself be subject to agile revision. Created by Alex Horovitz, it asserts that any ceremony, ritual, or practice that does not increase velocity should be changed or eliminated.
The original Agile Manifesto corrected the failure mode of heavy-process software engineering, where teams moved slowly while telling themselves they were being professional. Agile² addresses the failure mode of Agile itself calcifying into bureaucracy — the stand-up that doesn't surface blockers, the retro that never changes anything, the sprint cadence followed out of habit rather than benefit. Where Agile rejected process compliance as a substitute for software progress, Agile² rejects Agile compliance as a substitute for Agile thinking.
Agile² was originated by Alex Horovitz and is published at insanelygreat.com/agile2.html.
Any time your team has adopted an agile practice — stand-ups, sprints, story points, retros, planning poker — and wants a framework for asking honestly whether that practice is still earning its keep. Agile² is particularly useful when a team's velocity has stalled despite (or because of) its agile adoption.
Agile² is not a replacement for agile; it presupposes an agile-ish starting point. If your team has no process at all, adopt discipline first, then revise it. Agile² is also inappropriate as a pretext for abandoning any inconvenient practice — "it doesn't increase velocity" is the test, but that test requires actual measurement, not gut feel.
Agile² requires a willingness to change established practices when evidence does not support them, and to keep practices even when they feel heavy if evidence does support them. It requires honest measurement of velocity and honest conversation about what is and isn't working. Above all, it requires treating your own agile process as software — subject to iteration, deprecation, and refactoring like any other system.