esc
Anthology / Yagnipedia / Big Room Planning

Big Room Planning

The Room That Worked Best When It Was Empty
Ritual · First observed 2011 (as PI Planning in SAFe), but the practice of putting everyone in a room predates frameworks by approximately the entire history of human coordination · Severity: Variable (from revelatory to performative)

Big Room Planning is the practice of putting all the people who build a product into one room, at the same time, to plan what they will build next — an act so obvious that it required a multi-billion-dollar framework industry to formalize it, certify it, and charge admission.

The practice is ancient. Humans have been gathering in rooms to coordinate since rooms existed. The innovation of modern Big Room Planning is not the gathering — it is the ceremony: the two-day format, the dependency boards, the confidence voting, the management review, and the specific vocabulary that ensures you cannot do it without training.

In SAFe, Big Room Planning is called PI Planning (Program Increment Planning) — a two-day event in which one hundred or more people gather to plan ten weeks of work. It is SAFe’s most valuable ceremony, which is either a compliment to PI Planning or an indictment of every other SAFe ceremony, depending on your generosity.

The reason it works has nothing to do with the ceremony. It works because of the hallway.

The Hallway Theory

Big Room Planning’s value is not produced in the room. It is produced around the room — in the hallways, the coffee queues, the lobbies, and the five-minute conversations between people from different teams who have never had a reason to talk before.

In the room: sticky notes are placed on boards, dependencies are drawn with string, and confidence is voted on with fingers. This is the ceremony. The ceremony is visible, measurable, and photographable. It fills the slide deck.

In the hallway: a backend developer from Team 3 discovers that a frontend developer from Team 7 has been blocked for two weeks waiting for an API that Team 3 finished last sprint but forgot to announce. They fix it in a five-minute conversation. This would have taken three weeks through JIRA, two escalation meetings, and a Slack thread with fourteen people tagged.

The room creates the conditions. The hallway produces the results. The ceremony is the excuse. The corridor is the mechanism.

This is Conway’s Law in reverse — temporarily overriding the org chart by putting everyone’s communication structure in the same physical space. For two days, the shadow org chart and the official org chart collide, and the shadow org chart wins. People discover who they need to talk to. Then they talk to them. Not on Tuesday. Not in the next sprint. Now.

The Heartbeat

At a Scandinavian telecommunications company, the Big Room Planning was supplemented by a weekly meeting called The Heartbeat — modeled after the “Team of Teams” approach to cross-team coordination.

Initially, everyone attended. Developers, scrum masters, product owners — the room was full. After a few weeks, the room emptied. Only the scrum masters remained.

A manager panicked.

“The Heartbeat is broken,” he announced. He drafted an email to all developers: attendance is now mandatory.

A consultant — the same one who had grown the Big Room Planning from three teams to thirty-six — asked permission to investigate before the email was sent.

“Let me walk the floor and talk to the devs.”

He walked the floor. He talked to the devs. They told him:

“The Heartbeat is incredibly valuable. We attend, we find out who in other teams we need to solve things with, and then we reach out to them immediately — instead of waiting for Tuesday.”

The Heartbeat was not broken. The Heartbeat had succeeded. It had succeeded so thoroughly that it made itself unnecessary. The developers had absorbed the information they needed and started acting on it in real time, rendering the weekly meeting redundant. The empty room was not a failure of attendance. It was a graduation.

The manager saw an empty room and measured failure. The consultant walked the floor and measured success. The metric was the meeting. The outcome was the hallway.

“Better standups won’t save you from building features nobody needs.”
riclib, Mythology Driven Development — Substack Draft

Better attendance won’t save a meeting whose value has already been extracted. The best meeting is the one that makes itself unnecessary — and then has the courage to notice.

The Growth Model

The canonical Big Room Planning implementation — the one that actually obeyed Gall’s Law — was not designed for thirty-six teams. It was grown from three.

Quarter 1:   3 teams  → 3 sprints planned → refactor
Quarter 2:   6 teams  → 3 sprints planned → refactor
Quarter 3:  10 teams  → 5 sprints planned → refactor
Quarter 4:  16 teams  → 5 sprints planned → refactor
Year 2:     36 teams  → joined the other 20 (who had been doing SAFe)

At each step: run the planning. See what worked. Fix what didn’t. Add teams. Repeat. The format evolved because the participants evolved it. The three-team version looked nothing like the thirty-six-team version, because the thirty-six-team version had grown through sixteen iterations of “what worked?” — which is Agendashift wearing a trenchcoat and sunglasses (see: Agendashift#The One Time It Worked).

The consultant told the CTO: “We grow the Big Room Planning from three teams to thirty-six. In a year, we will be able to remove it.”

The CTO agreed, because the promise of removal is the one thing that distinguishes a tool from a dependency. A tool you can put down. A dependency you cannot. SAFe is a dependency — once implemented, it requires itself. A grown Big Room Planning is a tool — it teaches people who to talk to, and once they know, the room is optional.

The room is the scaffolding. The relationships are the building. You do not leave the scaffolding up after the building is complete, unless you are billing for the scaffolding.

The SAFe Version

In SAFe, Big Room Planning is formalized as PI Planning — a two-day event with a specific agenda:

Time Activity What Actually Happens
Day 1, AM Business Context & Vision Executives present slides nobody will reference again
Day 1, PM Team Breakouts The actual planning (the valuable part)
Day 1, PM Draft Plan Review Management asks questions that change nothing
Day 2, AM Planning Adjustments Teams fix what management’s questions broke
Day 2, AM Final Plan Review Confidence vote (everyone raises 3-4 fingers)
Day 2, PM Planning Retrospective “What went well: being in the same room” (every time)

The SAFe version works. Not because of SAFe — but because putting one hundred people in a room for two days produces hallway conversations that solve problems. SAFe did not invent this insight. SAFe packaged it — added the vocabulary, the agenda, the confidence vote, and the certification, and sold the package to organizations that could have achieved the same result with a room, a wall, and sticky notes.

The difference between the SAFe version and the grown version is the difference between buying flat-pack furniture and building a table from wood you found. The table is the same. The price is different. The understanding of why the table stands is different.

The Paradox of Attendance

Big Room Planning’s success metric, in most organizations, is attendance. Full room: success. Empty room: failure. This produces a paradox:

The Big Room Planning works → people learn who to talk to → people start talking directly → people stop attending the Big Room Planning → attendance drops → management declares failure → management mandates attendance → people attend but have already solved everything in the hallway → the room is full but inert → management declares success.

The metric measures the container. The value is in the contents. When the contents flow out of the container and into the organization, the container empties — and the organization panics, because an empty container looks like a broken process.

The Heartbeat was never broken. The Heartbeat was working. The developers just stopped coming to the room because they had already found each other and started solving things on Monday instead of waiting for Tuesday. The empty room was the proof.

The Lizard’s Position

The Lizard does not attend Big Room Planning. The Lizard blinks once, which means either “unnecessary” or “you already know who to talk to.” Both interpretations are correct.

But the Lizard understands the principle: put people in proximity. Let them discover their dependencies. Then get out of the way. riclib’s entire architecture — one binary, one database, one repo — is the result of a Big Room Planning in which the only attendee was riclib, the only dependency was internal, and the hallway conversation was an internal monologue that the Lizard ended with a single blink meaning “ship it.”

Measured Characteristics

Optimal Big Room Planning duration:                2 days
Percentage of value produced in the room:          20%
Percentage of value produced in the hallway:       80%
Time to solve a cross-team dependency in JIRA:     3 weeks
Time to solve the same dependency in a hallway:    5 minutes
Attendance at The Heartbeat (week 1):              full
Attendance at The Heartbeat (week 6):              scrum masters only
Problems solved at The Heartbeat (week 1):         discovered
Problems solved at The Heartbeat (week 6):         already fixed
Manager's diagnosis of empty room:                 "broken"
Consultant's diagnosis of empty room:              "graduated"
Teams needed to start:                             3
Teams at which SAFe says to start:                 100+
Growth steps to full scale:                        5
Time to grow from 3 to 36 teams:                   ~1 year
Time promised until removal:                       1 year
SAFe certifications required:                      0 (grown version), 12+ (SAFe version)
Best meeting outcome:                              making itself unnecessary

See Also