The ability to be agile about your agile.
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.