This is the last part in the 'SAFe® IP Iteration' series. Read part one here and part two here if you missed them. In part three, Tom goes back to address the original objections to whether the IP Iteration is Agile.
Coming back to the original objections
Let's go back to our original objections and deal with them now that we understand why SAFe is constructed the way that it is.
"But this just isn't Agile! Why can't we just keep Sprinting?".
Some people really dislike the "break" from the cycle of Sprints and view the IP Iteration as an ineffective tradeoff that isn't needed because all of the above activities can be worked into each Sprint for each team. This is essentially the single-team Scrum view that life should be an endless series of Sprints.
The normal response to this is to point out that there's a bigger programme picture, that the team is part of a team-of-teams and time needs to be spent on those activities, and that all of this rests on the same PDCA principles that underpin Scrum.
See the bigger picture beyond the team you are part of.
A possible compromise for teams who like the discipline of Sprints is to allow them to treat these two weeks as a Sprint - but as a special Sprint with different priorities and some scheduled programme activities. This does no harm so long as it is not another regular 'delivery' Sprint.
"We don't have time for this, we've got too much work to do!".
This is akin to saying "We don't have time to reflect, improve and plan as a team-of-teams because our team is already so busy". That means missing the bigger picture as discussed above. If the team is this busy, they should probably be forced to periodically step back, think about the medium-to-long-term horizon and have a breather.
"Planning together is worthless because everything changes soon afterwards."
This may be true but if it is true, that simply means that individual teams are not (yet) predictable. Sometimes people advocate never planning ahead of the current Sprint in any fashion. This does not work for most organisations who need to be able to commit to broader organisational goals, deadlines and deliver on longer-term commitments they make to customers.
The right response to this is not to dispense with PI Planning, but to focus on team predictability so that the plans become more useful.
"It is boring and a waste of my time, I'm here to write code".
This is the mentality of an individualist who cares more about their work than their team's or the team-of-team's. There is a bigger picture at both levels and succeeding individually at other people's expense benefits no one in the long term.
PI Planning helps everyone get that 'bigger picture'.
SAFe's style of aligned cadence across teams with explicit medium-term PDCA activities principally implemented inside the IP Iteration (with the exception of the regular System Demo) is not everyone's ideal choice. However, it does have behind it careful thought about tradeoffs and the same Agile principles that underpin Scrum.
It is possible to work without an IP Iteration but it is very hard to properly find time for all the activities and fold them into regular delivery Sprints - in practice people trying to do this are often simply not doing many of the activities even when they wish they could.
In many cases, when these activities are properly done, there's so much to fit in, that two weeks often feels a tight timetable for the IP Iteration.
The structure and length of the IP Iteration can of course be customised - SAFe is simply a framework after all - but it shouldn't be done lightly without experience and without thinking through the new tradeoffs that will result.