Big Room Planning

Der Newsletter für nachhaltige Transformation Made in Germany 🇩🇪

Über den Standort Deutschland wird viel geklagt. Doch Jammern bringt uns nicht weiter – Handeln schon!

Die globalen Rahmenbedingungen können wir kaum beeinflussen. Was wir beeinflussen können, ist wie gut Unternehmen digital, agil und zukunftsfähig aufgestellt sind.

In diesem Newsletter reflektiere ich wöchentlich meine Erfahrungen, Erkenntnisse und Impulse aus Digital-, Transformations- und Change-Projekten.

✔️Prägnant ✔️Praxisnah ✔️ Pro Bono.

Mein Antrieb: Viele kleine, konsequente Schritte können große Wirkung entfalten.

📣 Lass uns gemeinsam was bewegen!

Herzlich willkommen zu einer neuen Ausgabe von der Transformator:

„Stell dir mal vor, 100 Entwickler sitzen zwei Tage lang nur im Planning – was das kostet!!!“ 💸

Genau so klingen viele Einwände, wenn es um SAFe PI Planning bzw. Big Room Planning geht. Die Rechnung ist schnell gemacht: 100 Leute x 2 Tage = teuer!

Was dabei fast nie gegengerechnet wird: die Kosten dafür, dass genau diese Menschen ein Quartal lang aneinander vorbeiarbeiten, Abhängigkeiten zu spät erkennen, Prioritäten falsch verstehen oder dieselben Probleme mehrfach lösen.

Ich habe beide Welten intensiv erlebt:

Auf dieser Basis lege ich beide Ansätze übereinander und frage:

Was entspricht im klassischen Projektansatz dem, was wir im Big Room Planning tun – und wo liegen die entscheidenden Unterschiede in Effizienz, Planungsqualität und Verlässlichkeit?

1. Kontext: 90 Minuten vs. Meeting-Karussell

Der erste Block eines PI Plannings wirkt von außen oft „teuer“: Rund 1,5 - 2h, in denen alle gemeinsam Markt-, Produkt- und Technik-Updates bekommen. 🌍🛠️

Inhaltlich geht es um drei Dinge:

In meinem aktuellen ART, der sich in einem eingeschwungenen Zustand befindet, reichen dafür etwa 90 Minuten, um alle auf denselben Stand zu bringen. Viermal im Jahr – mehr nicht.

Im klassischen Projektumfeld sehe ich dafür ein ganz anderes Muster:

Townhalls, Bereichsmeetings, Architektur-Boards, bilaterale Abstimmungen, E-Mail-Newsletter, Präsentationen in kleinen Runden. Auf den ersten Blick wirkt das „billiger“, weil nie 100 Personen gleichzeitig im Raum sitzen. In Summe kommt man aber über 12 Wochen sehr schnell auf vergleichbare oder höhere Zeiten – mit deutlich mehr Streuverlust.

Ob SAFe hier wirklich effizienter ist, hängt von der Meetinglandschaft ab. Meine langjährige Erfahrung in Großkonzernen: Wenn man ehrlich auf alle Formate schaut, die „Kontext“ transportieren sollen, ist SAFe mit seiner Bündelung klar im Vorteil – weniger Rauschen, mehr Klarheit.

Nach dem Kontextblock geht es in die Breakout Session 1. Hier wird es konkret:

Die Teams nehmen vorbereitete Features, brechen sie in User Stories herunter und erstellen einen Plan für die nächsten 12 Wochen – inklusive Kapazität, Abhängigkeiten und Risiken. 🔍

Genau hier zeigt sich ein zentraler Mindset-Shift:

Wie sieht das klassisch aus?

Ein Projektleiter sammelt Anforderungen, schneidet sie in Arbeitspakete, fragt diese bei verschiedenen Experten ab und gießt alles in einen Projektplan. Der Aufwand dafür ist erheblich und zieht sich über Wochen: Planung, Abstimmung, Nachfragen, Nachjustieren. Da kaum ein Projektleiter alle Arbeitspakete selbst präzise schätzen kann, sind viele Abstimmungen nötig – nur eben verteilt, sequentiell und oft bilateral. 🔄

Im Big Room Planning wird dieser Aufwand konzentriert und transparent:

Rein rechnerisch:

Auf dem Papier wirkt der klassische Ansatz günstiger, weil „nur“ ein Projektleiter offiziell plant. In der Realität braucht er aber ebenfalls viele Experten, um sinnvoll zu planen – der Aufwand ist nur weniger sichtbar und verteilt sich über zahlreiche Einzeltermine.

Eine klassische Milchmädchenrechnung: In SAFe existiert der Projektleiter in seiner alten Rolle gar nicht mehr. 650 Stunden Planung klingen nach viel — entsprechen aber lediglich einem Vollzeit-Projektleiter für zwölf Wochen, der sich auch wiederum mit Experten abstimmen muss etc. Wirkliche Einsparung? Fehlanzeige.

Meine Erkenntnis aus SAFe-Umfeldern:

Damit verschiebt sich die Qualität der Planung: weg von einem theoretisch sauberen, aber fragilen Projektplan hin zu einem realistischen, von den Teams getragenen Umsetzungsplan.

Reviews: Steering Board im Big Room

Nach der ersten Breakout-Phase folgt im PI Planning das Draft Plan Review. Inhaltlich ersetzt dieser Schritt die klassischen Review- oder Steering-Boards, in denen Projektpläne präsentiert und freigegeben werden.

Der entscheidende Unterschied: Im Draft Plan Review schauen nicht nur wenige Entscheider auf einen abstrakten Projektplan, sondern alle relevanten Stakeholder auf konkrete Teampläne – inklusive Abhängigkeiten, Risiken und Kapazitäten. Wenn etwas nicht passt, kann sofort reagiert werden: Ziele nachschärfen, Prioritäten anpassen, Features umschneiden, Abhängigkeiten neu organisieren.

Im klassischen Kontext sieht das oft anders aus:

Der Projektleiter arbeitet mehrere Wochen am Plan, sammelt Rückmeldungen, bereitet Slides auf – und wartet dann im Zweifel wieder einige Wochen bis zum nächsten Review- oder Steering-Board. Bis dahin haben sich Rahmenbedingungen geändert, Probleme sind bereits eskaliert oder Verzögerungen haben sich verfestigt.

Das Draft Plan Review verkürzt genau diese Schleife:

Statt alle 6–8 Wochen auf ein Gremium zu hoffen, wird direkt im Planning gemeinsam korrigiert – mit allen, die es betrifft, und zu einem Zeitpunkt, an dem Änderungen noch vergleichsweise günstig sind.

Am zweiten Tag geht es in die Feinplanung: In Breakout Session 2 schärfen die Teams ihre Pläne, finalisieren User Stories, klären letzte Abhängigkeiten und ergänzen konkrete Risiken und Maßnahmen. Aus dem Entwurf wird ein umsetzbarer Plan für die nächsten 12 Wochen. 📅

Im anschließenden Final Plan Review ist die Erwartung klar: Stakeholder schauen nicht „nur mal drüber“, sondern geben bewusst ihr Commitment – oder justieren gezielt nach. 🎯

Retro vs. Lessons Learned

Abgeschlossen wird das PI Planning mit einer kurzen Retrospektive – dem Pendant zu KVP bzw. Lessons Learned im klassischen Umfeld, nur eben direkt im Anschluss und nicht erst am Projektende. So fließen Verbesserungen sofort in das nächste PI ein. 🔄

Vergleich:

Vom reinen Zeitaufwand her hält sich das in etwa die Waage. Der Unterschied liegt im Wirkungsgrad: Kontinuierliches, frühzeitiges Lernen versus spätes, einmaliges Reflektieren.

Bilanz unter klaren Annahmen

Für meine Bilanz setze ich zwei Dinge voraus:

1. Die Entwickler-Teams im ART sind in einem eingeschwungenen Zustand.

2. Das Unternehmen beherrscht die „Kunst des Weglassens“ – es werden nicht klassisch und agil parallel als zwei Betriebssysteme gefahren.

Unter diesen Annahmen relativiert sich der vermeintliche Mehraufwand eines PI Plannings erheblich. Der Gesamtaufwand bleibt vergleichbar — die Qualität der Ergebnisse ist meiner Erfahrung nach spürbar besser.