Why PI Planning is like a wolf in sheep’s clothing
PI Planning isn’t an Agile panacea.
“We are Agile! We have a backlog, and we host awesome PI Planning events.”
— Manager in an Agile Transformation
In one form or another, I hear a statement like the one above all the time. And every time I hear it, I cringe. I wonder how things have gone so far astray.
I cringe because Program Increment (PI) Planning from the Scaled Agile Framework (SAFe) does not support an Agile mindset. All my experience with it tells me this is true. I have never seen PI Planning help a team embrace change.
Yet, SAFe is the default for those seeking Agile without having to endure a difficult change to their status quo. And SAFe sells itself as an Agile panacea. For instance, if you look up PI Planning on the SAFe website, you will find this in the first sentence:
The Agile Manifesto states, “The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.” SAFe takes this to the next level with PI planning.
— PI Planning, © Scaled Agile, Inc.
Right there, the illusion begins. The implication is you are Agile if you do PI planning, and it’s front and center with the Manifesto reference. Not only are you Agile, but you are taking the face-to-face conversation to the next level.
Of note, the PI Planning page fails to mention any of the four Agile values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
— The values listed in The Agile Manifesto
I’m not surprised the Agile values are not called out. In my experience, PI Planning does not support any of them as this post will illustrate.
I realize many of you reading this might have a fondness for PI Planning. As such, you might be tempted to stop reading this post. But I urge you to give me a little more time to explain why PI Planning works against your quest to become Agile.
PI Planning creates a big plan and contract upfront
Planning an entire quarter in advance assumes a predictability level not present in product development. Despite this, we behave as if we have near-perfect certainty when performing PI Planning.
A key output of PI planning is a set of business-relevant PI objectives, which is a step in the right direction. But instead of the PI objectives, the program board gets most of the attention. The program board is the basis of the big plan and contract upfront.
The PI Planning event is a large investment of time for a large number of people. Reassembling after the event as the plan needs to evolve is rarely a viable option. As such, the program plan becomes rigid and gets treated as a contract for all teams to follow for the quarter.
Once on the terrain to execute the first SAFe iteration of the increment, we get the clear reality of this plan’s frailty. As soon as evidence of a better path emerges, the rigidity in the PI plan often deters change. For the quarterly plan to hold water, all teams in the Agile Release Train must play their part and deliver on cue.
A better path!
Instead of big batch PI Planning events, you need more frequent small batch planning. In place of freezing scope early, enable change through frequent inspection and adaptation. You need continuous planning instead.
As evidence emerges, continuous planning moves between now, next, and later planning horizons. It refines the plan at the right level of fidelity and the last responsible moment. You spend less effort planning, contain risk, and pivot fast as learning happens.
I have written before on the topic of continuous planning. Scrum provides a lightweight framework to enable it. Read more about how to perform continuous planning using basic Scrum in the post below:
PI Planning disrupts the flow of value
SAFe claims PI Planning doesn’t disrupt value flow. This is because it happens during SAFe’s Innovation and Planning (IP) iteration.
Holding the event during the IP (Innovation and Planning) iteration avoids affecting the scheduling, or capacity of other iterations in the PI. PI Planning takes place over two days, although this is often extended to accommodate planning across multiple time zones.
— PI Planning, © Scaled Agile, Inc.
But the IP iteration itself disrupts flow for an entire iteration. SAFe neglects to mention this. And don’t get me started about relegating innovation to only one specific iteration.
The mere presence of an IP iteration denotes the absence of innovation, planning, and sustainable pace in normal iterations. This is analogous to how a hardening iteration denotes a void of testing and getting to “done” during prior iterations.
Also, many celebrate the rapid, two-day duration of PI Planning. While condensed into two days, significant, flow-depleting preparation is necessary before the event. And after the event, the orchestration and scrambling to stay true to the PI plan puts a massive drag on value flow.
A better path!
Continuous planning, as mentioned above, disrupts value flow less than big batch planning. Smaller goals and smaller batches of work take less time to prepare, fewer people to plan, and reduced time to plan. And when you need to change course, it’s easier and costs less.
Optimizing your flow depends on learning and pivoting fast. And your path to flow means you won’t always finish what you start. You will find pivots become frictionless when you plan small batches. Read more about this concept in my post below:
PI Planning does nothing to break dependencies
Like a snug blanket, SAFe hugs you and accepts your function-driven, organizational shortcomings. It makes you feel “safe” in your status quo.
No amount of perfect PI Planning execution makes up for ineffective team structures. When the team is a siloed area of expertise, mastery focuses on pieces and parts, not features. Teams composed of homogeneous skillsets can’t deliver end-user value by themselves.
For a valuable, working product increment to emerge, it must pass through many functional teams. These dependencies hold value hostage, like a boa constrictor. As a result, the value becomes subordinate to the dependencies.
SAFe allows for this ineffective, dependency-driven organizational model. And PI Planning makes it feel right at home.
PI Planning brings dependent teams together to form a plan that links them. All the dependencies become visible. This creates a false sense of comfort that we can control the situation by having a good plan acknowledging all dependencies.
If you have been a part of PI Planning, I’m sure you have performed the dependency mapping activity. Here you use yarn or a similar tool to connect all team dependencies on the program board.
To an outsider, this looks impressive as if real transparency is taking place. To me, it looks like delays in waiting.
Many fall in love with the visual created by the dependency map. This happens because, finally, all dependencies are visible where they were not before. But many using SAFe rarely take the next step of real value — finding a way to break the dependencies.
Too often when implementing SAFe, the existing functional organizational model remains untouched.
In the end, the team structure is not challenged. The goal is better planning and visibility of dependencies instead of effective team organization. The flow of value is secondary to a big, up-front — albeit visible — plan.
A better path!
Don’t waste your time identifying and coordinating many teams to deliver end-to-end user value. Instead of visualizing your dependencies, break your dependencies.
While it’s not feasible or advisable to remove all dependencies, minimizing dependencies is critical for enabling teams to deliver value. When you break a dependency, you bring control back to the team. This ensures an effective flow of value to your customers.
There are many ways to break dependencies. Here are a few:
- Create cross-functional feature teams with all capabilities to deliver a working product to customers
- Do the work yourself instead of waiting for an external, dependent team to do it
- Create a workaround to avoid waiting for an external, dependent team to do the work
- As a last resort, wait for the external dependency to complete its part before starting your work
Breaking dependencies is a passion of mine. The value of doing so is immense. Simple mathematics proves every dependency you break doubles your chance of delivering on time.¹
Nine times out of ten, your dependencies are internal and within your control. The siloed, functional structure of your product teams is to blame. Don’t settle for silos. Take time to form small, cross-functional feature teams who can deliver a working product.
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.
Our teams must master the diversification to deliver end-to-end user value. With diverse, complete teams, the need for the theater of a PI Planning event vanishes. To learn more about forming powerful, cross-functional teams, read the post below:
PI Planning provides the illusion of collaboration
Early in this post, we discussed the SAFe claims of how PI Planning takes collaboration to the next level. PI Planning is no doubt a grand event, guaranteed to get attention. But it is only smoke and mirrors to fill a collaboration void.
For one, PI Planning happens once per Program Increment, which is usually about a quarter of a year in duration. Does bringing together the program for two days once per quarter elevate collaboration? No, it doesn’t.
True, the collaboration is strong during the event. But collaborating for two working days out of sixty-five in a quarter does not raise the bar. Sadly, the collaboration does not continue after the PI Planning event in my experience.
Second, the PI Planning event has a heavy focus on process and tools. To coordinate many teams for a two-day event, it has to rely on them. As such, the process and the tools get all the glory.
The program board tool lives on after the event, and delivering against it tends to become the focus. Collaboration across teams after PI Planning ends is secondary to following the plan. Dependency deadlines drive teams to protect their interests over collaborating on a solution.
A better path!
Continuous collaboration should be the goal. Having all capabilities on the same team makes this possible. You no longer need a special event once a quarter for collaboration; it’s available to you every day.
Consider the post below as an example of the power of bringing two capabilities together on one team. It shows how collaboration thrives when one team performs both discovery and delivery. No ceremonious PI Planning event is necessary.
Taking it forward
While it seems like a step in the right direction, PI Planning can lead down a perilous path. And it ignores existing ineffective modes of operation and suboptimal team structures.
PI Planning is no more than one big-batch process and set of tools. The typical output of PI Planning is a documented plan for a one-quarter release. This interrupts working product flow before, during, and after the PI Planning event.
The resulting plan is one big, up-front contract. All dependencies must deliver in precise order and on schedule. And the sheer effort and logistics of PI Planning make it difficult to regather when things don’t go right.
Unfortunately, PI Planning ignores and accepts poor team structuring. Your functional team dependencies, while visible, will continue to plague your value flow. Seeing your dependencies does not help remedy ineffective team structures.
Proponents of PI Planning will claim the Agile Release Train allows for adaptation. In theory, this is true. But in my experience, it does not happen.
Instead of PI Planning, opt for continuous planning and continuous collaboration. Form complete teams with all capabilities to deliver an end-to-end product. Spend your time breaking dependencies versus managing and orchestrating them.
Your product development will be more sustainable. And you will be on the path to becoming Agile…for real.
For more content like this on my pursuit of Lean Leverage, delivered to your inbox, you can just join my email list. Or see my other related posts below to dive even deeper.
A special thank you goes to Willem-Jan Ageling, Leise Passer Jensen, Fredrik Carleson, and Kunal Shah for their thoughtful contributions to this post.
Related Posts
Take a deep dive into dependency breaking by reading my series on the topic. Start with the introduction below:
References
- Impact of Multiple Team Dependencies in Software Development, Troy Magennis, ObservableHQ.com, July 28, 2019
