AA156 - "Selling" SAFe PI Planning to a not-SAFe Product Manager (with Special Mystery Guest)

In this episode, our favorite special mystery guest joins the podcast for a comprehensive walkthrough of the PI Planning agenda so that our resident Product Manager, Brian, can be "sold" on the idea.

SAFe P.I. Planning is a critical event that aligns teams with business objectives and fosters collaboration across the organization...

...or is it?

Drawing from extensive experience, we delve into the benefits of PI Planning, including fostering relationships, securing leadership buy-in, and mitigating risks. We also discuss the challenges teams face, such as managing dependencies, handling missed objectives, and maintaining engagement throughout the intense planning sessions.

0:00 Podcast Intro
0:17 Topic Intro
0:50 Benefits of PI Planning
2:20 Big-Room and Quarterly Planning
4:35 Product Pre-Work
7:06 Portfolio Funding: Lean Business Cases
8:43 Staying High-Level
11:25 Risks and Objectives
12:58 Failing to Meet Objectives
14:12 Arguing on: Stretch Goals
17:23 Goals: Committed vs Uncommited
19:25 Slowly Moving Train-Wrecks
23:43 Benefits of In-Person, Hybrid, & Virtual
27:57 Facilitating Preparation
30:19 SAFe PI Planning Agenda, Day 1 (Pre-Lunch)
34:27 SAFe PI Planning Agenda, Day 1 (Post-Lunch)
37:04 SAFe PI Planning Agenda, Day 2 (Pre-Lunch)
39:31 SAFe PI Planning Agenda, Day 2 (Post-Lunch)
41:44 Negotiations
45:27 PI Retrospective
48:11 Keeping Leadership Engaged
52:13 Wrap-Up

= = = = = = = = = = = =
Watch it on YouTube
= = = = = = = = = = = =

Subscribe to our YouTube Channel:
https://www.youtube.com/channel/UC8XUSoJPxGPI8EtuUAHOb6g?sub_confirmation=1 

Apple Podcasts:
https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596 

Spotify:
https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3 

Amazon Music:
https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-Podcast
= = = = = = = = = = = =
Toronto Is My Beat (Music Sample)
By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)
CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Transcript

0:01

Welcome to the arguing the Agile podcast where enterprise business agility coach Om Patel and me product manager Brian Orlando debate the real world challenges Agile professionals will face. We are not here to sell you anything. We are here to argue about Agile so that you don't have to. Jessica is here on the podcast today. so much, Jessica brought an interesting topic to the podcast she said, I'm about to do a PI planning. That's right. And I said, what is a PI planning? So we're here. For Jessica and Om, wherever, whatever camera you're on, sorry, for Jessica and Om to sell me on PI planning So again, I've gone through safe training. I understand it in theory. We have a four day agenda for our upcoming PI planning. That's in two weeks. Right? So. It is intense. It's a very intense agenda. But yeah, I'm going to pass it to Om with my first question. Cause again, I haven't experienced this firsthand yet. What do you think is the greatest benefit of having a PI planning? What is the greatest benefit? My goodness. So there are many benefits of PI planning. If you're asking my personal opinion, the biggest benefit for me is to be able to meet people that you never meet, right? You're doing PI planning because you have a lot of people. In multiple teams. That you work with pretty much daily, right? But you don't meet them because they're distributed and they're all over the place. That's a big benefit that you actually get to meet with people. You get to hang out with them from those relationships. That for me is invaluable. That's the personally for me, that is the biggest benefit. But for PI planning as an event, what are, what are some of the other benefits, right? For the team members, the leadership management Anybody, really. The whole premise behind PI planning is periodically we all get together. It used to be in person, but you know, it doesn't matter. It's hybrid these days. We all get together and we plan out collectively the work ahead for a period of time. Let's say three months, right? SAFe recommends PI planning for five. Sprints if you're doing two weeks sprints, some teams might do three weeks sprints. So they're saying well about three three months. You're right. So you're gonna do a cadence of every three months, everyone gets together, and again, safe says two days, you're doing four. Yeah. So let's say two, But then they leave the door open for longer P. I. planning if you need it. sorry, since, since you're selling me that's the point of the podcast on P. I. planning., I want to interject and ask questions occasionally, which is, so you're basically doing quarterly planning and you're playing five sprints, but I happen to notice that There are six potential sprints within a quarter for quarterly planning. So what happens to that last? It's a good question. Uh, PI planning is the is the name given to this planning exercise by scaled agile, but even before that the quarterly planning was still in. Play, right? It was called B. R. P. Or big room planning. Sure. So yes, you've observed very astutely. There is an extra sprint in there. So what safe is saying is that last sprint is your I. P. Sprint. It's your innovation and planning sprint. So during that sprint, team members don't actually work on the regular stuff that they did in previous prints, but they innovate. They learn the experiment. They learn new technology, maybe, and they plan ahead. So if you notice, the PI planning event falls in that sprint, right? It falls in the IP sprint. That way, you can serve the other sprints for regular development work. So that's the reason why there's that extra sprint. Yeah, that makes sense. slowing down to get together to plan and to, to meet together and go back into like business objective mode. That makes sense. It I don't know about two weeks. I think of all the organizations I've worked with, like. Like stopping development efforts for two weeks. That, that would be a a huge ask. Well, that's the theory, right? The two weeks is the theory in practice. What happens is there is some work left over. They didn't finish in the previous sprints, so they continue on. That's part of it. The other part of it is. It's not just for experimentation and learning that that last sprint is also for planning ahead for P. I. Planning. It's doing the planning before you get into P. I. Planning. So there's quite a lot of work that needs to happen there. You have to have your objectives ready. Leadership has to get their vision ready that they can share with the teams, right? The architects have to get their high level architectural diagrams ready. Product folks need to get their proposals ready that they're pitching. Right. So all of that preparation work happens during that time. I'm not saying it starts during that time. It's supposed to be continuous, but you get in full readiness mode during that time. That's the idea. Okay. So I'm a product manager and we're having PI planning what do I have to bring with me? okay, Jessica, you're the product manager now. I need to be able to point that like going in the vein of the last podcast that we recorded, which might be the next podcast. I'm not really sure. That's, that's what I got out of that whole podcast, by the way, is I need to blame somebody. If I'm saying like You're the product manager. I know that my teams are going to need product goals, business goals, objectives. Going into the PI planning to figure out how to solution and whatnot. Like I assumed there's going to be a lot of homework on your plate to go into. What do I expect my product people to bring to this? Like I will, what homework do they need to be doing in this two weeks that we give them? Quote, away from doing real work like, well, this is part of the real work. So don't think about this as just something that starts discreetly during that time and finishes prior to PI planning. This is part of the work. They should be doing this all the time. What they should be doing is preparing their epics. They should be creating their lean business cases, right? Which detail out what they're trying to achieve. What it's going to cost if they know that what the size of it is, gut feel and what is the need? How many customers will this impact? So ROI conversations. These things happen during in this document during the PI itself. So in the last two weeks, In that last sprint, what they're doing is solidifying all of that, and they are getting ready with potentially even with some features that they've defined out of those epics that they can bring into PI planning. So the whole point is you bring everything you need into PI planning so that you can have conversations with. Management, leadership, your, your peers, your other product people, and say, this is what we're doing. I need this here, and somebody could say, well, you're dependent on me for that. So in order for me to get you that, I need to do my piece before that, but we can't. So we'll give you that two weeks later, which means a sprint later. And then you can you can change the plan. That's the idea. So they need to bring all of these things which, which is a lot actually, because you've got the LBCs that are approved. So prior to they becoming approved, what you have to do is get them ready, right? Get with leadership. Yep. Pitch all of those things, have them basically commit funding, now, depending on which configuration of SAFE you're practicing, there might be more. There might be a layer above that, which is your LPM, the Lean Portfolio Management. Folks, they are the ones perhaps that you have to pitch your LBC to, right. And they will decide to fund portfolios according to their strategic objectives. Can I pause you at this point? Because I want to ask , in the course of my normal product management activities that I do as part of my job I am constantly pitching new directions, right. I understand like larger organizations. It needs to be more formal. It needs to be written down It needs to be in a document form where people can read it You distribute it to people who maybe can't attend your meetings completely understood. There's more bureaucracy It's just a lot of larger organization more stakeholders. I understand. That's not what i'm pushing back against What i'm pushing back against is when I go to my panel the the portfolio level maybe i'm not in control of funding. Maybe the portfolio level they're in charge of funding Yep I'm pitching to them, so I'm creating a new document, I want to do this new thing, I want to take my product in new, interesting directions, or whatever. Am I bringing them as part of that business case the experiments that we're going to try that show that there's signal here? To try to get money to to do those experiments. Is that is that all inside of the lbc? Is it lbc? Is that the right? Lbc for me is like rap lyrics from the 90s. Like I can you tell me what that stands for? Yes, lbc stands for lean business case. Okay So to answer your question, right? It depends So it it depends because maybe your whole lbc is We're gonna try to figure out if this is a good thing to do for our customers. Is there a demand? And to do that, there's a certain Cost and that's what you're pitching or you could say here's what I have already done in the past. I have solid signals Here's proof of that and I want to take that further now and actually have a product right? So then you're pitching a bigger LBC, but it's underpinned by the work that you've already done They should ask you for all of those things. where I can kind of crowbar myself into that is I like, I've already observed this evidence out of user behavior for what I can see. You know, in logs or user feedback, stuff like that. And here are the things that I think we should try, because I, I I'm trying , to fit safe PI planning. This is. It's this six week set in concrete, set in stone, chisel into stone and totally permanent. Can't change it I know it's not really that way, but that's the way I'm perceiving. If you're making me plan six weeks out I'm perceiving it as you're setting in stone my objectives, regardless of where the evidence is taking me. But I, I'm basically pitching, this is where I want to go in the next quarter. So Jessica, I'm, I'm, I'm framing all this I'm bringing all this up to say. I'm assuming your business has a strategy. I'm assuming your business has goals. I'm going to tell you what I would try to do in normal product management. And then you tell me if say supports this, right? I would come with a list of experiments. We think we can put the evidence that we have with goals that we have and figure out a new direction. The business is on board with it, at least somewhat on board with it. These are the experiments we're going to try in this next six weeks and the ones that work out, we're going to just swing them right into active development and make them real things. The ones that don't work, we're going to pivot and try different things. It's a choose your own adventure cause that, that's my big pushback on the, on the big room planning is, You don't want to explore every potential path, right? Yeah, and you don't have to do that, right? So people that are looking at your your pitch or pitches They're not gonna fund every single thing that's pitched at them because they don't have infinite budget They're gonna they're gonna have to feel comfortable Right funding something now, it's on you to convince them right so you can do that but to your point about the granularity of it Your lbc is simply a one pager one to two page max. That's all it is and this is to say here's what we're doing. Here's why we're doing it Here's for whom we're doing this and if they buy into that Then you can go ahead and say okay I'm for this particular pi three months of that big lbc which might take more than one pi Huge epics do take longer. You can say, I'm going to do this piece. Right? And usually leadership will say Okay. Because they trust you. You're the product person. Now it's up to you to go figure out what are your Dependencies on others to get that piece done. My mind went to stories almost when you said little the adventure game maze of twisty little passages yeah, you don't have to say I'm going to have to go passage a or passage B or like, I like your reference to the adventure game. Cause I go back to our lizards and wizards. I like that. Um, Yeah. So they're not interested in that level because you don't even know how many passages you're going to have to use the metaphor. So Jessica, you're a scrum master on these teams. I am, yes, I'm a scrum master on these teams. So we did all the pre planning work. So we're walking into it ready with our objectives, dependencies called out as well as risks. Okay. So objectives, dependencies. So, so you have the business objectives, which includes the business cases. Yes. This is like planning, but with extra stress. If I could write a one pager about what we're about to go into it would be, I would go right back to Roger Martin playing to win, where to play, how to win. I would want my business case to just clearly say like where to play this market, how to win this evidence, basically, for this market, for these customers, these people, these personas, right. Sure. This is how we win. And I would pitch it to my team like that and let the scrum master and the team take it away from there. Yeah, I agree. I think that's a good It is very flexible. A couple of other things that that leadership will be looking for when you pitch that LBC is, what are some of the risks that you've taken? Come across, or thought about, assumptions, right? And how do you plan to test those assumptions, right? I mean, these are normal things. You know, I mean, you're saying that they're normal things, but a lot of people skip over tell me what the assumptions are, tell me what risks that you're taking on, and the larger the organization you get, the less the risk. tolerance for risk that you get. The stakes are bigger. Well, I mean, maybe, maybe the stakes are bigger, but also how can I say the, the, the organization may not have the best outlook on failure. From failure. They may not take the right message. Oh good, I jotted that down. There's a couple things I want to revisit that you all mentioned. So one of them is missed objectives, right? So at the end, we always discuss what was missed. From your experience, how has leadership handled missed objectives? That's a good question. There are missed objectives more often than not, right? And so there's many reasons why. You need to figure out what happened here? Why did we miss it? And that, that's a conversation to have with your teams to say, well, we just over ambitious, right? And we took on too much, or maybe we weren't, we took on what we thought would be reasonably delivered. But then what happened is we had three team members out or whatever it is, right? Life happens. So there's reasons why, or other things that happen okay. Everything went well except we had to pivot to this three or four production critical issues that the team came across right So there's reasons why you don't meet your objectives and do your retros and figure that out and then Position that as this is why what happened happened as well as here's how we're gonna avoid this from happening again And when leadership hear that they don't understand Sure. Right. Because they, they know it's not a guarantee that you're gonna meet, meet all the objectives. I will say that one of the anomalies, one of the anti-patterns I see here is people say, well, we're gonna take on these objectives, but we'll leave ourselves a buffer as we like to feel comfortable, right? Yeah. So we're gonna, we're gonna say out of the, let's say 10 objectives, we'll call two of those stretch objectives. Right? And that way we're not committing to those, right?'cause Safe says you don't have to commit, which is true. Safe does say that. But that's not quite right because you don't take on objectives and then call them stretches because you want to feel comfortable, right? You call them stretches because you can see there's major dependencies on those two. So there's a risk there. And that's the reason why they're stretches. I have a tough time talking about stretch goals. Because in my normal work, I would never take on a goal for my team, like a sprint goal. If the team didn't have everything they could achieve the goal by themselves. I would never take on a goal that relied on Something else like a dependency that the team couldn't do. You know what I mean? I would say, well, we won't take this on as a goal for the team until after the dependency is resolved. Maybe the resolution of the dependency is a goal in and of itself I set my sprint goal from the viewpoint of if I were to go back to the business and say, if I could only deliver one thing in this sprint. What would you outline as the absolute highest priority, most critical thing that we must do? And the business usually can answer that question. I never set stretch goals because I just, I'd see them abused too much. I just, I don't feel that's a great tool. So it's a couple of comments on that, right? One is Your reference was at the sprint goal. Here, business objectives in PI planning are at a higher level of abstraction, right? They're much higher. They're not even at the feature level. Perhaps it's a stretch goal because now why would you put it into the PI? That could be the question you could ask because you have dependencies, right? Well, these dependencies are such that teams that are planning in the PI event believe they can work out. That's one scenario. The other scenario is, well, so they're optimistic, right? But they're not certain. That's why it's a stretch goal. But the other scenario is, these dependencies are external. With a different vendor or whatever it is, then we got to get this new tool in. Well, it's not just as simple as it's going to Walmart and buying it. You have to procure that. So all of that has to happen. And the timeline on that is flexible. The other thing that I see often included as stretch goals are tech net issues. So we're going to work on what we really need to build, but right, we also need to get some of this tech net driven down and that's fine. The thing that people miss sometimes is they say, Tech debt reduction is a stretch goal. To me, that's a purposeful willful decision to do something about your tech debt. And so it shouldn't be based on if we have time. You don't take on a goal and make it a stretch goal in case we have time. We might get tailwind and we have time so we can get this done. They're saying only make stretch goals, those goals that have substantial risk. That of finishing them. Yeah. Right. So there's a scoring system in place as well for the teams that for business value, et cetera, stretch goals do accrue value if you deliver them. But if you don't, they're not part of your commitment. So there's some safety there for the teams, right? Yeah. And I want to ask about that. So you're saying stretch goals, they're synonymous with uncommitted objectives, right? Yeah. The. Uncommitted objectives are the same thing as what we're saying stretch goals in this in this conversation. Yeah, right So we're saying they're more maybe nice to have there are items that have dependencies on it But really we're saying that they're the lower priority of all the objectives Well, so first of all, they may not be nice to have they may be must haves right? It's just that they're risky right now From what we've seen on the ROAM board, there's risks. We think we can resolve those in the next three weeks, but we're not certain about that. Right. So that's, that's one part of it. Some of those uncommitted objectives are the lower priority ones, right? It's not necessarily true They might be high priority. There might be eights and nines or even tens But they're risky. The teams are saying we understand the priority, but there's risk here, right? So that being the case, we cannot fully commit to delivering this because of that risk. So you'll see on the chart committed ones at the top, uncommitted at the bottom, and some of those in the priority listing might be high as well, right? Interesting. So how do you think it will be perceived if the team meets an uncommitted goal but doesn't meet their committed goals? So Look at each of those almost in isolation, an uncommitted goal that was not a sorry, a goal that was committed to that they didn't meet. They could miss for multiple reasons. We talked about earlier, right? So it could be because they were overambitious. A new risk came about in the P. I. That they didn't meet. Anticipate they ran into a roadblock, right? So there's all these different reasons why the team could miss a committed objective. Now flip side of that uncommitted objective they can get through because they thought they could deliver it, but they just were not a hundred percent. Sure. Like not, I don't mean to be like absolute certain, but they had this dependency issue and they felt like that may not get resolved during the PI. It just happens that they managed to do it. So that's fine. Yeah. Those aren't related. It's not like you have to do all the committed ones. And it looks bad if you just do an uncommitted and miss one of the committed ones, treat those on their own merit. They're all separate. Well, I mean this is a good question though, that Jessica's just posed that the end of your sprint happens. You missed a committed goal. Does your committed goal move to the next sprint? And now you've basically pushed every other committed goal from previous sprints off. Yeah, possibly. I mean, the, the goals then need to be re evaluated for the next PI. Is it still a goal? If it is where is it in the order of prioritization for the next PI? That's a great like real world scenario because in my, in my experience with SAFe, which I brought up on the podcast before, so it's not, it should not be shocking to anyone. Like what happened was management came down And just gave everyone there like, Hey, sprint one, you're going to have this objective and sprint two, you're gonna have this objective. And then the teams really had no choice. And like after the end of sprint one, like they didn't hit any of the objectives, they didn't deliver anything and all that work moved into sprint two. So sprint two had the goal of sprint one and sprint two. And it was a cascading, slowly moving train wreck that just got worse and worse and worse. Every sprint that went along, I can't really blame safe for that failure because they weren't doing safe, right? Because the company was, yeah, because the company was a, the company was a giant train wreck anyway, the point of me bringing this up in addition to it being completely hilarious is you're going to miss Sprint Goals. And then, and then that stuff's going to roll to the next sprint to say, Hey, it's still important. We have to do this because other teams are relying on this. Right. And we're going to carry it into the next sprint. I mean, the issue there is you have, I mean, you have potentially like a hundred plus people delivering like this. So if multiple teams are missing what they committed to and you're pushing work to the next sprint, stuff is going to move. the issue I have with PI planning is and I'll, I'll invite you to push back against this. Every PI plan that I've seen is set up where if one team misses their goal, the whole agile release train is a house of cards that will start slowly falling down when one team misses and then it collapses because another team has dependencies on that and we got red string and everything falls apart and everyone's fighting. Yeah, I, I've seen that as well. I have to confess I've seen it, but they're not doing it right. Okay. They're not doing it right. The example you cited earlier where leadership girl, you said management, actually, management came in and said, you had these dates. You're going to work on this. This thing is going to work on that. At that point, they're not doing safe. Safe says. P. I. Planning is done by those that are doing the work, which is teams, not management. So I've seen this all over the place where people say, well, we tried safe and this is what we end up with. Well, you're not doing safe, right? To begin with, this is analogous to people saying, well spending money. Agile doesn't work here. Scrum doesn't work here. We're not doing it right, quite possibly. It, those companies or those teams are, they're setting up such that a, an objective that's missed by a team impacts everybody, the house of cards scenario, they're definitely not doing safe right. Objectives are fluid, they're at the top, they're high level work item. They need to be broken down into epics and then features. So if a team misses, they're Their sprint goal. They might miss their feature. Let's say during the PI again. Think about three months, right? They'll miss a feature that doesn't mean the whole objective which has multiple features which have multiple epics above them Right that the whole thing is is Falling down. It's not. It's not falling down. What's happened is there's a reshuffle going on there and now it's up to the people that are planning those things. The RTEs will help here, STEs, depending on what flavor of SAFe you have. To manage those dependencies. You should be talking to those teams every single week You should be having those sync events to talk about these to prevent that from happening, but it can't be avoided completely. But usually when it happens and you're doing safe, right? You're practicing it properly then it's basically an external influence or an internal influence like a Management decision that says yeah, I know you planned all that stuff but We have this conference coming. We need this now, right? Then, yeah, you're going to miss your objectives, but you know why. And you can you can stand behind that, right? If it's an external one, you can still stand behind it and say, It was not in our control, and we didn't foresee this happening, right? I've seen those symptoms all over, but they're not doing it right. Interesting. At the very beginning of this conversation, you talked about one of the benefits of having PI planning is getting everyone finally together because usually we're all remote, right? So there's a benefit to that. However, I personally haven't heard that very often. I heard it's more hybrid. Right? Yeah. And and sometimes it's virtual all together, right? If there's not a budget to get people together, they just do virtual. So I wanted to bring that back up and ask the question, how beneficial do you think it is when it's hybrid and virtual versus in person? Well, certainly in person is the most beneficial. Obviously, I don't think there's any arguing there, right? I mean, Face to face, but you know, hybrid is better than all virtual because at least you've got some people that are meeting now. Yes. Budgets. I understand. Right. But maybe you can plan it such that for a PI, you get your key people together. Let's say key people, meaning you have product managers together. Maybe scrum masters can come depending on how much budget you have. If you have people overseas. Right. Typically they feel like they're kind of left out because they're just on a call. And these are long days. So one option is to bring somebody in. Maybe you bring in a, like a tech lead or an architect who's remote, fly them in for a PI planning, and then they go back. And they can talk to their teams so they feel involved. They can say, well, when I talk to so and so, it's all relationship building. Going back to what I was saying at the beginning. So at least that person got a chance to meet people right in person. But if if it is completely remote, then the benefits are questionable. Right, it's still okay because you can see people and you can say oh yeah, that person's on this team. You get to learn people and what teams they belong on, especially on large arts. So there is some benefit there, but there are difficulties as well because when you're on a call, only one person speaking at a time and that's okay. It should be that way. But if you're in person, your other senses are engaged. You hear. Conversations all around, right? You can hear somebody saying something and you pick up on it and say, I'm going to go talk to them about that later, your eyes are taking in the whole thing. You're watching body language. None of that is there. If you're remote, especially if you're not mandating cameras on, so it's not that effective. If you're completely remote. It's better to be hybrid, but it's best to be in person again, in the confines of whatever budget you have, Yeah. And I'm, I'm sure it's tough doing it fully virtual too, because we're just zoom burnout, right? We're just sitting there for hours. You're at home, so you're probably going to get up, get a snack, right? You're not as engaged. Yeah. Yeah, but even in person, it's hard for an RTE to kind of conduct this whole thing. But if they're in person, they can have rules. They can say in the room whoever wants to speak Go like this, or if she or he or she wants to intervene when someone's speaking, they go like this, right? And people can see that happening. You can't really. And I know there's emojis and all of this stuff inside reactions, but not everyone's looking for that. Yeah, people use backgrounds and you kind of lose that, right? No, I'm already with you on this one. even if I'm doing quarterly, quarterly planning, and we're not even talking about safe here. BRP, like I want to be in the same room with everyone I'm planning with. I want to be able to read how they're reacting to what I'm saying. And then immediately ask them like, Hey, you don't seem comfortable with this bet that we're making. Like what evidence can we bring to you to make you more comfortable? Or, Hey, there's no evidence you can bring. Or what risks are you seeing that I'm not? That's right. That's right. Or what are you seeing that I'm not seeing? And like, let's, let's talk about it. Let's get it I think you can do all this remote. I don't think any of this I don't think there's any cryptic messages that you get in person that you don't get remote. I just think it takes way longer and you need to go seek somebody with advanced facilitation skills to really draw people into the conversation in a remote setting, whereas in person, it's far easier to do that. It's easier to see someone who's sitting back at the table. somewhat disengaged and draw them into the, Hey, what do you think about this? Hey, I haven't heard your opinion. What's your opinion on this? And just clear the floor and keep everyone silent until we really draw out the the introverts or the people that aren't like, I, I was in a culture, a company culture where a lot of people, were introverts. A lot of people in the company did not do well with brand new details, brand new documents that they're seeing for the first time. Yeah, and you're asking them like, what do you think about this? Like they're just overwhelmed. They need that like, hey man I need to like take this and I need to read it and I need like give me a couple hours To really absorb this to figure out what what my actual opinion is They needed some time. That was just the personalities of the culture put together. You can't put them on the spot But I mean, in a, in a meeting where we're all in the room, you can say like, Hey, like we're going to give everyone 15 minutes, read through the document in your own time, nobody talks. If you read the Working Backwards book, the whole process of the Amazon six pager, where they all sit in a room and say nothing and they say nothing for the first, whatever, 20 minutes or whatever it is, because the point of that time is you're introduced to this document, the six page document, that's just chock full of new ideas, new concepts. And at the end, it has an appendix that sends you to all over the company, to different places to read about the evidence and the trials and the experiments and things that are brand new to you. You're given an amount of time in the meeting because. We could say, just read the document before you step in the meeting. Of course why wouldn't you do that? But the reality is we're all busy. we know that some people are not going to do it. So we're going to carve out time in this meeting. We all agree. It's super important for everyone to come online with the business case. That's the point of the sick pager. Everyone who reads a sick pager can completely understand the business case. And by the time they're done in that, in that reading time, they've read through the business case. They've annotated questions in the margins. They've marked up their copy of the document or whatever. And now, the rest of the meeting, I don't remember if it was two hours, I don't remember how long it is. The rest of the meeting is dedicated to talking through all of the notes and all the reservations and all the challenges and all that kind of stuff. Really beating up the document. I feel like so much more effective doing it that way because like you said you actually gave people the time instead of Say make this make your own time like do it in your own time That doesn't mean you have 20 minutes less work to do elsewhere again Again, as the the product manager in me says it is too important to assume That everyone gets the business case behind why we're doing what we're doing This is why one of the things I really like about SAFe is the break between day one and day two. Where you bring the management in. Yep. To score what the teams have done. I'm going to put the safe. Agendas for day one, day two on the screen right now. So maybe you can walk me through the day one, day two agendas. Yeah, so day one of PI planning begins with leadership providing the business context and their vision. That way everybody's bought into it, right? So this is where we're going over the next three months and beyond. So it's not just like three months. It's, this is our vision for the product. This is what we're doing. And it's an hour, but often there's questions so they can answer questions. Right. And there may be multiple leaders presenting this. I would say like business contacts for the next six weeks. In an hour like that. That is not by no stretch of the imagination. Is that a long amount? Exactly. I agree. I agree with you. And again, depends on the level of granularity, right? These guys are senior leaders. They are possibly the sponsors as well, right? So it's not very detailed. But you know, then you have the next layer down in the next layer. So sometimes the architects pipe up with questions and so on. So once the business context is done, then you get the architects to come up. These are your EAs, your enterprise architects, that typically lead it, but it can be then they can pass the baton to the other architects. Okay. So product solution and vision. Now, it's not just architects, it's also your business cPOs or product people that say here, now that we know the vision, this is why we're doing what we're doing. It's for these customers, et cetera. And that is an hour and a half. These times are indications. They, they can be flexed, right? Sure. And then we have an hour of the architect vision and dev practices. So what's happened way before all of this is the planning that we spoke of earlier. So the architects will have an architectural runway that they've prepared, which they share with the teams. Right. So that's, what's happening here and development practices all of that. So that, that's why it's a, it's an hour. We have planning, context and lunch planning. Context here is really the product managers looking at what they came in with, with regard to epics and features. And they're discussing this at a high level. Again, you're not really deep diving here yet. Typically that happens over lunch as well. Right. So that's why it's like 1130 to one. And then the teams now all morning long, they've heard the vision, the architecture revision, et cetera. Can I ask you about planning context and lunch, the planning context? So is that, is that the team like grabbing individual product managers or individual members of leadership and asking like, Hey, like you brought this up in your slides. Can we ask you more about that? The planning context is where the product managers, typically it is the product managers. They walk through the slides that they have, that they've prepared. Each of them do this. And so the other product managers are there as well looking at what's, what's going on with the overall solution. The team members can ask questions throughout, that's fine, but they haven't broken off into their own teams yet. This is everyone's still together until after lunch. This is still goal level. Is that, this is no, this is now at the PI level. So over the next three months, right here are the. Epics that we're going to work on here are the features that fulfill the epics. Sure. So remember what's happened here. We started with the vision, very high level, right? And then it went down and down more and down more. So that's where we're at now. We're at feature level. So, yeah, I try to write my epics in a way where they are delivering business outcomes rather than like feature delivery. Yep. So, so I, I guess, if the planning context is, Hey, here's these kind of high level, Business outcomes like aid and the team is kind of hooking into kind of feeling out what features will meet my high level objective and asking me questions. Then I understand what this period is for. If it's not that I have no idea what we do other than having free lunch. I have no idea. You know, you're pretty close with that, what you just said, right? Yeah, so the teams again, the teams can ask questions at any point. They're in the room. Okay, everyone's in the room. All right, move us along. So, so after lunch, right, team breakouts, the teams will go into their own little breakouts, they will take the feedback that they were not the feedback, the direction they received, and they will try and break those pieces down into, they'll try and break down the rocks into. You know, stones. And then they'll come back at some point with those, right? So that's, what's happening there and that, and then at four o'clock, according to this timeline at four o'clock, there's a draft plan review. So what is happening in parallel with all of this, the team breakouts is they are creating their features or they're, they're sequencing the features. Taking into account dependencies and whatnot, and they will present a draft plan of how they're going to meet these. In other words, we're going to take this feature. It'll last a sprint and a half, right? And we also have this feature that we're going to start at the same time. Cause we have people to do that, right? And so they'll lay it all out like that. It's still a draft because it's the first time other teams have seen it. So during that time for an hour, they'll present that. And then at the end of the day there'll be a management review for those draft plans, right? The draft plan review is with the teams. Management review is looking at any dependencies, risks, et cetera, that the teams have put on the risk board, the roaming of the board, right? That happens in any problem solving that needs to happen with respect to anything, any problems, right? So you may need to go back to, Leadership there at that point and say right after we thought about this more Our team met with this other team and we feel like this It cannot be done or we can only do a piece of it. Sure, right or we need your help, right? So that's the problem solving piece So that that wraps up day one. Okay, let's stop at day one. So, connect me from the end of day one to the beginning of day two. So we did a management review at the end of day one. I'm gonna go out on a limb and say that sometimes this runs over the time box. And management like you'll say there's a lot of assumptions here. There's a lot of risk things that we're not a hundred percent confident that things or we're not even like 70 percent confident that things are going to stop here. Like there's a lot of potential for a train wreck to happen. Kind of what I said earlier in the podcast. Right. Do we want to like de risk ourselves kind of scope down our objectives and let management kind of, Pick the, the, the best of what they want. So, first of all, you're right about one thing you started off with this runs over. This is idealistic tips. Unfortunately, this runs right into cocktail hour, much to my annoyance, but anyway, anyway, so this is not the time to de risk yet. This, this is the time. To get help and then think about things, sleep on it for the night, right? Come back, make the adjustments in the morning and present those and say, based on what we discussed yesterday, here's how we reshuffled everything. We've de scoped some of these things, right? And here's our. Adjusted plan so to speak. Okay So that's the eight to nine the point there is to have leadership in For their visibility and to get their input on what they're doing So they may say for example, i'll give an example So day two, eight to nine, right? You could say yesterday, dear leaders, we talked about these things today. We don't think we can do this one piece. So they could say, okay, you said it was very important though, right? And we're telling you right now, it can't be done. So then what leadership will do is they'll say, well, can you do any of it? They might say that, and they might say let's de scope, right? And the de scoping is presented at planning adjustment. Okay. Based on yesterday's conversation, we took out this piece, but we can do these other pieces. Or we took out that whole thing. So, so is 8 o'clock to 9 o'clock on day two, this is at a goal level? On day one. One o'clock to four o'clock, you've done your, your low level analysis, basically. That's, that's the way this reads to me. And then you come back to management and you say, okay, here's the things that seem high risk. Let's, let's take hour five to six and let's be civil about this and say, we're not working past six because we all got to get to happy hour. We come back at eight o'clock bright and ready to commit the next day maybe some of us with hangovers and say, here are the trade offs in the goals of what we have to have versus what's nice versus what's a stretch goal and whatnot. And then the team takes that adjustment. Into their next breakout session where we say, okay, given that we can flex these things, but we can't flex these things. Here's how we would change our low level plans that I get. That's exactly what the purpose is. So you nailed it right there. Yes. Okay. The other thing that teams are doing is on those things where there's no ambiguity, they are feeling pretty good about that, right? They can start creating stories. Now, remember. This is not in the next PI yet. So these stories don't have a whole lot of they won't maybe have a season there fully. There'll be shell stories, but at least they'll capture the understanding of to deliver a feature. We need these five, six stories. Let's say so they can start breaking those out and say, we've got to get these done and start putting those stickies, virtual stickies in the. You know, in sprint one of the next P. I. Sure. Right. So that's that. And that continues. That exercise next morning, 9 to 11. Okay. Now, 11 to one again, it's a working lunch. For the second day running there is a final plan. Remember the first day was a draft plan. Now you've updated it So the final plan is then presented to the leaders and after that We talk about the risks, the art risks, right? So, so your final plan review, your art risk review, I'm sorry, like I'm assuming this is where you have your red string review. Yeah. Thi this is where the planning board is looked at with regard to dependencies. Sure. So that happens one to two and you pretty much are done except for two other things. Tell me, tell me about the confidence. What is the confidence vote? The, is that every team giving a big thumbs up or a thumbs down? E exactly. That's what it's, so, so we were talking about how is it effect more effective in person? I like it in person because we're all in the room. Sure. And one of the things with this confidence vote that I like to do is to say. Okay. Right. We're going to have It's a scale of one to five. The confidence scale is right. So we can say, well, those people that feel like their confidence level is only a one, which means this is going to be a tough PI. We can't really deliver much, right? You go over in that corner, literally like walk over there. Oh, right. Yeah. That's what I do. And I say, twos walk over here. Three's over here. Four's over there. Fives stay in the middle numbers can be shifted around I like to do that because it gets people thinking and they walk get you know, you can't do that virtually So now I use a board and we use like my row or mural or whatever so the confidence vote is just that people doing the work do the voting and they will vote based on their individual confidence on Collective art meeting the goal, right? It's not like okay You I, as a tester, think I can do my job, so I'll give it a five. It's not like that for the art. Do you think we're going to meet our objectives overall? So it's pretty high level, holistic, right? But it's very revealing because you can see the clusters. Well, you can see the clusters on a board too, I guess. But in practice, in the room, you can see that where are the most people. I had a question about the confidence vote because you said you, you put people in different sides of the room. I'm just curious, what is the benefit of doing that? Well, it's just, it's gets people out of their chairs and they move to a corner. They're committing that that is my vote. So what happens if you do it on a board? You can't see who's voting. So they're gonna wait and wait. And then they'll see more people are like at a three. And they go, yeah, I'm not gonna risk myself. So in practice, once you walk over there, Let's say it's me. I walk over to that corner and I see more people over there. I'm less likely to just get up and walk over because everyone can see that I've just changed my mind. Interesting. Okay. Yeah, I was curious if you want all the three's to communicate with each other and discuss why they both thought it was a three. We don't want to necessarily do that. This is just the classification exercise for now, right? So we just want to say, well, how many threes do we have, right? And the reason why it's an hour and a quarter is because this whole thing that I just mentioned, whether you do it virtually or in practice, it's only five minutes. Sure. The rest of the time is spent looking at And this is what the RTE does. Looking at where is the concentration of the votes. If most people are at a 2, that doesn't bode well for the art. So, let's say it's all over usually it's a fairly good distribution. Now, I'm gonna look at, if I was an RTE, I would look at people that have voted a 1. And I will ask the question, what will it take to get you to a two? Why is it a one for you? And they'll say, whatever they say, right. They'll say, well, if I can only have you know, access to architects, it'll be much better. Yeah. Okay. Yeah. So as an RTE, I write that down. Because that's fixable, right? I can fix that. I can get that person from a one to a two. Now, you don't want to do that for every single number. People that are at fives, stay at fives, that's fine. Fours. But, look at, you'll have a few people at the low end of the spectrum, and you can talk to them and say, why is it like that? Can we change that? Can we get a few people over from a one to a two or a two to a three? Right? I mean, I But I love that as a facilitation technique of what will it take you go to your threes? What will it take to get you to a four? That's right And like I would imagine I would imagine one of these plans like it's gonna be Hey, we need to have less risks. We need to have less red string. We need less dependencies We need to be sure about these experiments, okay It varies, it runs the whole gamut. Some people say that, some people will say, I'm, I'm okay, but I'm at a three because I think we've just taken on too much work. We should take on less. We did that last PI didn't work out so good. Great input. And that's a great thing to know at that point, right. Rather than kick off the PI. So RTEs, RTEs will do that. And at some point they'll say, okay it's the average is roughly. And I just look at heads. Yeah, that's good. We're, we're mostly at fours and fives. We're good. They could still leave people in ones. Cause they won't move. Some people will be stubborn. And they say. Yeah, I, I see what you're saying, but that's still a one for me. Fine. Leave them. Yeah. Right. So that's what happens during that, that exercise. Well, you have this two 15 to question mark block of plan rework where you can make those trade offs. my three say it'll take this. My two say they can take this. Maybe we can reduce some dependencies and we'll these will be objectives. Now that we're stretch goals, we're going to punch them up the main goals and we'll maybe kick some stuff out of scope. And that gets us all to to a general level of a four across the whole PI I'm on board with that. I like that as a, I mean, I could very clearly see that requiring, like you're already at two 15 on the second day. At this point, people have been in the room since eight. They took lunch in the rooms. They haven't left the room for like six hours. I could easily see this kicking off to another day, but I, I also could see like, Hey, let's just move let's just cut scope, do whatever to get up to a confidence level and just You know, let's just move. Let's just go. Yeah. Yeah, all of that. Right. I mean, you're right. People are tired by that time. You know, if you're in person or hybrid, I mean, some people flew in before day one. So they're pretty tired. Sure. But yeah, the plan rework time to 15 to whenever is exactly that is figuring out how, how can we make our plan sharper, based on what we've done the two days. And when they're done with that, right. There is a retrospective, there should be a retrospective, and this is on the PI exercise, the last two days. How do we do? What do we not like? Typical things you talk about in retrospective. And going forward Is this location good for us? Like it's all of those things, right? Logistical things. I would like, I want to bring up you're going to do a retrospective with a hundred something people in the room. Yeah. So that's a good question. How does that work? Right. Some, some people do it poorly. Some people do it better. I like to have a retrospective board. I'd like to have one board, first of all, for whole PI planning. I don't like these 15 boards that people use. These people get lost. I would want one board. I want, I want one board. So I have a single board, we happen to use Miro, you could use Miro, it doesn't matter, right? Where you have all the activity that happens. But way over to the right, I have the ROAM board. For the risks and underneath that I have the retro board and I tell people way before this I tell people before they come out to PI planning I introduced the board and it says how the board is gonna be used right and Throughout the whole PI planning exercise if there's anything that someone says yeah, this stinks. I don't like it or I really like this, right? Put it on the board. It's already there. I'm not going to ask you to do a sprint type retro where you brainstorm and do all of that. No one has time for that. They're tired, you want to go home, right? So collect all the evidence before then. And then, spend, literally this only takes seven minutes. Right? Because the first two minutes are spent shouting out kudos, etc. And then the rest of the five minutes are walking through the stickies. And I want leadership, by the way, who are keen to get the hell out of there. I want leadership to stay through the end of that because some of the retro items impact them. I'll give you an example. One of my team said, and this, this happened to be a good, I also have a bad, right? So the good example is they said, it was great that leadership was in the room for a for a long time. So we can ask questions, but you need to hear this leaders. Now, the other side of it was leadership kept coming into the room when we were doing our team breakouts, and they were asking why, why aren't you putting estimates on stories? Well, we don't know enough yet to put estimates on. Why are they delving that deep? Right? So they need to hear that. The teams aren't going to tell them that. But during the retro, I would say leadership shouldn't be in the room when you're doing that. If they're not in the room, leaders aren't hearing that. They need to be there. They need to be in the retrospective? Yes. It's so funny because at a team level, we don't want the leaders in the retro. That's right. At the team level, you don't. But this impacts them. They're part of the team, in quotes, that plans the PI. They're in there. They're impacted. This is a retro for the planning of the PI. Correct. Okay, okay. So from that perspective, I really think that leadership's input is super valuable. The product manager I want to take the temperature of whether leadership feels that the whole program really has understood their intent and is on the same page with them and it feels the same sense of urgency. And like also, that's the product manager in me. But also the ridiculous side of me is like, I I know that leadership is like they're like kids on the internet. Like they, like you got 10 seconds to grab their attention in a video, or they're going to click the next video. Like they, like you got to keep them engaged at all times. Or they're gonna cash out. So I really like the idea of keeping them interested in what the teams are doing and I want to find places to keep them contributing to what the teams are doing. I have high confidence that the teams are going to contribute. But I'm, I'm worried that they're just going to say like, Oh, I'm not seeing, I'm not seeing myself in these, in these suggestions. I'm going to leave. I'm going to cash out mentally. Well, there's two, two benefits of keeping leadership you know present in these retros, right? One is so they know what the retro exercise is. Otherwise they're going to say, why is the team sitting around? I get 150 people here, so they need to see that. And then the second side of it is. At the end of this, they could look at it and they could say, Oh, I see the teams have some pain points here. Maybe this location is not the best. This actually happened. One of my teams, they said, can we rotate the locations? Cause you know, we're a global team. So can we just can we go to Denver one day? I can hear that now. It doesn't mean they're going to approve it, but. You know, the teams are feeling these little things, so feel it. And then at the end, right at the end of the retro, when everything's done, I want the leaders to close out. I want the leaders to say great job, everybody. That makes a difference. I agree. Right. So I want leaders to say that. Right. And they'll do the closing. Right. They do the opening, they do the closing. Right. That's good. Yeah. I completely agree. Initially when, when this first happened I thought, I might get pushed back. Cause they're just really itching to get out of there, right? So I thought they're just gonna say great job and that's it. Well, this leader talked for 20 minutes. And sitting there, standing in the back of the room, I had to say, Hey, Wow Yeah, because he was it's like he was just going on and on and on. Yeah, he just felt so Energized and he was more aware of what the teams are experiencing. He'd never been in a retro before So that was like, okay, you know not shocking. The leadership that I talked to on a regular basis, they rarely get to address all of the teams working on their behalf. They rarely get to address them I think of all everyone that has an Azure coaching background, like how important it is to come out to the teams and just. Put yourself out there and say like, Hey everyone, like what you're doing is super valuable and I really appreciate it. And we have all these sessions and we like we're catering all these lunches and we're doing all this stuff. And if you're not if, if you're not happy with any aspect of it, like we're, we're ready to bend over backwards to make sure you have everything you need. Especially with like dependencies and all this everything we talked about, like confidence, that kind of stuff. Yeah. For them to hear it directly from leadership, especially when you start with the business context of like, we're doing this because and here are the reasons and you're basically book ending this session with here's where we could go, should the experiments work out in our favor or whatever. And then if they don't, here's where we might go instead or whatever. To understand that like everything that we're doing in this session like we'll, we'll inspect a quarter from now. And then we'll decide where to go in the market from then. The typical developer on the individual team, you're so focused on the work, you don't get a chance to step back to the point of your leadership. You know what I mean? That's like several steps removed from your day to day work to see the work from the outside. Yeah. That's great. That that that that part is great about this. I like the fact that you know, there's some affirmation from leadership right at the end saying we have confidence in you. We've seen you plan all this workout that we said you need to do at the beginning. We didn't tell you how, you figured that out, at least started to, right? So there's affirmation and commitment. There's perceived commitment by the team members. Yeah. My leadership's behind me. So I think that is super important. I'm turning into a pumpkin. Yeah. But thank you so much for the conversation. I feel well prepared. Yeah. I feel well prepared walking into this PI planning in a couple of weeks. So this was great. Thanks guys. Awesome. Well, listen thank you for staying with us today and let us know in the comments below, if there's anything else you'd like us to talk about, don't forget like, and subscribe.