What the "Right" PI Cadence?
If you've studied SAFe and are familiar with its concept of a PI. The default duration of a PI is 8 weeks, but by the book it can last 8-12 weeks. The concept, though, is that once you establish the PI duration it generally doesn't change. An unofficial way to think of a PI is a large sprint. In Scrum the duration of a Sprint (or Iteration in XP/SAFe terminology) is fixed (say, at 2 weeks) and is always of that duration unless a retrospective leads the Team to experiment with something else (say 1 week sprints). But where did this duration come from, and when might you want to consider a different one and why?
Releases and Release Planning
I haven't read all of the foundational material behind SAFe, so I'm basing this on the word of those who have and who have also discussed its history with Dean himself. There was a time not that long ago when quarterly releases were considered fairly aggressive. OK, in some industries they still might be, but that's another conversation for another time. If a new software release was going to be delivered by the end of the quarter, then planning was required, hence the creation of "Release Planning." The last few weeks of the quarter were designated for preparing for the deploy and release activities, hence the "hardening sprint" at the end of the cycle.
The story goes that Dean wanted to get even more aggressive. Why only have 4 releases a year when you could have 5? And since more US based IT organizations plan very little work in the last two weeks of the calendar year, why not just recognize that they're lost and plan on that? This led to 10 week Release cycles giving 5 Releases per year with a 2 week break for the winter holidays.
PI Planning
As it became more feasible to deliver value in shorter periods of time, it made sense to move away from a fixed number of Releases per year to a new flow-based approach where value should be deployed and released when ready rather than waiting until the end of an arbitrary time period. This led to the change from "Release Planning" to "PI Planning." Today a PI is a timebox for planning out the increment of work that might take place while leaving room for late changes based on new information.
Scheduling PI Planning
Anyone who has attempted to schedule PI Planning events knows that it can be kind of a challenge. Besides the obvious problems of just getting the right people on the invite list and figuring out where and how the event is going to take place, there's another challenge: when? When working globally it seems as if there's a holiday or festival or other consideration almost every week. How is someone supposed to schedule these things? But wait, it gets more challenging: the dates keep moving!
Look at this 10 week schedule. This schedule shows 3 days for PI Planning mostly to make it easier to see, although that might be reality either to hold the I&A workshop just before the event or for a hybrid/online event. And don't forget that PI Planning falls during the last Sprint of the PI, so it could move slightly.
Try explaining to someone when PI Planning season is going to be year over year when it rotates like this. And what are the chances that the next planning period will be free of holiday conflicts? Just look at PI 6 planning - it's Christmas week!
You could try another approach like 12 week PI's, but whether it's 8 weeks or 12 weeks you're going to have a problem. So what to do?
Predictable PI Cadence
Both of these recommendations are based on a pragmatic approach and fly in the face of SAFe "by the book." As a matter of fact, some agile coaches will argue strongly against them for good reason. But let's consider them anyway.
Having a predictable cadence is very useful. Once it's built in to the culture people are familiar with when Iterations (a.k.a. Sprints) are going to start and end, and they get used to the concept of PI's. Not only is it good to have a set time box, but it's also good to be able to explain generally when the main events will take place in the rhythm of the year. When PI Planning moves all over a calendar it becomes difficult to connect with the rest of the business.
Option 1 - an annual break
Once you know the history of PI's from the story above, then one option becomes clear. Schedule 5 PI's per year and then take the last couple of weeks off. This way it's fairly easy to explain that PI Planning takes place the first business week of every year.
One obvious problem with this approach is that the business has to consciously recognize what we all already know - nothing significant is getting done in those last two weeks. For those who aren't taking time off this could be used as extended innovation time or perhaps for bashing bugs or something similar. Another option would be to schedule that last PI through the end of the year making it a roughly 12 week PI.
Option 2 - Quarters
In the early days of Agile when there was no distinction between "PI Planning" and "Release Planning" more planning events meant more releases which meant your company was "more agile." Today we recognize that there are times to intentionally plan to start work in one PI that will carry over into the next so that there is a smooth, continuous flow of value. With that in mind, perhaps it's time to re-think how we batch sizing, especially given the cost and time away required for planning. But there's another benefit.
Other parts of the organization, such as marketing, sales, and finance, often work in quarters. (This isn't true of all businesses, of course. Some manufacturing and distribution companies work in "periods" in which case yet another cadence may make more sense.) Chances are good that they're already on a quarterly cadence and making quarterly plans. Why not sync up with them and use similar language? Furthermore, many Finance organizations have major activities at the end of every quarter, so by moving to a quarterly schedule you can ensure the PI's are out of sync with closeout allowing Finance to participate, if appropriate.
There's obviously one challenge here - a 13 week quarter isn't divisible by 2 or 3 weeks which are the typical duration of a Sprint. So what then? Some companies solve this by having five 2 week Sprints and then a single 3 week Innovation & Planning Iteration (a modification of SAFe's guidance). Others are moving towards six 2 week sprints and a one-week IP Sprint while then also setting aside additional time elsewhere for innovation to make up for the lost innovation time.
Obviously there is a slight challenge in this example with PI Planning falling around the US Independence Day holiday, but the entire calendar could be shifted a week one way or the other, and don't forget that SAFe actually says that the PI Planning event can fall anywhere in the IP Sprint, so in this approach it could be in any of 3 weeks in any PI.
It's possible to slightly offset the planning event from the start of the actual Quarter. This may be a smart thing depending on the needs of the rest of the organization. It's OK for Quarter 1 planning to start in the second or third week of January provided everyone involved knows what "Quarter 1 Planning" actually means.
Tradeoffs and Conclusion
Are there tradeoffs in both of these recommendations? Absolutely!
Both of these involve some sort of variation from the consistent pace of 2 week Iterations and 10 or 12 week PI's. This change could not only affect how the team works, but it also requires a bit of nuance when gathering metrics.
However, it's worth recognizing that PI Planning by its nature is different from the regular Iteration cadence. This means that the normal flow of work is broken up by design and that metrics will have to be tweaked to recognize the change in velocity during the IP Iteration. And anyone who's spent time gathering Agile metrics knows that they must account for the unusual times of the year such as the last two weeks in North America and similar ones around the globe. Meanwhile, the benefits of being able to lay out a multi-year planning schedule that avoids major conflicts in the form of holidays and other standard business events is huge.
