I’m writing this around the time when businesses are essentially locked down by Covid-19 and everyone is working virtually. It remains to be seen what types of working habits and new norms will emerge and stick after we recover from this viral attack. 

Here I’d like to explore SAFe PI Planning as a planning construct or pattern. Talk about the origination of the idea. Then explore remote PI planning as something that we could do virtually.

But what I really want to focus on is an extension to PI Planning that could nearly negate the need to do it either face-to-face or virtually.

PI Planning – The Intent

The intent of PI Planning is to get a number of teams together for face-to-face planning once a quarter to commit to a body of collaborative work. It’s a scaling tactic that has its roots well before agile hit the mainstream. For example, a similar pattern was shared by Dwayne Phillips in his book The Software Project Managers Handbook, published in 1998. Dwayne called it Cards-on-a-Wall planning. I’ve used the technique to plan larger-scale waterfall projects with 100+ participants.

The PI Planning pattern is intended to—

  • Capture a shared vision/mission/set of goals for a given body of work;

  • Vet them with the individual teams assigned to accomplish those goals;

  • Have the teams interact x-team to resolve dependencies and any other x-team interactions;

  • Leave the room with a high-level view of the work for all of the teams and a confidence vote as to how achievable the plan is towards delivering on the chosen objectives.

The face-to-face aspect of the planning, immersed for several days, is crucial to the quality of the collaboration, the “plan”, and the overall alignment to goals.

Virtual / Remote PI Planning

Initially, PI Planning was viewed to be solely an in-person event. I recall many organizations struggling with the financial aspects of getting larger-scaled teams together once a quarter.

For the past ~5 years, many organizations have been forced to come up with mechanisms and tactics for supporting partially or fully remote PI Planning. Part of that is related to maturing tool-sets. Not only for meeting collaboration but virtual boards that allow for effective and efficient distributed planning.

For example, I was coaching with Ipreo in Raleigh (teams across NYC, UK, Eastern Europe, etc.) around 2014-2015 and we successfully used RealTimeBoards (now Miro) for PI Planning collaboration across ~20 teams.

But this wasn’t a unique experience. I know of many teams who tried remote PI Planning prior to 2020. It was usually a mixed bag with some teams being local and others being remote, so it was partially remote. A virtual tool usually helped with the planning, for example—Jira, Miro, or Mural were commonly used tools. Anything that could present a virtual release board for all of the teams to collaborate on and visualize their plans. 

However, no matter the locale of the teams, PI Planning looked the same. It required a—

Net-net, no matter how you slice the approach, PI Planning is a huge time investment for the organization. And, the hidden little secret behind the planning is, for that investment the plans often (nearly always) …

Change, evolve, emerge, did I say change?

Given that dynamic, I’d like to discuss an alternative form of PI Planning. The intent and value proposition remain there. But the implementation dynamics might be (1) easier to accommodate in the real-world, and (2) more accurately embrace the emergent nature planning and delivering products. I refer to it as Rolling Wave PI Planning and that’s where we’re going next.

Rolling Wave (RW) PI Planning

In a phrase, RW PI Planning isn’t fixed to a quarterly event. It’s as simple as that.

The same PI Planning activities, tactics, collaborative conversations, etc. occur during RW planning. They just happen on an ongoing (continuous) basis and in much smaller chunks.

And the planning is tied more succinctly to your Backlog Refinement tempo at two distinct levels—

  • Team by team (PO x PO) backlog refinement;

  • And X-Team (x PO team) backlog integration, coordination, and aggregation.

The driving forces behind RW PI Planning are still aggregated release targets (milestones, roll-up releases, periodic deployments, etc.). However, they’re not fixed to a quarter by quarter tempo. In one wave you might target a 30-day release, in another a 90-day release, and in another 45-day release. Whatever the clients and the market requirements based on the team’s capabilities to deliver accumulated content.

From that point of view, RW PI Planning aligned with the release on demand notions that have been more recently added to the SAFe flow. We’re still tempo-based, but you could, for example, release every sprint, once a month, or every 45 days.

So, much more flexible in aligning the release timebox to the size of the content goal. And from that perspective, more easily aligns with Kanban-style work as well. I’ve seen organizational leaders try to squeeze too much content into quarterly releases and this approach lessens that tendency.

RW PI Planning also implies that your higher-level portfolio planning is occurring continuously tool. This would include— 

  • Defining functional and technology epics;

  • Evaluating scope and ROI potential for the epics;

  • Prioritizing them into the portfolio flow for roadmaps and release plans;

  • And translating content down into the various teams.

A final benefit of it is the impact it has on Product Owner organizational stress. Normal PI Planning dynamics can place a tremendous amount of pressure on “Product” to prepare for each event. Usually, they deliver, but the quality of the requirements (Epic…Feature) analysis often suffers. Which then impacts the teams.

Contrasting the 3-types of PI Planning (in person, remote/distributed, rolling wave)

It’s important to remember that all three styles have essentially the same tools, tactics, and intentions. The real difference between them is the scale of the planning (Big Bang vs. Incremental), potential variability of the release timebox, and transparency of emergent triangulation towards planned release goals uncovered during the work itself.

It’s really not about planning

First, PI Planning is not really about commitment or committing to a body of work across a set of teams. Sure, you can declare that as an outcome and look for it. But I don’t think it the most important outcome.

  • Dependency identification;

  • Dependency flow and preventing over-commitment;

  • Priority decision-making;

  • High-level visioning;

  • Stakeholder engagement and understanding of true capacity; and

  • X-team collaboration and clarity of understanding scope.

Taking the time via RW PI Planning allows for a calmer, more sustained level of ongoing understanding, adaptation, and triangulation towards your release goals.

Intense Preparation often compromises quality

Quality around—

  • Quality of the artifacts

  • Quality of the collaboration

  • Quality of the outcomes and overall understanding

  • Quality of the commitment

Are often impacted when rushing to do an intense 2 or 2 ½ day session. I’d much rather continuously focus on the planning by extending our awareness and understanding out in time. Point being RW PI Planning is often a more thoughtful, detailed, and higher quality approach to landing your product releases.

Wrapping Up

In a perfect world, I’d recommend that organizations stop doing SAFe. You can read more about those thoughts here. But if you are determined to execute using SAFe or doing any sort of release level planning, then I would recommend doing it in a rolling wave fashion over having a fixed planning & release tempo.

But that being said, I’ve always had an affinity for and see great value in performing release-level (PI Planning). It’s one of those practices that help teams envision an outcome and navigate cross-team dependencies and discovery towards meeting their goals. 

I hope I’ve inspired you to release some of the constraints in your PI Planning and see what might be possible in rolling your waves.

Stay agile my friends,

Bob.

3 Comments