Breaking the SAFe: Deconstructing PI Planning

[@joshburdick2464]

As an SPC who’s taught over 85 SAFe courses the past four yrs, I think this was a very worthwhile discussion! Keep them coming! As I coach in my large enterprise, I try simplify these concepts. These videos let me know I’ve got the right mindset.

[@AgileforHumans]

Wow, thank you! We appreciate the support and are glad that the new SAFe series is valuable to you!

[@olemew]

28:00-30:30 that exchange and Yuval's explanation were great

[@matthewhodgson1168]

I think for me, PI Planning's best at visualising and sequencing dependencies between teams, and helping stakeholders see what is planned for the quarter. But Ryan is right when he says it creates this sense of locking in the scope of the PI. It happens everytime I launch an ART.

[@yyeret2]

yes. you need to be really intentional to avoid this lockdown.

[@ThomasOwens]

Thank you for this! This is fantastic. In the beginning, Ryan nailed my concerns with PI Planning. But it's even more than days with 2 days of PI Planning but also stuff in the IP Increment beforehand. I also think Yuval got it spot on where people feel more comfortable with details and it's a practice versus theory gap. Although even trying to plan more than a couple of Sprints ahead makes me worry, even if you're talking about goals and objectives.

[@stasvpavlov]

Glad to hear Story Points are also Trash in SAFe ;). On a serious note. What I have often found that what becomes painfully obvious is that the elephant in the room is that the organization is oblivious about the lack of strategy. Or simply put the emperor has clothes because they were stolen by underpants gnomes (meta, I know). On the plus side I always enjoy the sweater that comes out of the weaving done on the dependency board 😅.

[@yyeret2]

😆love the gnoes+emperor clothes mashup! brilliant!

[@stasvpavlov]

@@yyeret2 Toda raba!

[@marymiller1253]

Re-watching. Now that I am finally pulled more into other projects and not just tech debt, this series is very useful.

[@user-vk3xc8qs8n]

New comment: really love the video. Context was created very well, and this enhancing my understanding of how SAFe could be implemented. In some ways, I now view PI Planning similar to Release Planning. In a previous organization (not using scaled concepts), I inherited a project that had releases planned 1-2 years out. It was Waterfallish. However, what was nice is one could see an approximate timeframe of when features or functionality (for each area) would be released. Although I did understand that the things further out may or may not get done in a particular timeframe (I.e. cone of uncertainty). It also helped us gauge an approximate time when we would be able to sync up and integrate a system of systems with our counterparts in other parts of the country.

[@kdiggity1]

Who was the facilation god? @6:12 Did Yuval say "Gene Tabeka?"

[@kdiggity1]

Oh, it's actually Jean.

[@matthewhodgson1168]

I find the PI cadence and planning event tends to reduce "ability to pivot" for teams to quarterly instead of every Sprint.

[@user-vk3xc8qs8n]

Timely given we are about to go into PI Planning. I will say that I was a bit horrified to see that projects were just renamed as features. Coming from a Systems Engineering background, with some software development knowledge, I think there is some room for development in what features mean. Most of the time, my work doesn’t really require my presence, at PI Planning, except to learn something about the organization. Although it is good for the managers to discuss work coming down the pike so that they can align people to the work that needs to be done. One of the risks, especially if teams are component teams, are if too many teams are dependent on another team to deliver. If the latter team hits an impediment, 2-3 days of planning go down the drain. That is risky and expensive. I would love to hear something on if there is some way to nudge people (CSMs, CSPO, managers with only the SA cert, etc) to think from the perspective of empiricism and the Product mindset. I am the only one on the team with Scrum.org certs.

[@destinpl]

Thank you both for all the insights. I must admit they give me hope that PI planning could be valuable event. I still have one concern with PI planning - in Scrum if things change radically then PO could terminate current sprint. But it's not an option to terminate Program Increment. That gives the impression that teams should stick to their initial commitments at all cost, even if they are obsolete. Or have I misunderstood something?

[@googleaccount5225]

Seems to share the same problem with Scrum: planning. Seemed like the original idea of an increment was, can we shrink an increment such that we can deliver something a sprint? These days most teams can create an increment in a day or two. With increments being so easy the question becomes what to make of a goal. Some try to insert many increments into a goal. No longer is it about shrinking an increment but growing it. And eventually crowd out the ability to deliver one increment anymore. Obviously there are patterns for this but I have found planning to be the most contentious routine-following practice in Scrum. I have found that setting expectations, forecasts, and predictability work better in review events, not planning events.

[@AgileforHumans]

Scrum allows multiple increments in a Sprint.

[@yyeret2]

@@AgileforHumans and so does SAFe :-)

[@yyeret2]

You'd be surprised how many teams still struggle to create increments in a day or two.... or even two weeks... while we can say - let's work on getting there and then apply agile - I would say that an organization that struggled with this for so long isn't gonna improve much using their current operating system. so they need an operating system to help them navigate the journey towards continuous development. That's what SAFe is about. And like we discuss in the episode - it's not for everyone or every context. you need to think from a change management perspective to figure out what agile play makes sense...

[@jaredmorr1000]

How Yuval explains this is so different from the implementation I experienced, direction I received from our RTE, and the SAFe training I attended. I don't understand how his perspective differs so much from everything I've consumed. I appreciated his willingness to break this stuff down with Ryan but this has been the most confusing Breaking the SAFe episode yet.

[@goblufeverwe]

It seems to me an organization can spend time and money on fixing poorly constructed teams, grouping of product teams and leadership habits or it can implement a scaling framework and processes to address the planning and work flow dysfunction that an organization doesn't want to address. Thoughts?

[@Rekettyelovag]

Maybe I'm the one who don't understand this, or I'm not familiar with the terminology, but SAFe says: IF we are not talking about filling sprints with backlog items based on velocity then what does "estimate their capacity for each iteration" and ""identify the backlog items" mean here? Also where does PI Planning resides in the "planning phase"? Because the documentation says But then the Day 1 Agenda starts with business context and product/solution vision. The question is, when will the teams get involved? Before the PI planning or during the PI planning or is it a redundancy? Do the teams know what would they work on before the PI planning or they got familiar with it during the planning?

[@tomaszniemiec]

Definitely came out more concerned and negative from this video, then it was the case for the previous one. This is one of the key areas that SAFe fails for me, is that it tries to bend the reality and goes hard on wanting to grasp unpredictability. But, let me ask: looking at something like the OST (Opportunity Solution Tree) method, does the PI planning stop at the solutions level or goes down into ideas and beyond?

[@MisterAwesan]

My experience is that PI planning can serve as a hedge against weaker POs. It gives the PO a fixed amount of time for their objective, so they must make it manageable. And the team can hold them accountable for that in a structural way. If your PO is on point and you are able to capitalize on the benefits of scrum, then the PI planning loses some of its value. But in bigger organizations it is often the case that you account for the weakest link.

[@yyeret2]

I would say that if you have good POs with stream-aligned product teams, PIP doesn't necessarily lose its value. It just becomes easier. Teams will spend more time just strategizing and doing horizon planning for their own product, and there would be less need for managing dependencies across these teams. The synchronized nature which makes access to stakeholders and other teams easier is still quite valuable in my experience.

[@rolemodel99]

Reconciling what Professional Scrum teaches and what SAFe prescribes and is practiced in a practical manner within a large enterprise setting is where I have trouble the most. What Professional Scrum practices have we seen that bridge this gap?

[@MrCire69]

Should be called "Cracking the SAFe"