What Happened to PI Planning in AI-Native SAFe?

In 2014, I wrote a post called Can You Be SAFe Without PI Planning? The EDW Release Train had launched without PIs. We ran rolling wave planning and Unity Day, and when demand finally outstripped supply, we experimented with a PI Planning event. Not the two-day event from the book. My leadership team sat down with Dean Leffingwell's Agile Software Requirements and adapted the agenda to a single day.

The day delivered real value in shared understanding and dependency visibility. It also taught us something awkward: most teams told us their plans had not materially changed as a result of the day. The planning had already happened, continuously, outside the room. So we chose to stick with rolling wave, and my conclusion at the time was that without stakeholders in a room making trade-off decisions, the PI construct wasn't adding value for us.

I remember Dean’s reaction to the blog very clearly. He acknowledged that our approach worked for a stand-alone ART but would struggle when there were dozens or even hundreds of ARTs trying to coordinate at enterprise scale. It was a fair point. Over the years, I have revisited the idea of rolling wave planning. Oddly, every RTE I have suggested it to did not want to give up the forcing function of the two-day PI Planning event, which ensured Product Management had a ready backlog. I never forced the issue, as I always worried that if or when the organisation added ARTs, the lack of cadence-based PI Planning would become a challenge. I had also become a huge advocate of the magic of the tried-and-true two-day PI Planning format. 

When Andrew Sales announced in session four of the AI-Native SAFe series that the two-day PI Planning event is replaced by a one-day PI Outcome Planning event in AI-Native SAFe, I had mixed feelings and a strange sense of déjà vu.

Not a Shorter PI Planning. A Different One.

Let's start with what PI Outcome Planning actually is, because it is not PI Planning compressed. The article states the change plainly: the two-day event "that provided the time and space for the entire ART to create a set of plans" becomes a one-day event "that focuses on in-flight re-alignment". Having read the guidance, my view is that this is a different planning philosophy, not a rename.

Consider what arrives at the event. In Core SAFe, PI Planning consumes an ART backlog that Product Management has prioritised using WSJF. In AI-Native SAFe, Business Owners and ART leadership draft a set of PI outcomes beforehand, informed by the roadmap, the vision, progress on ART outcomes and learnings from Sense and Respond events. The prioritisation call has always been made before the room, in both models. The difference is that Core SAFe names the method for making it, and so far, AI-Native SAFe doesn't.

The draft PI outcomes go to the teams a week before the event, and teams draft their own team outcomes in the days leading up. It looks like an IP iteration in shape, though the article never calls it one. This is the part I keep turning over. We have spent years teaching teams to limit their pre-planning, precisely because teams that arrive with a finished plan won't change it in the room. I've watched that dynamic from the other side: at our one-day event, plans didn't change on the day because rolling wave meant the planning had already happened. Now the guidance asks teams to arrive with drafts. Are we recreating the anti-pattern we spent a decade coaching out? Or does it not matter this time?

Maybe it doesn't. The old anti-patterns were anti-patterns of output planning. Pre-committing hurt the process because teams would anchor to their plan and resist re-planning as it felt like waste. Two days were necessary because negotiating every feature and dependency across an ART takes two days. PI Outcome Planning doesn't plan all the teams' outputs. The day alternates between outcome breakouts, where the teams contributing to a PI outcome converge on how they'll achieve it together, and team breakouts, where each team consolidates its own plan. The teams on the ART are explicitly told not to identify all their outputs. Instead, they identify only what they need to commit to outcomes and milestones, then let the specifics of the work emerge over the PI. In some ways, this seems similar to the Discovery pattern we use to define features ahead of PI Planning. 

On the other hand, it is possible that the anchoring behaviour we saw in teams that pre-planned was never about outputs. Maybe it's about humans defending decisions they made before they walked in, and outcomes will anchor just as hard as features did. The drafting happens team by team, from the same set of draft PI outcomes, so what happens when two teams arrive at an outcome breakout with roughly the same team outcome? Someone will be giving up a position their team formed before the event. That might be exactly the trade-off conversation the breakout exists to host, or it might be the anchoring problem with a new name. I genuinely don't know, and I will be interested to see how this plays out in the gemba. 

What is clear is that, like PI Planning, PI Outcome Planning creates the space to make the trade-off decisions and align teams. The article's worked example shows exactly that: a team surfaces a capacity clash, it goes to Management Review and Problem-Solving as a "decision needed", a pilot gets deferred in the room, and the PI outcome's key results are adjusted to match. The day ends with a confidence vote on the result.

In the meantime, I suspect the nuance of one-day PI Outcome Planning vs the anti-pattern of one-day PI Planning will be lost on many, and the detail that explains the difference lives behind the SAFe Studio paywall. I feel for the many RTEs that are about to be inundated with the message "Scaled Agile says PI Planning can be one day now". When responding to this, I recommend sticking to the facts and posing the question: AI-Native SAFe has a different event called PI Outcome Planning. Are you proposing we move our ART to an AI-Native operating model?

Turning Up the Good with Sense and Respond

The other new event in AI-Native SAFe is Sense and Respond: two hours, every iteration, for the whole ART. It replaces the half-day end-of-PI Inspect and Adapt event and the System Demo each iteration. The first hour senses: progress against PI and team outcomes with updated key results, product demos, workflow improvements and challenges, and customer feedback and metrics. The second hour responds: identifying what needs a response, exploring options, and agreeing decisions and actions with owners.

One part of this is similar to the pattern I have been using since 2013, the end-of-iteration "Bubble Up", where teams surface challenges outside their control in their retros, and delegates bring them to a cross-team session, where sometimes another team has already solved the problem. We have long had a theory that a fortnightly Bubble Up reduces the need for the I&A problem-solving workshop, because problems are raised and addressed as they emerge instead of being stockpiled for the end of the PI. The article seems to agree: it notes that AI-Native ARTs may choose to run the problem-solving portion of Inspect and Adapt periodically.

The more time I spend thinking about Sense and Respond, the more I find myself thinking about Core SAFe. Teams and stakeholders regularly complain about the duplication between the fortnightly System Demo and the PI System Demo, and I've never had a good answer for them. A version of Sense and Respond might be it: one fortnightly event consolidating the demos, the measures and the improvement conversation, doubling down on the two-week cadence, which is where we have always believed learning and improvement live.

Adrienne and I made the case for progressive objective evaluation at the 2022 SAFe Summit: Business Owners at every System Demo, scoring objectives as they complete instead of all at once at Inspect and Adapt. It works when the Business Owners are in the room. Core SAFe has always expected Business Owners at the fortnightly System Demo, but in my experience, that attendance is patchy at best. The end-of-PI System Demo catches what the fortnight misses. AI-Native SAFe removes this safety net.

The way we measure has changed too: Business Value and Actual Value are not mentioned in the new event guidance articles, and ART predictability appears to be gone with them, in favour of key results reviewed at every Sense and Respond. The in-flight measures and trade-offs now live in one fortnightly event, and the ask has grown from an hour to two. Will Business Owners give us two hours a fortnight? I'm not sure they will.

Sense and Respond feels like the rolling wave approach we used at EDW, with one difference: AI-Native SAFe keeps the PI cadence alongside it, and uses it to close the gap Dean called out. Teams sensing and responding independently drift apart, and the divergence compounds; the article says as much. Sense and Respond is the fortnightly correction, and PI Outcome Planning is the periodic re-anchor. On paper, that's rolling wave planning in SAFe with Dean's objection answered.

Meanwhile, in Core SAFe

One more thing from session four, and it might be the most immediately useful. Andrew Sales announced an update to the Customer article, and when I went looking at the change I noticed something he didn't mention: the update was made to the Core SAFe Customer article, with AI-Native SAFe linking through to it. As far as I can tell, that's the first time the two models have been updated in unison. I've written before about how much of the AI-Native SAFe guidance would serve Core SAFe practitioners just as well. This is Scaled Agile doing exactly that, and I'd love to see more of it. You don't need to adopt any of the AI-Native SAFe patterns to benefit from this one.

The new content is more practical but not equivalent. The section with the four-part customer typology is gone, and it is replaced by a customer feedback loop and useful guidance on customer demos, including a simple two-by-two grid to help teams frame the right approach for the right purpose: is the purpose to learn or to persuade, and is the reach small or large? The combination maps to the stage of your product and creates optionality I suspect many teams have never considered. Most default to the same demo format every time.

What's Next

Session five, Building AI-Empowered Products, runs in two weeks. Session six, Adopting AI-Native SAFe, is on 25 August, the same day the AI-Native upgrades go live: free, on-demand, with an expert upgrade for SPCs, ASPCs and SPCTs and a certified member upgrade for anyone holding any SAFe certification, any version. I'm hoping session six also answers the question I keep circling in this series: who is AI-Native SAFe actually for? See you then.