SAFe doesn’t kill agility. Bad leadership behavior using SAFe language kills agility.

SAFe, AI, and the Myth of the 12-Week Waterfall

Why PI Planning Can Complement Agility When It Is Used the Right Way

Real talk: SAFe gets criticized for a reason.

I have seen organizations take a Lean-Agile framework and turn it into a delivery theater machine. They run PI Planning, fill every team to 100% capacity, create dependency boards that look impressive, assign business value scores, and then treat the plan like a fixed contract for the next 8 to 12 weeks.

That is not agility.

That is waterfall with better branding.

So when people say, “SAFe is too rigid,” I do not immediately dismiss the criticism. In some organizations, they are right. SAFe can be misused. PI Planning can become output-focused. PI Objectives can become feature commitments. Leadership can use the cadence to create false certainty instead of better transparency.

But here is where I think the criticism often misses the mark: the problem is usually not the existence of a PI cadence. The problem is how leaders, product managers, architects, coaches, and teams behave inside that cadence.

SAFe defines PI Planning as a cadence-based event that aligns Agile Release Train teams and stakeholders around a shared mission and vision. It typically occurs every 8 to 12 weeks and results in PI Objectives and a plan for the upcoming Planning Interval. That matters because the intent is alignment around objectives, dependencies, risks, and value—not blind adherence to a frozen backlog.

The real question is not, “Does SAFe have a planning horizon?”

Every Agile framework has some form of planning horizon.

The better question is, “Are we using the planning horizon to enable learning, or are we using it to suppress learning?”

The Myth: “SAFe Is Bad for Agility, Especially for AI”

The newer version of the criticism sounds like this:

“SAFe may have worked for traditional software, but it is completely wrong for AI. AI initiatives have rapid learning cycles. You cannot plan 8 to 12 weeks of AI work because the model, data, architecture, prompt strategy, evaluation method, or business assumption may change in days.”

There is truth in that statement.

AI work is full of uncertainty. Data quality may be worse than expected. A model may perform well in a lab and fail in the real operating environment. A retrieval strategy may look promising until users ask messy real-world questions. A generative AI assistant may produce impressive demos but struggle with accuracy, governance, security, or trust.

AI requires fast feedback, rapid experimentation, continuous evaluation, and disciplined learning.

But none of that means an enterprise should avoid alignment.

In fact, the more uncertain the work, the more important it becomes to align on the right things.

The mistake is trying to align around fixed outputs.

The better move is to align around durable objectives, learning goals, risk reduction, and measurable outcomes.

PI Planning Is Not Supposed to Be a Scope Prison

A PI is not supposed to mean, “Here are all the features we promise to deliver no matter what we learn.”

A PI should mean:

“For the next planning horizon, here are the business and technical outcomes we believe matter most. Here are the assumptions we need to test. Here are the dependencies we need to manage. Here are the risks we need to make visible. Here is how we will inspect progress and adapt as evidence emerges.”

That is a very different mindset.

In practical enterprise agility, the PI cadence creates a container. Inside that container, teams may still use Scrum, Kanban, flow-based delivery, spikes, experiments, prototypes, model evaluations, technical enablement, DevOps, MLOps, and continuous discovery.

The PI does not replace learning cycles. It should organize them.

SAFe’s own Lean-Agile principles emphasize cadence and synchronization as mechanisms for operating in the presence of development uncertainty. They also emphasize decentralized decision-making to reduce delays, improve flow, and enable faster feedback from those closest to the work.

That is critical for AI.

AI teams do not need executives approving every prompt adjustment, model comparison, embedding strategy, or evaluation tweak. But they do need alignment on the business problem, acceptable risk, success measures, governance boundaries, integration dependencies, and funding priorities.

That is where a PI cadence can help.

Objectives Are More Stable Than Outputs

This is the distinction I believe leaders need to understand:

Outputs are things we build.

Objectives are outcomes we are trying to achieve.

Outputs may include a model, dashboard, API, chatbot, workflow, feature, report, automation, data pipeline, or integration.

Objectives describe the business result, learning outcome, capability improvement, or risk reduction we are pursuing.

In high-uncertainty work, the exact output may change quickly. The objective is usually more durable.

For example, this is a weak AI PI Objective:

“Deliver chatbot v2 with 12 predefined features.”

That is output-driven. It assumes we already know the right answer.

A stronger PI Objective would be:

“Improve customer self-service resolution for the top account-support intents by validating model accuracy, response quality, escalation thresholds, and operational readiness.”

That objective gives direction without pretending we know every detail upfront. It creates room for discovery. Maybe the team improves retrieval quality. Maybe they adjust escalation logic. Maybe they find that three intents are safe for automation and two require human-in-the-loop review. The output can change while the objective remains useful.

Another weak PI Objective:

“Build the fraud detection model.”

A stronger PI Objective:

“Reduce fraud investigation latency by testing three model approaches, validating data quality assumptions, and deploying the highest-performing candidate behind a controlled evaluation pipeline.”

That is much more Agile. It makes learning explicit. It supports experimentation. It also gives stakeholders something meaningful to inspect.

This is how I coach teams: outcomes first, framework second.

If the PI Objectives are just renamed feature commitments, do not blame agility when the process becomes brittle. The operating model is telling people to chase output instead of learning.

This Is Not Fundamentally Different From Scrum

Some critics act like SAFe invented the idea of planning beyond the current day or current sprint.

It did not.

Scrum has a Product Goal. Scrum has a Sprint Goal. Scrum has Sprint Planning. Scrum creates a Sprint Backlog. Scrum also expects teams to inspect and adapt based on what they learn.

The Scrum Guide says Scrum is founded on empiricism and lean thinking, and that Scrum’s events provide cadence for inspection and adaptation. It also states that Scrum Teams adapt the moment they learn anything new through inspection.

That is the key.

The existence of a goal does not make Scrum anti-Agile.

The existence of a PI Objective does not make SAFe anti-Agile.

A Product Goal provides direction. A Sprint Goal provides focus. A PI Objective provides alignment across multiple teams.

Different time horizons. Same basic leadership challenge.

Do we use the goal to create focus and transparency?

Or do we weaponize the goal to punish teams for learning?

That is the difference.

The Agile Manifesto values responding to change over following a plan. It does not say, “Do not plan.” It says we value the ability to respond to change more than rigidly following a plan when reality tells us the plan is wrong.

The Agile principles also call for frequent delivery, welcoming changing requirements, close collaboration between business and developers, sustainable pace, technical excellence, simplicity, and regular reflection and adjustment.

Those principles are completely compatible with a PI cadence when the cadence is used to improve alignment, feedback, and decision-making.

They are not compatible with using PI Planning to lock teams into a 12-week batch of predetermined output.

AI Needs Faster Learning Loops, Not Less Alignment

AI initiatives often require several learning loops inside a single PI:

• Data exploration and data quality validation

• Prompt testing and evaluation

• Model comparison

• Human-in-the-loop review

• Bias, fairness, privacy, and security assessment

• MLOps or LLMOps pipeline work

• Integration with existing systems

• User feedback and workflow validation

• Cost, latency, reliability, and scalability testing

• Governance and compliance review

That work may move in days or weeks, not quarters.

But enterprise AI does not happen in a vacuum.

AI initiatives usually touch legal, risk, security, architecture, data governance, operations, product, finance, customer experience, and executive strategy. The team may be learning quickly, but the organization still has to make coordinated decisions.

That is why I do not see PI Planning as the enemy of AI agility.

I see poor PI Planning as the enemy.

A healthy PI cadence gives AI teams a way to answer practical questions:

What business problem are we solving?

What assumptions are riskiest?

What data do we need?

What model or architecture options are we testing?

What does “good enough” mean?

What human review is required?

What risks are acceptable?

What dependencies could slow us down?

What decisions need to be decentralized?

What evidence will tell us to continue, pivot, or stop?

NIST’s AI Risk Management Framework reinforces the need to manage AI risk across design, development, use, and evaluation, with trustworthiness considerations built into the AI lifecycle. NIST’s related AI Resource Center also emphasizes measurement, monitoring, and managing AI risks and system performance over time. That sounds a lot more like continuous learning than big-bang delivery.

And that is the point.

AI teams need fast cycles. Enterprises need aligned cycles. Good agility gives you both.

System Demos Should Expose Reality, Not Hide It

One of the most underused aspects of SAFe is the System Demo.

When done well, the System Demo is not a status meeting. It is not a slide presentation. It is not a celebration of tasks completed.

It is an objective inspection point.

SAFe describes the System Demo as an integrated view of new features delivered by teams on the ART, providing an objective measure of progress and a feedback opportunity against PI goals.

For AI work, this is powerful.

A good AI System Demo might show:

• The model’s actual performance against evaluation criteria

• Where the model fails

• What changed after user feedback

• How the system handles edge cases

• Whether response quality improved

• Whether latency or cost is acceptable

• Whether human escalation works

• Whether the solution is ready for broader exposure

• What risks still need to be managed

That is not bureaucracy.

That is transparency.

In AI, leaders should not ask, “Are we on track with the original feature list?”

They should ask, “What have we learned, what evidence do we have, and what decision should we make next?”

That is enterprise agility.

When Objectives Become Obsolete, Replanning Is Not Failure

Sometimes an objective becomes invalid.

That can happen because the market changes, a regulatory concern emerges, data quality is not sufficient, customers reject the concept, the model performs poorly, or another solution becomes more valuable.

When that happens, replanning is not failure.

Replanning is the Agile response.

The failure is continuing to fund, staff, and report against an objective everyone knows is no longer valid.

In a healthy ART, teams should not wait until the end of the PI to surface reality. Iteration

Planning, backlog refinement, PO/PM sync, ART sync, System Demos, stakeholder feedback, and Inspect & Adapt all create opportunities to adjust.

The PI cadence is not supposed to prevent change.

It is supposed to make change visible, intentional, and economically informed.

Practical Guidance: Better PI Objectives for AI Work

Here are a few patterns I would coach teams to use.

Weak Objective

“Deploy the AI assistant to production.”

Stronger Objective

“Validate whether the AI assistant can safely resolve the top five support intents with acceptable accuracy, escalation handling, latency, and customer satisfaction before expanding production usage.”

Why it is better: it focuses on safety, quality, learning, and controlled expansion—not just deployment.

Weak Objective

“Build a predictive analytics dashboard.”

Stronger Objective

“Improve operational decision-making by validating whether predictive signals can identify high-risk service delays at least one week earlier than the current reporting process.”

Why it is better: it connects the analytics work to a decision and a measurable improvement.

Weak Objective

“Complete the model training pipeline.”

Stronger Objective

“Reduce model experimentation cycle time by establishing a repeatable training, evaluation, and deployment pipeline with documented quality gates and baseline performance metrics.”

Why it is better: it treats platform capability as an enabler of faster learning.

Weak Objective

“Integrate GenAI into the claims process.”

Stronger Objective

“Reduce claims intake friction by testing GenAI-assisted summarization with adjusters, measuring accuracy, review time, exception rates, and trust before scaling to additional claim types.”

Why it is better: it starts with a bounded use case and measurable evidence.

Weak Objective

“Deliver all committed AI features by the end of the PI.”

Stronger Objective

“Demonstrate measurable progress toward the target customer outcome by validating the highest-risk assumptions first and adapting scope based on evidence from users, data, and system performance.”

Why it is better: it makes agility explicit.

What Leaders Should Stop Doing

If you want PI Planning to support agility, especially in AI, stop doing these things:

Stop treating PI Objectives as fixed scope commitments.

Stop filling every team to 100% capacity.

Stop measuring success by story count, feature count, or whether every planned item was completed.

Stop punishing teams for surfacing new information.

Stop pretending uncertainty can be eliminated through more detailed planning.

Stop using SAFe language to preserve command-and-control behavior.

That last one is important.

Agile did not fail because teams forgot how to do ceremonies. Agile fails when leadership, funding, governance, architecture, and execution remain disconnected.

That is the real enterprise problem SAFe is trying to solve.

What Leaders Should Do Instead

Use PI Planning to create alignment around outcomes.

Write PI Objectives as business outcomes, learning outcomes, technical enablement outcomes, and risk-reduction outcomes.

Make assumptions visible.

Create space for spikes, experiments, and discovery work.

Use System Demos to inspect real evidence.

Decentralize decisions where the people closest to the work have the best information.

Replan when evidence tells you the plan is wrong.

Measure flow, learning, predictability, quality, customer impact, and decision cycle time—

not just output.

That is how a PI cadence can complement agility.

The Bottom Line

SAFe is not magic. Scrum is not magic. Kanban is not magic. AI is not magic.

The behavior system matters more than the framework label.

A PI cadence does not prevent agility. Treating the PI plan like a fixed contract prevents agility.

When PI Objectives are outcome-oriented, evidence-driven, and continuously inspected, the PI cadence can strengthen agility by giving fast-moving teams the alignment, visibility, and decision-making structure they need to learn quickly without creating organizational chaos.

That is especially true for AI.

AI needs fast learning cycles.

Enterprises need coordinated learning cycles.

The best Lean-Agile organizations do both.