Big Room Planning Is Dead

‘Big Room Planning’, or PI Planning, is one of the core events of the Scaled Agile Framework – SAFe. It’s an event where all of the teams on an Agile Release Train (ART), plus stakeholders, get together for 2 days to plan and align on goals for the next production time-box, or Program Increment – typically 5 or 6 sprints.

SAFe Big Room Planning is a multiple team/multiple sprint planning exercise. It is the SAFe solution for large programs where where multiple delivery teams are needed to construct and deliver large systems, typical of most commercial software or software supporting large business operations like banking, insurance, or healthcare. These organizations are often subject to regulatory constraints,  and (understandably) likely place more value on planning and predictability over risk-taking and innovation. Even though requirements are always a moving target, their product roadmaps are generally more slowly evolving than those of technology companies, and hence multi-sprint planning is not as potentially wasteful. The problem is at least two-dimensional: the production capacity of multiple teams is needed to make progress within meaningful market windows, and, business leaders want visibility of what is being delivered beyond the next sprint. The SAFe program-level framework provides a formula for solving both problems simultaneously.

In the midst of a pandemic, in a world of self-quarantines, and social distancing, no-one is volunteering to huddle with 200 other people in a single room for a 2-day gathering. Big Room Planning is dead, at least for now. In the meantime organizations have been scrambling to find alternative ways of accomplishing the goals of a planning event without being physically together. One unfortunate consequence has been increasing reliance on tools and of course the almost total elimination of face-to-face interaction. Video conferencing applications like Zoom have become ubiquitous, and a plethora of other collaboration and content-sharing applications has become part of  everyday corporate life. SAFe programs have put themselves through excruciating contortions to continue PI Planning as prescribed, for example running the event at multiple locations and multiple time zones simultaneously by maintaining constant audio and video communication between the sites. Question: Why is this even necessary?

These events are designed in a way to ensure that all of the answers are on hand in One Big Room. The benefits claimed by this approach include:

• Resolution of cross-team dependencies
• Fast decision-making

Are there other solutions for these challenges?

• Dependency management – minimize dependencies by designing true cross-functional feature delivery teams
• Fast decision-making – highly autonomous cross-functional teams are also key here, but, there is also no reason why planning must be completed in 2 days. It can take any reasonable length of time so long as it is completed before the next PI cycle, and the production cadence is not interrupted.

Many organizations have tried to adopt a scaling framework but have severely handicapped themselves in the process. Badly designed, non cross-functional teams, weighed down with dependencies, and with features shared between multiple teams. The resulting program boards look like the work of a mischievous kitten let loose with a big ball of yarn.

Meanwhile, at the other end of the scaling ideas spectrum we have other frameworks (LeSS, Nexus, Scrum@Scale) whose stated philosophy is to keep things as simple as possible, and resist  against layering additional governance mechanisms – additional roles, events and artifacts, on scrum teams, but instead encourage solving common scaling challenges by reducing cross-team dependencies, and refactoring monolithic architectures. None of these frameworks have any specific mechanisms for multi-sprint planning.

At the highest level of abstraction, we have two sets of processes at work: a set of feature intake processes that supply ready work to a product backlog, and then on the downstream side of the backlog, a set of delivery mechanisms that consume backlog items and transform them into working product increments.

There are only a few basic patterns (with variations) on the delivery side.

Pattern 1: Multiple Teams, Multiple Sprints (SAFe Model)

The job of the business team is to ensure that the product backlog is populated with well-defined work (features), ranked by business value, and that there is sufficient backlog depth to supply the ART with at least one PI’s worth of ready work. The delivery teams for their part will break down work from the backlog into story-sized pieces (story mapping), estimate each story, and, using knowledge of their velocities, derive an estimate of the approximate delivery date (to the nearest sprint) for each feature. Teams will use the mechanics prescribed by the SAFe Program Layer to get here. The resulting feature delivery timeline from each team is consolidated into the SAFe Program Board artifact, which is a representation of the feature delivery plans for the entire ART for the PI. A PI planning event has some other aspects, but essentially the output is an estimate of the scope and timeline for what can be delivered within the next multi-sprint time-box.

Pattern 2: Multiple  Teams, Regular Scrum

The LeSS, Nexus and Scrum@Scale patterns are based on real Scrum. In each case we have a single Product Backlog and a single Product Owner for each product. Both LeSS and Nexus insert one additional step where work for the next sprint is selected from the Product Backlog for each team prior to regular sprint planning. In reality most teams already know which subset of the backlog they will work from, so this step is likely low overhead. All teams march to the same cadence with all sprints starting and finishing on the same day. There are no additional roles like Chief Product Owners, or RTE’s. The scaling models in these frameworks try to stay as close as possible to pure scrum with minimal additional governance. LeSS, for example, is optimized for adaptiveness, and unlike SAFe, has no mechanisms for multi-sprint planning. It’s proponents would argue it is pointless building 6-sprint delivery plans as product backlogs are in a continuous state of refinement and re-prioritization (as suggested by the diagram).   Multi-sprint delivery plans with additional roles to support the required governance overhead seems uncomfortably un-agile.

But business leadership, not unreasonably, wants a view beyond the next sprint, say for the next quarter – is SAFe the only effective answer? Most organizations will use some form of product roadmap as a way of laying out product goals and priorities over time. Product owners may use roadmaps to outline future product capabilities and as an aspirational timeline for when new features will be released. In an agile organization roadmaps are not commitments but represent a set of prioritized goals for the evolution of a product over time, and like product backlogs, subject to continuous refinement and prioritization.  At scale, multiple agile teams will share a single product roadmap. Feature delivery velocity can be measured and a determination made of whether current production capacity (number of teams) is sufficient to meet business objectives represented in the product backlog and product roadmap. Over time, teams can become good at forecasting feature delivery without resorting to story-level estimation for multiple sprints.

Alternatives to Big Room PI Planning

But wait, where are my PI Objectives? There are in fact 2 key outputs from the PI Planning process: the Program Board, and a set of PI Objectives, scored by business stakeholders in terms of business value. The PI Objective-setting and scoring exercise typically happens towards the end of the 2-day planning event, and is where each team validates its understanding of their deliverables by summarizing  them in business terms. Features are really solutions to one or more business objectives. Why then do we have to wait until near the end of the event to learn whether the things we plan to build have value? This is not entirely clear, but it is how the standard PI Planning event is laid out. Instead, how about having that exercise at the beginning of the process, before detailed planning begins? The real part of this exercise should begin during feature intake. There should be something in the standard feature template that asks: why do we need this feature/what business problems does it solve? If that is done diligently for all features, then at Event #1 where we align on Vision, Strategy and Priorities, team Product Owners present their ranked list of proposed features and explain the business rationale for each one. If something is perceived to have little or no value by stakeholders it can be called out and then removed or de-prioritized.

Delivery at scale comes down to a choice about how much additional governance you are willing to take on in order to orchestrate the work of multiple teams, and also how large of a planning horizon you wish to accommodate. The level of governance required is directly related to the complexity of your program (number of teams) and team design (dependencies). Every item of additional governance subtracts delivery effort and hence velocity. Big Room Planning is a solution for complex program and team structures and multi-sprint delivery time-boxes. The goals of such planning can be largely realized without resorting to elaborate logistical arrangements. Asynchronous, distributed planning can be just as effective. Keep it simple. We all have enough stress.