The PI Planning is SAFe's best idea

But it can work so much better

One of the biggest Agile myths is that you can’t and shouldn’t plan beyond a few weeks. What’s more, some Agilists even claim that approaches that ARE looking beyond this short time period are anti-Agile. For these people, the Scaled Agile Framework (SAFe) is the prime example of a fake Agile approach.

This is nonsense. Anyone who’s working on a product or service for multiple months or even years has to plan well ahead. A team that only plans every few weeks for a few weeks is running blind. You need to know if you are on your way to achieving your goals and if you need to adjust your course accordingly.

This doesn’t mean that long-term plans don’t have their pitfalls. On the contrary, there are many serious issues with most long-term plans. They are often too rigid, too output-focused, and considered to be literally correct.

SAFe’s PI (Planning Interval) Planning suffers from similar issues. In essence, I’m in favor of such an event every quarter or perhaps a bit more frequently. But the practical execution of these PI Plannings leaves much to be desired.

In this article, I will discuss the good and the bad of the PI Planning and also point out how to fix the event.

Photo by Anete Lusina

The Good

SAFe 6.0, the framework’s latest version, highlights the importance of organizing around value. It should not be about the delivery teams only. It should involve all the people responsible for the entire value stream to get from idea to value. The Agile Release Train (ART) is an example of organizing around value.

Everyone within the ART is at the PI Planning. I can’t overemphasize how important this is. Value doesn’t come from the software running on hardware alone. It often also involves people working on supporting systems, sales, client support, and others. They all need to be aligned and collaborate to create a valuable product.

I also very much like how the PI Planning starts with an explanation of the business context followed by the product/solution vision. This includes highlighting important milestones. These are vital to bringing focus, alignment, and commitment. A clear sense of purpose and direction allows the teams to make the right decisions to maximize their effectiveness.

There’s a caveat though.

Agile approaches should help teams to learn from what they did and based on these learnings determine what next step brings them fastest to their desired outcome. This is why a product/solution vision should be describing what you wish to achieve in the coming period, including how you can assess if you are heading in the right direction. This gives the teams the opportunity to plan accordingly and adjust the course during a PI, at their Iteration Planning.

The product/solution vision should not be limited to listing and describing the desired features. It should not be about output (only). Delivering features should serve the desired outcome and the impact you wish to make with the product or solution. When a product/solution vision lacks the desired outcome, teams can only focus on building the features, regardless if they bring the desired results.

The PI Planning ends with a retrospective of the event, which always is a good idea. You wish to learn from what you did and if you can improve for the next time. Having a retrospective immediately after the event ensures that people have their impressions freshly in their minds.

The Bad

The issues with the PI Planning creep in when the System Architect presents the architecture vision. This doesn’t have to be a bad thing. As long as it is about the development practices and shared quality rules, this can only help to align the teams. However, I have issues with the idea that a System Architect would dictate this without input from the teams.

What I see as even more problematic is when a System Architect would present an immutable architecture solution. Because that would severely limit the Agile teams to finding their best way forward in a complex product domain.

Any action that limits the teams to deciding upon the best technical solution has a negative impact on agility. This practice may work in a complicated environment, where you need to do an analysis to determine the best way forward. It doesn’t work in complex environments where you need to find the best way by taking small steps, learning, and adapting.

But what I find even worse is that the remaining time of the PI Planning (up to 1.5 days) has the teams planning their work for the coming three months, followed by a review, another planning round, a second review, and then even a final planning round. All of this includes a confidence vote and logging the risks and dependencies.

In three planning steps, the Agile teams determine their expected capacity, define the features to deliver, and identify the backlog items. They create plans for every iteration of the PI. This is all about output, about delivering features.

When the narrative during the planning is about features only, the teams will focus their work on features only. As a result, the entire PI will be about delivering the features according to planning and hoping that teams that depend on each other will be working in sync as planned.

Everything about the planning of the Agile teams during this PI Planning points towards the delivery of predetermined features. It is not about the nature of a complex product environment. It ignores that the features may not be bringing the hoped value and that the product journey is a discovery.

On top of that, the fact that all these teams spend so long creating and optimizing their plans triggers them to be reluctant to abandon them. After all, they put so much time and effort into it. Deviating from the plans would indicate they were wrong. And the time and effort spent on it would be wasted. While this is true, it is difficult to swallow when you believe in the plans in the first place.

The bottom line is that too much time is spent on planning and fixing teams for the coming months. On top of that, the dependencies make it worse because you need to rely on each other and therefore be predictable with what you deliver. How about achieving your desired outcomes? How about actually solving problems for the customers and/or users? Ultimately, these are off the table for months as teams focus on features only.

The Way Forward

The PI Planning is a great opportunity to align the ART on what is important in the coming period. When done well, it brings focus and commitment.

The issue with current-day SAFe is that this PI Planning is so centred around delivering features with multiple teams. It is all about the output, assuming that when they deliver the output, users will be happy. It also restricts the teams from adjusting their plans during the PI because everything is so entangled.

I recommend the following to make the most of the PI Planning:

Align ARTs around the value stream

This is already part of SAFe 6.0 and I wish to emphasize its importance.

Have the entire ART at the PI Planning

This is also already in SAFe 6.0.

Explain the business context

As in SAFe 6.0.

Present the product/solution vision

This is also present in SAFe 6.0, but I would like to pinpoint key elements that I think should be included.

The product/solution vision should include an overarching aspirational goal. Meeting this outcome-oriented goal indicates that the ART has achieved its objectives. Typically, such a goal is big and far away and the ART therefore will be on a journey.

On top of this overarching goal, the product/solution vision should inform the ART where they are on the journey. This includes an assessment of what they have achieved and what they still need to do to meet the overarching goal.

What I also would include is the goal for the coming PI. This PI goal should inform everyone about the desired outcomes of the PI and how they can assess if they are progressing towards the goal. It will be something like “By the end of the PI, we hope to have achieved …. result which we can assess by ….”.

By focusing on the desired outcomes, the Agile teams in the ART have the opportunity to find the best way to reach the desired outcome. Even if it means completely changing the plan. This will require alignment with other teams during the PI which I will also discuss.

I would also include the opportunity to discuss the PI goal with the participants in order to refine it. Feedback is an essential part of an Agile way of working. This includes having a discussion on the PI goal.

Plan the first Iteration

Instead of planning the entire PI, I recommend focusing on the first Iteration instead. I recommend taking the following steps for every Iteration planning of the PI:

• All teams together determine the outcomes they wish to achieve in the next Iteration that bring them closer to the PI goal.

• Every team defines an Iteration goal based on mutually defined outcomes.

• When the Iteration goals are defined, every team creates a plan for the Iteration to create an Increment that would help them reach the Iteration goal.

While you could argue that the first Iteration planning doesn’t have to be part of the PI planning, I can imagine it is because everyone required is already present.

Retrospective

I would keep the retrospective at the end of the event, as is already part of SAFe 6.0.

Conclusion

The PI Planning can be a great opportunity to align on the desired outcomes for the coming months. Sadly, it is often the moment when Agile teams are bound to a highly complicated web of feature delivery plans.

When the ART can change the focus from output only to output serving to achieve an outcome, Agile teams will be empowered to find the optimal path towards the outcome in their complex environment.

Original article April 2023