Within SAFe, PI Planning (or Release Planning) is when all the people on an Agile Release Train (ART), including all team members and anyone else involved in delivering the Program Increment (PI), get together to collaborate on co-creating a plan. The goal is to create confidence around the ability to deliver business benefits and meet business objectives over the coming weeks and months – typically around 3 months or a quarter.
To many people this feels un-agile. Isn’t it creating a big plan up-front and defining work far ahead? However, a recent experience led me to realise why its not about the plan, but the planning and the dynamics of the event itself. In Cynefin terms, PI Planning is a catalyst for transition and movement between domains.
Let me explain.
Before PI Planning, and a move into an ART cadence, many organisations are in Disorder, relying on order and expertise when they should be using experiments and emergence. The scheduling of a PI Planning event triggers a realisation that there is a lack of alignment, focus or vision. In order to prepare for the event people have to agree on what is important and what the immediate objectives, intentions and needs are. In short, what does the Program Backlog look like, and what Features should be at the top. The conversations and work required to figure are the beginning of a shallow (or sometimes not so shallow!) dive into Chaos.
During PI Planning is when the Chaos reaches a peak, typically at the end of Day One, as it becomes clearly apparent that the nice ordered approach that was anticipated isn’t achievable. More conversations happen, decisions are made about the minimum plausible solution and hypothesis are formulated about what might be possible. This is when action happens as everyone starts to pull together to figure out how they might collectively meet the business objectives and move the situation out of Chaos into Complexity.
After PI Planning there is still uncertainty, and the iteration cadences and synchronisation points guide the movement through that uncertainty. Feedback on the system development, transparency of program status and evolution of the solution are all necessary to understand progress, identify learning and inform ongoing changes. This may require subsequent dips into Chaos again at future PI Planning events, or over time the ART may become more stable as understanding grows, and PI Planning in the initial form may eventually become unnecessary.
It is this triggering of a journey that makes me believe that PI Planning, or equivalent “mid-range” and “big-room” planning events, are a keystone to achieving agility at scale for many organisations. I wonder how this matches other’s experience of successful PI Planning meetings? Let me know with a comment.
If this doesn’t make it into v9 of the Leading SAFe training then we’ve missed something huge: “The scheduling of a PI Planning event triggers a realisation that there is a lack of alignment, focus or vision.”
[…] my level of sadness increased still further when I read his piece on understanding PI Planning in a Cynefin light, and realised he wouldn’t be with us to explain it in […]
Karl:
Makes perfect sense. I think too many agile purists, be they Scrum Alliance senior or Kanban thought leaders, dismiss SAFe out of hand with such pejorative assessments as “Too Big & Prescriptive”, or “Too Much of One Size Fits All”. This despite Dean Leffingwell’s continued advice that customers should tailor the SAFe guidelines as they see fit – and which I have certainly done. I’ve also see first hand that many “big” organizations (lets say at least 5K staff or larger in size) really **are** looking for precisely these kinds of guidelines – and if they do it themselves, within the often even more prescriptive policies they typically implement, they end up inventing something very much like SAFe to address the interdependencies.
I see your blog as in alignment with Eisenhower’s great statement: “Plans are worthless, planning is everything” – –
Excellent article. You hit the nail on the head with your use of the Disorder domain – organisations think they’re in an ordered situation because they’ve got lots of procedures in place, when in fact planning for large scale initiatives, particularly involving many people, can be ultimately successful only if the environment is understood as complex.
Eisenhower’s statement is so true – echoes one I’ve heard attributed to Napoleon: Before a battle, plan to the greatest detail. Then throw the plans away and act.
Karl,
Great post. Does anyone was able to introduce the PI (Big Room ) planning in the large scale dev organizations with the geographicaly distributed teams? How to avoid flying hundreds of people from one continent to another every 3 months?
Thank you,
Igor
Hi Igor,
I know of lots of people who have run this sort of event across geographies and timezones, and have done so myself. Generally it requires plenty of video-conferencing, and some additional thought into how to effectively facilitate to allow everyone to participate.
Karl
Thank you, Karl. I would be interested to learn about any “todos” and things to avoid from the people who went through the Big room planning exercise with the large distributed dev teams. I did find some interesting videos on the youtube but non of them were discussing the ways to address the situation when your team is distributed between the different time zones and regions. The advise to fly everyone to the same location every 3 months is not very productive considering the size of the team and the cost.
What I have seen work well is something along the following lines:
* Have whole teams in each location so each team is at least planning its own work together
* Maximise the amount of overlap time by asking everyone to start/finish slightly earlier/later
* Ensure teams have enough information to continue planning when there is no overlap
* Allow extra time, and have more frequent synchronisation, especially when teams go on/off-line
* Lead from all locations – all locations are equal
* Use technology to maximise bandwidth and communication channels
Karl