Have We Reached the End of Agile's Primary Benefit? — OODA, Pt. 1

When Agile Isn't Solving the Hard Part Anymore

Agile once solved the biggest risk in software: uncertainty around delivery. But what if that risk has shifted?

If you're using LLMs to develop plans, you've likely seen them generate lists of phases with durations: "Phase 1: 2 days," "Phase 2: 3 days," and so on. But it's obvious now that when you see "10 days" worth of phases, you're often only minutes or hours away from completed code. These inaccurate estimates likely carry over from pre-LLM assumptions, or perhaps they're clever artifacts of reinforcement learning and marketing optimization. Either way, they expose remnants of a bygone model.

I'd argue that one of Agile's most important features was its feedback loop. It helped teams improve their ability to estimate the time it takes to develop features. Estimation used to be the riskiest part of delivering a project. Good estimates meant regular deliveries, which meant more feedback and better plans. It was a decent loop.

But now, the "develop code" part has been short-circuited.

Yes, Agile can be adapted to refocus on earlier phases, like where the dev time now shifts to spec-building. But my gut says the collapse of long dev times means we're no longer solving for the hardest part.

---

What's the Hard Part Now?

One major challenge is the breakneck pace of progress. That sounds like a blessing, and in some ways it is, but it also means your competitors are moving just as fast. Even how we work is evolving rapidly. The volume and quality of educational content and open-source code available today is overwhelming.

There's never enough time to stay current.

A team might try to divide and conquer the flow of new knowledge, but when do we find time to update each other? With every team member accelerated by AI, the amount of actual work (and status) generated per day can be astonishing and hard to synchronize. Everyone's dealing with their own firehose. The world itself is a firehose of change, constantly shifting opportunities and conditions.

It doesn't feel like Agile was designed to optimize for this.

---

Re-Enter OODA

A decision-making model developed by U.S. Air Force Colonel John Boyd in the early 1970s might be. While Boyd created some of the most important ideas in air combat, OODA was primarily a teaching tool at the strategic level. It's designed for action in environments with imperfect information, uncertainty, and constant change.

OODA stands for Observe → Orient → Decide → Act. It's a loop, where Act leads right back into Observe.

Other loops exist, such as PDCA (Plan → Do → Check → Act), and Agile frameworks like Scrum and Kanban have their own cycles. At first glance, OODA doesn't seem all that different. You may have heard that if you iterate through it faster than your opponent, you can "get inside their loop" and win. When you look at the biggest players in AI, it certainly feels like there's a war of decision cycles happening in real time.

But many explanations stop at "faster is better." There's more to it.

• Observe: A continuous process of gathering feedback, both internal and external.
• Orient: The most critical "step," but it's also a continuous process. It creates hypotheses based on updated mental models.
• Decide: Choose a hypothesis to act on.
• Act: Execute or test your hypothesis. Write code, push a change, ship a product.

But it's not a linear process.

• Decide and Act both send feedback back to Observe.
• Orientation constantly shapes how we see the world.
• Sometimes, Orientation leads directly to action, skipping explicit decision-making altogether.

Let's go deeper.

Orientation is the beating heart of the loop. It involves preparing by studying models, doctrines, and heuristics. It also involves breaking them down and recombining them as new observations come in. It's about forming instincts, a trained intuition that influences both how we observe and how we act.

Boyd spent decades teaching OODA. He invoked Gödel's Incompleteness Theorem, Heisenberg's Uncertainty Principle, and even the second law of thermodynamics to explain why we need a continuous, adaptive process. We won't unpack all of that in one blog post, and that's okay.

---

Agile vs. OODA

Agile was designed to be steady but fast, with a heavy focus on introspection and some user feedback to guide product development. It shines in predictable environments with slowly evolving constraints.

OODA, on the other hand, is a decision loop designed to be highly fluid. You can change the pace, skip steps, and act on instinct. It's built for environments where the world refuses to sit still, and increasingly, that's our world.

It feels like the landscape is shifting. OODA might be the better loop for it.

---

Is This Applicable or Actionable?

Agile won't disappear overnight. OODA won't suddenly replace it. OODA has been used for decades in business and litigation, but it's rarely cited in software startups. Some people note that founders who instinctively pivot their startups into winners are OODA-adjacent, even if they've never heard of Boyd.

What I think will happen is this: teams that can respond to rapid change will compound the geometric advantages that Boyd described. It won't be some "official" OODA process, but healthy, adaptive teams that execute well will naturally perform better.

So maybe, for now, OODA is just a mindset, a frame of mind to bring with you to work.

But software process is evolving rapidly. New practices are emerging, and tools to support them will arrive faster than ever.

This is part one of a series. There's more to say.