Episode Transcript
Richard Lawrence: Welcome to the Humanizing Work Show. I'm Richard Lawrence here with Peter Green, and today we're talking about where PI Planning came from, why it's often so painful, and what to do about it.
Peter Green: Spicy topic! Well, I've done what we call big room planning going back, I don't know, maybe 20 years. You get everyone together in a room, you get aligned on the goals, how we might get there, and it can be pretty energizing and provide a lot of insight.
I've used those kind of kickoffs for big two year releases, sometimes for small quarterly initiatives, and I've seen really good results from that process of just getting everybody together, working through how it might go, including one example where we decided to scope the initiative way down towards the end of the day when we realized we can't accomplish the goal of this thing in the time allotted.
The idea of big room planning, I think is really sound. That label, big room planning actually comes from Toyota. So back in the nineties there was this new initiative at Toyota, what they called G 21. The goal of that initiative was to build a car that was twice as fuel efficient as comparable vehicles, but still commercially viable as they manufactured at scale.
And that eventually became the Toyota Prius. The process of how they got there was really interesting. The chief engineer, Takeshi Uchiyamada. I think that's probably pretty close.
Richard: Easy for you to say, Peter.
Peter: Whew. Yeah. The way he approached this was really interesting. He got a cross-functional team together; engineering, sales, manufacturing, and they started iterating on some of the core complexities. Like at the time, they didn't even know what kind of drive train could deliver that kind of fuel efficiency. They didn't know what materials would be evolved. They didn't know how to manufacture it yet. And they used set based concurrent design or engineering where they were testing multiple possible drive trains at the same time, generating data as they went.
So they were just actively working on the complex parts. Uchiyamada called this big room planning or obeya in Japanese. Again, pronunciation, I apologize. Obeya was the Japanese word for big room, and he put all of those folks in the same space and had big visuals up on the wall and the prototypes were sitting on the floor and they would meet as a full program team two, three times a week.
And then as they got closer and closer to manufacturing, that kind of moved to daily. So all of the stuff was in the room that they needed. Then as they reduced the core complexities, like they'd picked the powertrain architecture that was gonna work, they had validated some of the core market and engineering feasibility questions.
Then they actually shifted the location of the room. They moved the obeya to a different place, and it shifted from focusing on answering engineering questions to moving to scaling up manufacturing, and from that collaborative exploration to a more structured planning around production, scale up and delivery.
Richard: It sounds like Toyota moved from what we would call phase two of our CAPED approach, Active Planning to phase three, Analytical Planning, once the system justified it as they resolved the core complexity. They'd already done phase one before this, that Strategic Planning to establish the key goals for the initiative, like we are going to double our fuel efficiency and still make it commercially viable and all of that. That would've been the upfront thing that revealed what the core complexity is.
This is exactly how we advise clients in similar situations to apply the CAPED approach. You can learn more about CAPED on our website, humanizingwork.com/caped C-A-P-E-D, and while you're there, you can register for our upcoming webinar where we walk through the details of how CAPED Works.
Peter: So let's talk about how big room planning became PI Planning. In his Agile requirements book, Dean Leffingwell, who wrote the book and is the author of the SAFe Method, borrowed that term, Big Room Planning, from the Prius example, and he attached it to a quarterly planning event that he calls PI Planning or product increment planning.
Now, Dean borrowed a lot of ideas, including Richard's story splitting patterns in that original book. Many of our clients and audience use either full, safe, or at least the PI planning portion of it. So let's talk about the parts that Dean got wrong and what to do instead.
Richard: As frequently practiced PI planning treats work primarily as complicated. You can do analysis, you can get everything in order. You can recognize the dependencies, make your plan, and go run that plan.
We see extreme examples of this all the time. I think about one client, they literally plan five sprints of work at a time for offshore teams. Everybody in this program is getting together and figuring out the next five sprints. And it's not just generally, 'this is where we're going,' it's 'here's all the things we're going to work on and what order they're in and what they depend on.' And then kind of handing that work off, which is very much an analytical approach to planning, even though they're still facing a lot of complexity in their work that they need to resolve.
I think as an industry, now that SAFe has taken off and become what a lot of people experience at Agile right now, we sort of as an industry took the wrong lesson. If you get everybody together every so often and do some big visual planning, everything's gonna work out. You'll get this hybrid where you thread the needle between long waterfall style planning and just planning an iteration at a time.
But I think the real lesson, if you go back and look at what Toyota was doing with their big room planning, is to do this Active Planning collaboratively and experiment when you're facing complexity, and then move towards more and more predictability, rather than just treating things as predictabile and planning at scale.
The big rooms, the visuals, those help, but they're just the window dressing on what you're doing. It's the behavior of addressing complexity first in a collaborative, cross-functional way that really matters and made a difference.
Peter: It occurs to me as we talk through PI planning, one of the challenges related to PI planning is that you get this big plan locked in and then there's a lot of resistance to making any meaningful change as you iterate. And the core idea behind agile techniques is we do a little slice, learn from it, maybe pivot, change, new information emerges as we build, and there's a lot of resistance to making changes once you've done PI planning. I think there are two contributing factors to that.
One is that if you've spent two full days with a hundred people in a room to create a plan, and then a week later discover the plan's wrong. There's this sunk cost fallacy that comes into play. Like, we put a lot of effort into that. It must be the right thing. In addition, if you know it takes a hundred people two days to get aligned and coordinated and you discover something's wrong, are you really gonna ask a hundred people to come back for two days to update the plan?
So I think there's a lot of reasons just structurally within how SAFe is typically practiced that make it very unlikely that you really get agility within a PI. There are probably great examples where people are the exception to that rule, but I think by far, once a PI plan is locked in, it stays. And that's risky because anytime we're estimating by decomposing, estimating the pieces, and summing them back up, we're taking what the psychologists Kahneman and Tversky called the inside view approach to estimating.
And what they found in their research is that when you take an inside view of estimating, you just miss things. You can't think of everything. No matter how detailed and analytical you are, you can't think of everything because some things are gonna be emergent and you're naturally gonna be optimistic and then end up overcommitting.
So there's a lot of risk to doing planning that way.
Richard: I think that optimism bias that Kahneman and Tversky were talking about also naturally pulls you towards the things that will confirm your optimism. So confirmation bias gets laid on top and there's a tendency to go straight towards the things that you're right about, front load toward the things you're certain about, putting off the things you're less certain about, which is exactly the opposite of how you wanna work if you're going to resolve complexity early. You're pushing complexity away, quite naturally, because we want to prove that the plan is right. We wanna feel like we're making good progress.
And then there's often a org structure problem laid on top of this. We see that plans are even more fragile because complexity spans teams. So you end up spending a lot of PI Planning focusing heavily on dependency management, but then as you get into the work, emergence on one team, one team learns something, the work takes longer than you expected, something new comes up, you get feedback, that emergence ends up having to cascade through the entire work system, and that makes it really hard to predict the effect of something changing, which either leads to chaos or trying to prevent change from happening.
This kind of shift from "what Toyota did" to something that has the mechanics, but sort of misses the point, it actually happened with a lot of things from the Toyota Production and Product Development Systems. As Lean became a big thing, people copied pieces of TPS without the larger system and culture that made it work.
Like one of the most widespread examples of this is manufacturing companies all over adopting Just In Time inventory of parts from Toyota, where you bring down how much inventory you're holding and just have things flow smoothly through the system. Super attractive from an accounting perspective 'cause you're not sitting on all that inventory.
But I think people didn't realize how much the continuous improvement, kaizen approach from the grassroots level built into the Toyota system, enabled them to address root causes for supply issues. And if you don't address those root causes and you have Just In Time, you're super fragile to shortages and production delays.
Peter: Mm-hmm. Yeah. So all the form of Lean without the benefit of it all, the form of Big Room Planning without the benefit of it, in both cases. So what's our advice? Well, I think there are a couple things you can do if you're using PI planning to make it better. When I look at my experience with big room planning, there are three big benefits.
First is alignment. Even the way that PI Planning is laid out, the first couple of presentations are about the vision. What are the big goals for the next quarter? Those are super useful and a good way to spend time together.
Then instead of going out and having everybody start estimating features and mapping dependencies, what we'd recommend is that you identify the core complexities and what your first probe is gonna be.
Third, there is a benefit of social connection, especially across teams. When you work in our team, and Richard works in his team, and this person works in that team, it's very easy over time for our sense of connection to drift, and it starts to be us versus them. Coming back together once a quarter and remembering, oh, these are good people. We can trust them. Oh yeah, I could just reach out if I had a question. I think the social connection is really important.
So focus on those three things: alignment, identifying complexity, and social connection. If you find yourself focusing primarily during PI planning on estimating and dependency mapping, that's a sign that you're assuming everything is predictable. You're analyzing a complex problem, and that's not gonna have good results.
Richard: Yeah. On that social connection advice, Peter, I was talking with a longtime client and friend the other day about hybrid work. This person is in an organization that has gone from fully in person to fully remote with COVID and then, now back to a a few days in the office.
But because this person's team is spread across several different offices in different time zones, everybody goes into the office one or two days a week and gets on Teams calls. And so they're not actually getting the social connection. They're just doing Teams and cubicles.
And we were talking about this and they mentioned one of the best work experiences they'd had was a startup where they did quarterly in person for a couple days for alignment and strategy and social connection, and then worked remotely the rest of the time, connecting with online tools like Slack. And that got the best of both in-person and remote. And now I think a lot of people are living in the worst of in-person and remote.
Peter: One of our favorite clients does a similar thing. They have what they call collab week, where once a month or once a quarter, depending on budget and things, what they're working on, the whole company comes into the office.
It's both social connection, but you also get a chance to work through some of the stuff that's just so much harder to do when you're remote. Working in a room together, tackling complexity is just so much faster. Right?
Richard: And one more piece of advice if you're doing PI Planning. If you take Peter's advice and focus on alignment and identifying complexity and then thinking about what the complexity means, you're probably going to identify some dependencies. "Resolving this core complexity is going to require these three teams to work in this sequence." The more you see dependencies showing up, the more that's a sign that you should look at your team structure. Build teams around complexity, locate complexity inside teams. 'cause you can collaborate around complex problems and deal with emergence within a team really well. Hard to do across teams. You can coordinate across teams. But you can't really collaborate across teams. And complexity moves over time, just like we saw in the Toyota example, where it moves from "what's the drive train going to be," to "how are we going to manufacture this new thing?" And that probably required a change in who's collaborating.
So if you see a lot of dependencies showing up in your big room planning, that can be a sign that your team structure needs to shift to match today's complexity. And that's okay. Team structure should be stable for a while, but it doesn't have to be stable forever as the world changes around you.
Peter: To learn more about CAPED, check out our upcoming webinar that Richard mentioned earlier. You can register by going to humanizingwork.com/caped and click the link. We'll also drop the link to register for the webinar in the show notes on our episode page. If you want help improving your planning, your team structure, your delivery approach, contact us and set up a free coaching call. We've helped lots of clients make SAFe work more effectively, and helped others move to something that was a better fit for their org, and we're happy to do the same thing for you.
Richard: And if you get value from the show and you wanna support it, best thing you can do if you're watching on YouTube is all the normal things: subscribe, like, click the bell icon. It really helps. And drop us a comment. We love to hear what the people who are watching are thinking about these topics, so we're not just talking out into the void.
And if you're listening in the podcast version, getting on Apple Podcast or Spotify and leaving us a five star review makes a huge difference in whether other people who'd benefit from the show find it or not. And it's super encouraging for us to keep doing this. Thanks for tuning into this episode of The Humanizing Work Show and we'll see you next time.
