The below article is adapted from our recent PI Planning webinar.
PI Planning is a core mechanic within SAFe; it’s one of the few things that SAFe does that is unique to it amongst all the other scaling frameworks. It’s been part of the framework since the very beginning well over a decade ago and it’s simulated as part of the Leading SAFe, Implementing SAFe and SAFe for Teams courses. It’s also taught in the Product Owner Product Management and Release Train Engineer courses, probably others. Surely this topic has been done to death?
Well, the advice is very much open to interpretation?
There is considerable flexibility in how that advice is interpreted, which can lead to good interpretations or bad interpretations.
Figure 1: Good interpretations promote agility, bad interpretations crush it
A good interpretation promotes agility, a bad interpretation crushes it.
The detractors of SAFe hold those bad interpretations up as proof that SAFe is not agile and in some respects, they are right, a bad interpretation might not be agile but that neglects the fact that a good implementation can be agile, very agile.
Why do PI Planning?
To Gain Alignment! That was easy, that’s what it says in the training…
Why do we need to gain alignment?
“There is more value in overall alignment than individual excellence.” Don Reinertsen. If Don’s statement holds true in your organisation then PI Planning and the overall SAFe setup are going to be a good fit. If it doesn’t hold true, if you just need lots of agile teams being individually excellent then you don’t need to collaborate.
Why do we need to collaborate?
Because there are large number of people working towards a common goal.
Why are there a large number of people?
The first rule of scaling is “Don’t”! Don’t scale if you don’t have to but sometimes we need more people and this is where the answers starts to branch, different organisations will have different reasons.
To have all the knowledge to manipulate the entire system in one person, or one small team is impossible. People will need to collaborate so that the total body of knowledge within them can be used to build the system.
To realise the value in the timeframe that an organisation desires then many people or teams will have to work in parallel together. Any single person or team wouldn’t be able to realise the value quickly enough on their own.
One of the criticisms against SAFe is that it promotes building a bigger and bigger pyramid of people to construct and maintain systems and solutions. The detractors argue that the correct course of action is to scale down by having a loosely coupled architecture that allows smaller independent teams to release smaller pieces in their own right. The detractors are correct, the end goal should be to scale down, but what they forget is that that is not where organisations are right now. Organisations have inherited, from the past, systems that are tightly coupled, that require lots of people to work on them in collaboration. They need a means of scaling agility to allow collaboration on the existing systems as they are now, so that over time they can evolve those systems towards architectural patterns that are more suited to agility and continuous delivery.
Even once you reach that nirvana of a loosely coupled, independently releasable architecture, PI Planning might still be beneficial. The business requests to change the bigger system will cut across the architectural landscape of independent pieces, and teams may still need to collaborate to work out between themselves who’s doing what and when in order to achieve the bigger business request.
This blog presents IJI’s interpretation of how PI planning should be done and, maybe more importantly, why we think it should be done this way. You might have a different interpretation, it might be equally good, how do you know that it’s a good interpretation…
Principles
…you hold it up to the principles
If it upholds those principles then you’ve got a good interpretation.
So we need to look at those principles first.
Figure 2: SAFe Principles & Values
SAFe has 4 Core Values, 12 Agile Principles from the Agile Manifesto, there is Lean, and there are 10 of SAFe’s own principles.
Rather than repeating several hours of training and many pages of detail this blog assumes readers have some familiarity with the various principles linked above.
Figure 3: Lean
Lean is the interesting one; particularly step 4 “Let the customer pull value from the producer.” That principle will reappear later as part of the planning process itself.
| Further Reading | |
|---|---|
|
IJI’s Principles cards are freely available, they’re great for engaging with the principles interactively by playing games with them. |
Design Thinking
It’s not just the default principles; there are couple of other principles, that aren’t enshrined in any of the others lists, that have a massive influence on PI planning.
The first of which is Design-Thinking; specifically the double diamond: separate the problem and the solution.
Figure 4: Design Thinking
PI planning is in the middle of the two diamonds, the boundary between the Problem Space and the Solution Space.
Everything prior to PI planning should be about understanding the Problems that the organisation needs the Agile Release Train to solve.
Everything after PI planning is about solving those problems.
PI Planning is about reaching alignment on what Problems the train can solve within the next timebox and planning how the teams intend to solve them over the next 10 to 12 weeks and who needs to be involved in developing those solutions.
It becomes the transition from problem space to solution space.
Autonomy
The next principle at work is autonomy. Autonomy is part of SAFe Principle #8 : Unlock the intrinsic motivation of knowledge workers, but it’s being called out here because during PI Planning autonomy happens in a fairly specific fashion.
This diagram originates from Henrik Kniberg’s write-up of the Spotify engineering culture in the early days of Spotify.
Figure 5: Autonomy and Alignment
from Henrik Kniberg : https://www.youtube.com/watch?v=_qIh2sYXcQc
The horizontal axis is autonomy, the amount of choice that teams have over how they do their work. The vertical axis is alignment, are the teams all focused on the same goal?
Most organisations start off in the bottom left. Low autonomy, people just doing what they’re told. Because they don’t have a lot of choice they’re not that happy and they’re not very effective. The arrows represent the amount that the teams are doing, the arrows aren’t very big because they’re not that effective, and they’re all pointing in different directions due to low alignment.
Not a good place to be, so what do organisations do? Let’s go agile!
They start adopting team level agile practices. The teams gain autonomy, we move across the horizontal axis. The choice over how they get things done allows them to do more, those arrows have definitely grown, but this poses a challenge for the organisation, how does it know whether these autonomous teams are actually fulfilling the needs of the organisation?
It doesn’t! What’s the usual response? Go command and control!
The teams are back into order taking mode; they’ve lost their autonomy and therefore slipped back down the horizontal axis, but they’ve risen on the vertical axis and gained alignment.
The goal is to be in the top right quadrant.
This can be achieved by posing problems, challenges for the teams to align around and solve. Doing this gives them autonomy, freedom of choice, over how to solve those problems. There are always constrains to the solutions they come up with, Regulatory, Compliance, even plain old coding standards are a constraint, but there should still be plenty of scope for negotiation over how the problem is solved. Problems are the output of the first diamond of the aforementioned Design Thinking.
Organisations that are sceptical about letting their people think for themselves, I remind them that twice during PI Planning the accountability loop is closed to check that the plan the teams are assembling meets the expectations of the organisation, and every iteration during the PI the accountability loop is closed again through the system demos to check that the evolving plan and associated value delivery is again meeting the expectations of the organisation.
Critics state that alignment takes autonomy away from the teams, you can’t have both alignment and autonomy. The critics will decry that the teams no longer choose what problems they solve and I would riposte that that depends on whether you involve them in creating the set of problems to solve. I would involve them, they should know their system and customers better than anyone else. If they don’t know their systems and customers better than anyone else, it’s not a framework problem, it’s an organisational problem you’ve employed a bunch of people that don’t know how to do their job, and for that you only have yourselves to blame…
Preparation
Preparation, Preparation, Preparation
But it has to be the right preparation and it’s not immediately obvious what the right preparation should be. Get it wrong and you can severely compromise PI Planning.
Vision
Figure 6: Vision, Set The Destination
When you are trying to Decentralise Decision Making, SAFe Principle #9, it’s The Vision that drives everything, to misquote David Marquez “The Vision provides The Intent to get Intent back in return”. By describing where the organisation is trying to get to, the destination, people are empowered to make their own decisions about how to get there. The autonomy mentioned earlier.
Line the Vision up with any bigger vision for the organisation.
Make it measurable, true business metrics, how does it contribute to the bottom line of the accountancy spreadsheet. Even not-for-profit organisations still need to think about the money, often trying to do the most with the scarce investment that they do have.
The vision drives everything that follows.
Roadmaps
Roadmaps provide the look-ahead to be able to ask the question:
“Is there anything that we need to do now to prepare for the future?”
Future functionality may require enablers to be done now to support that future delivery. Key dates are made visible so that the Agile Release Train can plan towards them.
The roadmap represents the organisations best guess at how it thinks it could reach the destination. Do not carve it in stone, it needs to change and adjust as the organisation gains insight from delivering earlier pieces of the roadmap.
It’s use as a forecasting tool is not to determine that some precise functionality will be delivered at 4:13pm on 2nd Thursday in February 2027, the insight it gives is “does the deadline look achievable?” If the answer is “no” or “it’s a little too close for comfort”, then we need to start doing something about it now: clear out irrelevant work, prioritise what’s needed for the deadline, move investment in people to create more capacity in the right place.
Do something now, because if you leave it until the deadline, it will be too late!
Feature Preparation
Cast your mind back to the extra principles mentioned earlier, Design Thinking and Autonomy, they apply to Feature preparation.
Design Thinking: PI Planning is the bridge between Problem Space and Solution Space. Feature Preparation for PI Planning is therefore in the Problem Space, it’s the set of problems that the business wants solved. This could be the challenge of adding new functionality, exploring options, ideas, improving tooling and processes, basically any problem that needs to be solved.
The important thing is that it is a problem to be solved, if it becomes a solution to be enacted, then it’s going to break autonomy. When presented with solutions, teams will stop thinking for themselves, they’ll just follow the instructions, blindly. You’ve employed engineers or creative professionals, you’ve employed them for their knowledge, their brains, utilise that or you’re wasting your money.
How you prepare you features is important as well.
Figure 7: Product Mangement Shouldn’t Be Message Passing1
The detractors of SAFe would suggest that it propagates the old world behaviours:
| “I am a Product Manager, I tell the Product Owners what to do.” |
| “I am a Product Owner, I get my instructions from the Product Manager and I tell the team what to do.” |
| “We are the Team, our Product Owner tells us what to do and we just do as we’re told.” |
A bad interpretation of SAFe can quickly end up as a message passing exercise, very un-empowering for all involved.
Instead, what’s desired is collaboration. Collapse the communication lines, get together all those that need to be involved, to collaborate on the elaboration of a feature. The Product Manager is there not to dictate, but to facilitate the conversations, facilitate the Product Owners talking directly to the Stakeholders who suggested the features, and to draw into the collaboration any other Subject Mater Experts that might have input into the feature, be that Security, Regulatory, Architecture or explicit business knowledge. Through the collaboration the Product Owners become empowered, as a collective they own the product. By elaborating the Features the Product Owners also understand those Features so that if their team selects a Feature then they are in a position to explain the business need described in the Feature to their team.
| Further Reading | |
|---|---|
|
Crafting good features is hard, it gets precious little slide time in the courses, even the Product Owner Product Manager course doesn’t really explain what makes a good feature. SAFe Fellow Ian Spence wrote a series of articles on Feature preparation: |
Socialize Features
Figure 8: Features Are Socialised With The Teams
The teams should have seen the features prior to PI Planning. If the features are a surprise at PI Planning then the reaction from the teams is likely to be an inflation of the estimates because they are incorporating their surprise and uncertainty into those estimates. Therefore, socialisation is good; it ensures that there are no surprises.
Socialisation also allows the teams to sanity check the Features and if something doesn’t make sense then, given that this is happening a week or two in advance of PI Planning, the Product Management team still have time to fix any errors or omissions.
What I wouldn’t want, and unfortunately most of the training material hints at doing this, is for teams to start working on the Features, to start creating stories. The reason why we’ll come back to later…
Prioritization
Preparation of the Features has taken the whole of the Planning Interval, socialisation of the proposed set of features takes place a week or two before PI planning and can happen even without knowing the Prioritisation. Prioritisation happens at the last minute; often only a day or two before PI Planning.
Figure 9: WSJF Worksheet
It has to occur last minute because it has to incorporate any work from the current PI that wasn’t completed needs to be factored in; and you’ll only know what that is once you’ve finished the last plan-able iteration within the current PI and that remaining work has received new estimates for effort to complete.
| Further Reading |
|---|
| There are some subtleties to WSJF, enough to warrant their own blog post on the subtleties of the Weighted Shortest Job First mechanic. |
Long story cut short, however: Estimation should be done by a sensible subset of the people on the train that do the work, the engineers, typically facilitated by the System Architect. User/Business Value, Time Criticality, Risk Reduction/Opportunity Enablement come from the Stakeholders, the Business Owners, facilitated by the Product Manager. WSJF is a tool for generating alignment amongst those stakeholders, agreement that this is the set of Features that they want the Teams within the Train to try and solve, if WSJF is done by the people within the train then it can become self-serving and any alignment to the greater business can be lost.
Experience has shown that the planning process itself is remarkably robust, the one thing that will cause it to fail is disagreement amongst the stakeholders, or between the stakeholders and the Agile Release Train. PI Planning is a garbage-in, garbage-out process; feed it garbage, a bad backlog, and it will produce a plan to deliver you that garbage.
Preparation, having the right backlog, that everyone agrees on, is therefore key.
The backlog provides the intent for the PI Planning process itself.
Next
Having explored the principles and preparation in this article, the next article will cover the practicalities of the PI Planning event itself.
Training & Support
If you’ve never done PI planning before it’s a daunting task. There is training to explain what’s happening, but for many some guidance to steer them through their first PI Planning event is very useful. You want people that have done it before, seen the situations, that know how to read the room. There aren’t many consultancies with comparable length and depth of experience.
#1 Pastiche of the Class Sketch : Cleese, Barker, Corbett