Schematisches Program Board: Zeilen für fünf Entwicklungsteams, Spalten für die einzelnen Wochen eines Program Increments. In den Feldern liegen Aufgabenkarten, rote Verbindungslinien zwischen Karten verschiedener Teams markieren Abhängigkeiten.

PI-Planning

PI-Planning ist ein großes Planungstreffen, bei dem mehrere Entwicklungsteams für die nächsten rund drei Monate gemeinsam festlegen, wer was baut und wo sie voneinander abhängen. Es stammt aus dem Rahmenwerk SAFe, mit dem große Unternehmen ihre Softwareentwicklung organisieren.

In großen Unternehmen arbeiten oft zehn oder mehr Teams an demselben Produkt. Jedes Team baut ein Stück davon, und diese Stücke müssen später zusammenpassen. PI-Planning ist das Treffen, bei dem alle diese Teams sich für die nächsten rund drei Monate abstimmen. Sie legen fest, welche Aufgaben sie in dieser Zeit erledigen wollen und an welchen Stellen sie auf die Arbeit anderer Teams warten müssen. Das Kürzel PI steht für Program Increment, also für den festen Zeitabschnitt von meist acht bis zwölf Wochen, den man gemeinsam plant. Das Treffen selbst dauert typischerweise zwei volle Tage und findet alle drei Monate erneut statt.

Warum Firmen zwei Tage lang alle an einen Tisch holen

Der teuerste Fehler in großen Softwareprojekten ist nicht schlechter Code. Es ist die Entdeckung im letzten Moment, dass zwei Teams aneinander vorbeigearbeitet haben. Team A hat eine Funktion gebaut, die auf eine Schnittstelle von Team B zugreift. Team B wusste davon nichts und hat etwas anderes priorisiert. Solche Lücken kosten Wochen, wenn sie erst kurz vor der Auslieferung auffallen.

PI-Planning zieht dieses Problem nach vorn. Die Abhängigkeiten werden ausgesprochen, während man sie noch billig auflösen kann. Zwei Entwickler klären in fünf Minuten im Raum, was per E-Mail über drei Wochen laufen würde. Genau deshalb halten viele Firmen die zwei Tage für gut investiert, obwohl hundert Leute währenddessen nicht programmieren.

Der zweite Grund ist weniger offensichtlich. Alle Teams hören dieselbe Erklärung, warum das Unternehmen bestimmte Ziele verfolgt. Ohne solche Treffen kennen viele Entwickler nur ihr eigenes Ticket, nicht den Zweck dahinter. Wer den Zweck kennt, trifft bei kleinen Entscheidungen im Alltag bessere Kompromisse.

Ablauf der zwei Tage

Der erste Tag beginnt mit Vorträgen. Führungskräfte und Produktverantwortliche erklären, welche Ziele in den nächsten Monaten wichtig sind und was sich am Markt geändert hat. Danach zieht sich jedes Team zurück und plant für sich. Es schätzt, wie viel Arbeit realistisch in die kommenden Wochen passt, und schreibt die geplanten Aufgaben auf.

Das zentrale Werkzeug ist eine große Wand oder ein digitales Board. Jedes Team hängt seine Aufgaben in eine eigene Zeile, aufgeteilt nach den einzelnen Wochen. Rote Fäden oder Linien verbinden Aufgaben, die voneinander abhängen. Wenn ein Team viele rote Fäden zu einem anderen hat, ist das ein sichtbares Warnsignal. Diese Wand heißt im Fachjargon Program Board.

Am zweiten Tag werden die Pläne angepasst, bis sie zusammenpassen. Zum Schluss stimmt jedes Teammitglied per Handzeichen ab, wie sicher es sich mit dem Plan fühlt. Diese Abstimmung heißt Confidence Vote. Niedrige Werte sind kein Scheitern, sondern ein Hinweis, dass etwas noch zu unklar oder zu ehrgeizig ist. Wichtig ist der Unterschied zu einem klassischen Projektplan: Der PI-Plan ist eine Absichtserklärung, keine Garantie, und er wird während der drei Monate laufend korrigiert.

SAFe, Konzerne und die Kritik daran

PI-Planning kommt aus SAFe, dem Scaled Agile Framework. Das ist ein Regelwerk, das agile Arbeitsweisen aus kleinen Teams auf ganze Konzerne übertragen soll. Banken, Versicherungen, Autohersteller und Behörden arbeiten häufig danach. Wer sich in Deutschland auf eine IT-Stelle bei einem großen Arbeitgeber bewirbt, findet SAFe und PI-Planning oft direkt in der Stellenanzeige.

In Wirtschaftsnachrichten taucht der Begriff meist im Zusammenhang mit Umbauprogrammen auf. Wenn ein Unternehmen ankündigt, seine IT agil aufzustellen, steckt oft eine SAFe-Einführung dahinter. Es gibt eine ganze Beratungsbranche, die solche Umstellungen begleitet und Zertifikate dafür verkauft.

Kritik gibt es reichlich. Gegner nennen SAFe bürokratisch und sagen, es verkleide alte Konzernplanung als moderne Methode. Zwei Tage Planung alle drei Monate seien viel Aufwand für Ergebnisse, die schnell veralten. Befürworter halten dagegen, dass große Organisationen ohne festen Abstimmungstermin gar nicht koordiniert vorankommen. Beide Seiten haben Punkte, und in der Praxis hängt das Ergebnis stark davon ab, ob die Teams das Treffen ernst nehmen oder nur abarbeiten.

Subscribe free. Unsubscribe the second it sucks.

High-signal news across AI, business, UX, and tech. Every morning.