Steering Your Ship Through PI Planning: Navigate the VUCA Waters with Ease

AGILEBUSINESS AGILITY

Eduardo Alvim

7/6/20246 min read

Hey there! So, let me tell you a little secret. For some years now, I've been awarded the SPCT certification, which stands for SAFe Practice Consultant Trainer. It's like the Oscars of agile certifications – maybe a little bit too pretentious here, but I trust you got me. What's that? Never heard of it? Well, let me share with you some wisdom from Gartner:

“Do not rely on certifications alone as a measure of the skills of a consultant or prospective employee. A notable exception to this is the SAFe Program Consultant Trainer (SPCT) certification, which does require demonstrated experience with agile, software development or product management, training and consulting. If you’re hiring someone who has [an] SPCT certification, you can be confident that they do have experience in these areas, as well as experience with SAFe implementation at multiple organizations.” - Gartner

Now, imagine me as a sort of agile world traveler, zipping around the world, coaching and facilitating PI Plannings like there's no tomorrow. I've done so many of these that I’ve lost count - literally. Big companies, small companies, tech giants, mom-and-pop shops—you name it, I’ve been there.

But let's get real for a second. Sometimes, PI Plannings make me want to pull my hair out (as if I had any still, LOL). Why? Because some folks treat it like a supersized Iteration Planning session. Picture this:

  • The execs talk on and on about Business Context. Graphs and data nobody gets. (Yawn, right?)

  • Product Management blabs about product vision. Do what I tell you to. Ok? (Still yawning?)

  • System Architect mumbles something about architecture vision. (ZZZ…)

Disclaimer: No Business Owners, Product Managers, or System Architects have been harmed during the creation of this small scene.

After these two (or three) hours of blah blah blah, team breakouts begin:

  1. No one remembers a damn thing from the morning presentations.

  2. Teams start cramming work into their iterations.

  3. Dependencies and risks? Oh yes, they find plenty. Mostly lack of capacity or capability.

  4. PI Objectives? Sure, just match features to objectives, call it a day. Who cares? It’s just work to be done, anyway!

Everyone goes home with a confidence vote of 3.x (insert your favorite number here), which is just the comfort zone—not too good, not too bad. Just Meh!

If this sounds familiar, my friend, you might be waterfalling your PI and Iterations. Full of good intentions, but still.

Let’s shake things up a bit and see how Agile and SAFe can truly work for you. Ready for a new perspective? Great! Keep an open mind as we embark on this journey through the wonderful world of agile and scaled agile.

Complicated vs. Complex

To make it simple (pun intended), complicated means you can predict the outcome (if this, then that). Complex? Not so much. Too many variables make it unpredictable. We live in a VUCA world—Volatile, Uncertain, Complex, and Ambiguous. Since the 90s. But some folks throw around VUCA just to sound smart without really getting it.

Complicated environments suit predictable methodologies like waterfall. Complex environments? That's where agile shines. Using the “tool” (to reduce Agile to just a tool) in the wrong environment is like using a hammer for everything—it just doesn't work well. You need to choose your weapons, or tool in this case.

What is a Feature?

A feature is a hypothesis that needs to be proven. Simple as that. Why? Because you want to see some results—business outcomes, they call them. But there's only one way to know if the thing you’re constructing meets expectations: deliver it and get feedback. Up until that point, what you have is just a bunch of hypotheses. Call them this way or not.

Just in case, if you see features as just tasks (work) to be done, you might need a crash course in Agile development or even better Design Thinking.

The ART Backlog and Features/Enabler Features

Your ART Backlog is full of hypotheses (Features/Enabler Features) that you need to validate quickly to solve real customer problems. Welcome to the VUCA world and all its wonders!

My French friends have a saying: "Il faut nommer les vaches", which means "let’s call the cows by their names." So, instead of pretending everything is fixed and known upfront, let’s “nommer ls vaches”: Features are just hypotheses that are in need to be proven or disproved as quick as possible, so we don’t waste money, time, energy, people’s mind and so on. Name your hypotheses, draw the expected outcomes, validate them as quick as possible, or find a new plan based on your learnings and the strategy of the company. Move to the next.

How to Validate Hypotheses?

Here’s the secret sauce (not from Colonel Sanders, though): Acceptance Criteria. When you treat features as hypotheses and not just work to be done, Acceptance Criteria should be defined to help you test the hypothesis, not just check if the feature was implemented correctly. Pivot or persevere with no mercy or guilt, one could say.

The Big Picture: PI Planning Agenda

PI Planning starts with Business Owners sharing the vision for the next six or nine months. Why? To prepare for pivoting or persevering based on market changes and customer needs. It's not just graphs and charts—it's about creating a story that makes sense for everyone and gets everyone around the same intended vision.

Product Management then dives into the product vision, proposing features (hypotheses) to solve customer problems and to address market challenges. System Architects follow, discussing how the architecture needs to evolve to support these hypotheses.

Writing PI Objectives

Write PI Objectives based on what you’ve learned from the morning speeches. These objectives answer the "ASK" from Business Owners. PI Objectives should be the very first thing a team defines.

Start with PI Objectives, then select some starter user stories from your team backlog to help achieve those objectives. Or write others. It doesn’t matter. It’s a VUCA world, you must navigate your way towards the right answer.

The Cherry on Top: Iteration Goals

Enough with forgetting about Iteration Goals. Define Iteration Goals during your Iteration Plannings!

These goals help you move towards PI Objectives. Without Iteration Goals, you’re like Alice in Wonderland—any path will take you somewhere, but not necessarily where you want to go.

Iteration Goals are going to guide the team in selecting the appropriate user stories to move in the same direction as the PI Objectives, then validate the hypotheses, learn and keep on moving. Or change direction.

Daily Standups: Planning, Not Reporting

Transform Daily Stand-ups/Team Sync into planning meetings with these three questions:

  1. What did I do to advance the iteration goals since we last met?

  2. What will I do until we meet again, to advance the iteration goals?

  3. Any blockers or issues?

Stop with reporting Daily Standup/Team Synch. It’s not to be used to generate a report. It’s the first and most basic level of planning a team can do. Make it count!

Bringing It All Together

By inspecting and adapting daily during your Daily Standup (DSU), you’ll know if you’re on the right path. Iteration Reviews and System Demos help you check if you’re meeting the iteration goals and PI Objectives. This way, you can quickly decide whether to pivot or persevere, avoiding wasted effort and resources.

How?

  • Daily: Inspect and adapt during your Daily Standup (DSU).

  • Every Iteration: Review your team's progress during the Iteration Review.

  • Every Iteration: Assess the overall progress of your Agile Release Train (ART) during the System Demo.

  • Every PI: Evaluate your progress towards the right solution for the right customer, with the highest quality, delivering the most value in the shortest sustainable lead time. By doing this, you’ll create products that are desirable, viable, feasible, and sustainable.

  • Every PI: Close the loop between the strategy and execution by using the feedback received and reintroduce to the next business context.

By aligning IT and Business, you’ll become partners in creating value for customers. Decision-making becomes decentralized, and everyone becomes more motivated. Together, IT, Business, Solutions, and Customers iterate toward success.

Want to test this hypothesis? Start by embracing the VUCA world (for real) and acknowledging that we don’t know everything upfront. Welcome to the agile way of life!

Hope you enjoyed the ride!

Stay Agile!

Yours,

UncleEduardo