SAFe Mix-in’s: No Prep PI Planning
Overview
One of the issues that I’ve seen with doing big room planning (BRP) or Program Increment (PI) planning in SAFe is often people tend to over-prepare for these events (a quick note here: I use the terms PI planning and BRP interchangeably). And let’s face it, there are often good reasons for why they might do that. PI planning is a big event. It’s expensive. It involves a lot of people. There’s a genuine reason to worry that if you show up without any work, you’ll be wasting a lot of people’s time and money.
With that rather intense pressure in mind, what you tend to see is a lot of well-intentioned labor to make sure that PI planning is very, very, well prepared for. This leads us down a road that I’ve travelled many times. At Rally we had a BRP launch checklist. That checklist was for a nine-week process for preparing for big room planning. That was nine solid weeks of breaking down the work, reviewing the work, and estimating the work prior to the big room planning event. If you stop and think about it, nine solid weeks of preparation is an enormous investment.
Therefore, if you think that 2 days of everybody’s investment is a lot of work for the event itself, then the nine weeks leading up to that is even worse. The burden falls on a relatively small group of people, usually product management and a few others. In many cases I’ve heard product management come back to me and say, “We like the collaboration at the end of the nine weeks, but this preparation process is murder.” If you’ve participated in this process, then you know there is a grain of truth to this concern. Even worse, I’ve seen instances where new unanticipated work was discovered in the BRP and therefore the conclusion: we need to invest more in planning next time. It becomes a never-ending nightmare cycle. Miss something, plan harder. Miss something, plan even more. I call it “Falling into the requirements black hole.”
So how do we avoid this pattern? What I would propose is that we lighten up that preparation process. I call it the “No-Prep BRP” or “No-Prep PI Planning.” After all, one of the underlying reasons that we’re afraid of wasting our time is we don’t trust that people can break down the work or do meaningful work without us preparing it all like pre-chewed baby food for them. And that’s simply not the case.
In a no-prep BRP, it’s not that we would do no prep at all, but that we would minimize it to the greatest degree possible. In some sense this isn’t all that different from open space. Open space doesn’t have elaborate preparation, rather it has the absolute minimum of preparation. In fact, often times people don’t know what the issue is until they walk into the room. In a no-prep BRP what we are going to do is prepare the initiatives at the highest possible level. We’ll try and articulate those initiatives as well as we can, but we are going to stop there and go no further. Also, we’re not going to estimate – we’ll leave the estimation completely out of it. We’re going to spend more time on customer validation. Rather than focusing on sizing, we’ll focus in validating that this initiative truly has the right outcomes that are truly meaningful for our customers.
You can find out more about No Prep PI Planning here:
Actually, there isn’t anyone calling it that, but we could start a trend…
Ivar Jacobsontalks about lightweight PI Planning
Using this lightweight process, we’re going to invest our time differently. We’re going to spend it more focused on the customer and less focused on the estimation. Once we get it all together, then we deliver it as we typically would in our BRP, but at that point it then becomes more of a Q&A and more of a dynamic breakdown that we are going to engage in with our customers (who are hopefully present) or our stakeholders.
Part of the reason for the exhaustive preparation for big room planning is that these are organizations that are accustomed to having detailed plans. Detailed plans being one of the most important outputs for these kinds of organizations. Unfortunately, they haven’t learned the lesson that no matter how detailed the plan, “stuff happens” that no one can anticipate in software design. In an effort to try and compensate for this, they only try and squeeze more and more detail out of the plan in the vain hope of trying to detect the “stuff” in advance and somehow avoid it. Which by now we know that in a design process is nearly impossible.
With that in mind, we need to change our focus for the BRP. The BRP is no longer about outputting the plan. The BRP is the start of a collaboration. It is the start of a conversation. It is the start of discovery, but it is by no means any sort of end result or end product. That means that in order for this to be successful we’re going to need to be a little bit more thoughtful about encouraging interaction throughout the duration of the planning increment. That means that our scrum of scrums and other activities are going to need to be more collaborative and we are going to lean on them more heavily, because plans will change. I think it’s a better reflection of the way that software design works, but nevertheless some organizations may not be able to tolerate this. And that implies that some organizations wouldn’t want to consider this. But for those that are willing and ready, doing the no-plan BRP may be the way to go.
Forces
PI Planning Prep is getting too heavyweight and oppressive
Product management is willing to plan less and discover more
Framework Impacts
None really, SAFe doesn’t require extensive PI Planning as such
Benefits
Improved collaboration between teams and product owners
More time spent with customers and less time spent on endless estimation
Interested in more Mix-ins? Join Ron Quartel and I for a 3 day workshop on SAFe+FAST Agile. Combine the 2 to get max value from your agile transformation. It’s an opportunity to explore the latest scaled agile processes and practices with other agile innovators on May 15, 16, 17. https://bit.ly/2HXCcKD
#SAFe #PIPlanning #Agile #BRP #NoPrepPIPlanning #BigRoomPlanning