Eskalationen in agilen Programmen: Schnell entscheiden, ohne zu blockieren

Eskalationen in agilen Programmen funktionieren, wenn jede Entscheidung einen Besitzer, eine Frist sowie eine feste Stufe hat, auf der sie spätestens fällt. Dann wird die Eskalation zu einem normalen Teil der Steuerung und blockiert die Teams nicht mehr. Die Ursache liegt meist in ungeklärten Entscheidungsrechten: Wer nicht weiß, wer entscheiden darf, wartet auf den Lenkungskreis und lässt Arbeit liegen.

Dieser Beitrag beschreibt ein Eskalationsmodell mit drei Stufen, zeigt, wie sich Fristen festlegen lassen, und gibt eine Prüfliste für Programme mit mehreren Teams an die Hand.

Warum blockieren Eskalationen agile Programme?

Eskalationen blockieren agile Programme, weil sie die Arbeit eines Teams anhalten, bis eine Stelle außerhalb des Teams entschieden hat. Ein Team von acht Personen, das drei Tage auf eine Freigabe wartet, verliert 24 Personentage, obwohl niemand etwas falsch gemacht hat. Rechnet man mit einem Sprint von zehn Arbeitstagen, entspricht das knapp einem Drittel der Kapazität eines Sprints. Die Verzögerung ist selten sichtbar, denn das Team arbeitet in dieser Zeit an anderen Aufgaben, und die gewartete Aufgabe erscheint erst im Rückblick als Ursache für den verfehlten Sprint.

Drei Muster erzeugen diese Wartezeit. Das erste Muster ist die fehlende Entscheidungsstufe: Ein Konflikt zwischen zwei Teams wandert direkt zum Lenkungskreis, weil keine Zwischenstufe existiert. Das zweite Muster ist der unklare Besitzer: Mehrere Stellen fühlen sich zuständig, und jede wartet auf die andere. Das dritte Muster ist die fehlende Frist: Die Eskalation wird auf die Tagesordnung der nächsten Sitzung gesetzt, die in zwei Wochen stattfindet.

Wie sich solche Wartezeiten in der Lieferkette summieren, beschreibt der Beitrag zu den Abhängigkeiten zwischen Teams. Eskalationen sind meist das sichtbare Ende einer Abhängigkeit, die nicht rechtzeitig geklärt wurde.

Welche Stufen braucht ein Eskalationsmodell?

Ein Eskalationsmodell für agile Programme braucht drei Stufen: die Entscheidung im Team, die Entscheidung zwischen den Teams und die Entscheidung in der Programmsteuerung. Jede Stufe hat einen benannten Entscheider und eine Frist, nach deren Ablauf die Sache automatisch auf die nächste Stufe geht. Das Modell folgt dem Prinzip der Subsidiarität: Eine Entscheidung fällt auf der niedrigsten Stufe, auf der alle nötigen Informationen vorliegen.

Die erste Stufe ist die Entscheidung im Team. Sie umfasst alles, was Umsetzung, Reihenfolge sowie Technik innerhalb des Teams betrifft. Der Scrum Guide von 2020 weist den Product Owner für die Reihenfolge des Product Backlogs und die Entwickler für die Planung und Umsetzung zu, ohne dass jemand außerhalb des Teams eingreift. Eskaliert ein Team auf dieser Stufe, sind meist die Rollen ungeklärt, und deren Klärung löst die Sache ohne höhere Instanz.

Die zweite Stufe ist die Entscheidung zwischen den Teams. Sie greift, wenn zwei Teams sich über eine Schnittstelle, einen gemeinsamen Baustein oder eine Reihenfolge nicht einigen. Entscheider sind die Product Owner der beteiligten Teams oder eine Person mit Programmverantwortung, in vielen Organisationen ein Delivery Manager. Die Frist beträgt in der Praxis einen bis zwei Arbeitstage, weil beide Teams in dieser Zeit warten.

Die dritte Stufe ist die Entscheidung in der Programmsteuerung. Hierhin gehören Fragen, die Budget, Termin oder Umfang des Programms verändern oder mehrere Bereiche des Unternehmens betreffen. Die Frist beträgt höchstens fünf Arbeitstage, und die Steuerung entscheidet in einem festen Zeitfenster, das nicht auf die nächste reguläre Sitzung wartet.

Wie legt man Fristen für Entscheidungen fest?

Fristen legen Sie fest, indem Sie die Kosten der Wartezeit berechnen und die Frist an diesen Kosten ausrichten. Die Rechnung ist einfach: Anzahl der wartenden Personen mal Wartetage mal Tagessatz. Fünf Personen, die zwei Tage warten, ergeben zehn Personentage. Bei einem angenommenen internen Verrechnungssatz von 600 Euro je Personentag sind das 6.000 Euro für eine einzige Verzögerung. Das Prinzip stammt aus der Priorisierung nach Cost of Delay, die den wirtschaftlichen Schaden einer Verzögerung in den Mittelpunkt stellt.

Aus dieser Rechnung ergibt sich eine Regel für die Fristen: Je mehr Personen eine Entscheidung blockiert, desto kürzer die Frist. Eine Entscheidung, die ein einzelnes Team für einen halben Tag aufhält, darf warten. Eine Entscheidung, die drei Teams ausbremst, braucht eine Antwort am selben oder nächsten Tag. Die Frist ist dabei eine Obergrenze, und viele Entscheidungen lassen sich in einer halben Stunde treffen, sobald die richtigen Personen im Gespräch sind.

Das Ablaufen einer Frist hat eine klare Folge. Wer innerhalb der Frist nicht entschieden hat, überträgt die Entscheidung auf die nächste Stufe, und die übergeordnete Stufe erhält dazu eine kurze Zusammenfassung mit Optionen und Empfehlung. Dadurch zeigt sich die Wartezeit von selbst, und niemand muss eine Verzögerung anprangern.

Welche Entscheidungsrechte müssen vorab geklärt sein?

Vorab geklärt sein müssen die Entscheidungsrechte für Reihenfolge, Technik, Budget, Personal sowie Außenwirkung, jeweils mit einem Namen oder einer Rolle. Wo diese Klärung fehlt, entstehen die Eskalationen, die sich vermeiden ließen. Ein bewährtes Hilfsmittel ist Delegation Poker aus Management 3.0 von Jurgen Appelo: Eine Gruppe ordnet für jeden Entscheidungstyp eine von sieben Delegationsstufen zu, von „Ich entscheide allein“ bis „Das Team entscheidet vollständig“. Das Ergebnis ist eine Tabelle, die für jeden Entscheidungstyp festhält, wer entscheidet sowie wer gehört wird.

Der Aufwand dafür ist gering. Eine Sitzung von neunzig Minuten mit den Product Ownern und der Programmleitung genügt für die ersten zehn bis fünfzehn Entscheidungstypen. Entscheidend ist, dass die Ergebnisse veröffentlicht werden und für alle Teams gelten. Eine Entscheidungstabelle, die nur in einem Protokoll liegt, wirkt im Alltag nicht.

Eine zweite Ebene betrifft die Koordination über mehrere Programme hinweg. Das Modell der Flight Levels von Klaus Leopold unterscheidet drei Ebenen, auf denen Entscheidungen fallen: die operative Ebene der Teams, die Koordination zwischen den Teams und die Strategie. Die drei Eskalationsstufen oben lassen sich diesen Ebenen direkt zuordnen.

Wie sieht ein Entscheidungsprotokoll aus?

Ein Entscheidungsprotokoll hält je Entscheidung fünf Angaben fest: die Frage, die Optionen, die Entscheidung, den Entscheider sowie das Datum. Dazu kommt ein Prüfdatum, an dem die Entscheidung überprüft wird, wenn sie weitreichend ist. Das Protokoll hat zwei Zwecke. Es verhindert, dass dieselbe Frage nach vier Wochen erneut auftaucht, weil niemand sich erinnert. Und es macht Muster sichtbar: Wenn ein bestimmter Typ von Entscheidung wiederholt auf Stufe 3 landet, fehlt auf einer niedrigeren Stufe das Entscheidungsrecht.

Das Protokoll zeigt auch, ob das Modell wirkt. Landen viele Einträge auf Stufe 3, die auf Stufe 1 oder 2 hätten fallen können, sind Entscheidungsrechte nicht geklärt, und die Programmsteuerung wird zum Flaschenhals. Die Zahl der Eskalationen auf Stufe 3 ist darum eine nützliche Kennzahl, die jede Programmleitung monatlich beobachten sollte. Sinkt sie über mehrere Monate, kommen die Entscheidungen dort an, wo die Informationen liegen.

Was tun bei Konflikten zwischen Vorständen oder Bereichsleitern?

Bei Konflikten zwischen Vorständen oder Bereichsleitern bereitet die Programmleitung die Entscheidung so auf, dass der gemeinsame Sponsor sie in einem einzigen Termin treffen kann. Dazu gehören die Auswirkung jeder Option auf Termin, Kosten sowie Nutzen in Zahlen, eine Empfehlung mit Begründung und die Frist, bis zu der entschieden sein muss. Ein solches Entscheidungspapier umfasst eine Seite. Wer zehn Seiten schreibt, verzögert die Entscheidung.

Ein weiterer Hebel ist die Planung. Ein Programm, das seine Abhängigkeiten in einem gemeinsamen Termin klärt, wie im Big Room Planning beschrieben, verlagert viele Konflikte von der laufenden Umsetzung an den Planungstermin. Dort sitzen die Entscheider ohnehin im Raum, und die Eskalation findet in Echtzeit statt.

Eskalationen steuern mit Niehues Consulting

Niehues Consulting ist eine Beratung für KI-Management und Organisationsdesign aus der Lieferperspektive mit Sitz in Düsseldorf. Gründer Marin Niehues baut Organisationen, die liefern, und arbeitet in Projekten von VC-finanzierten Scaleups bis zu DAX-40-Konzernen, im Einsatz in über 20 Ländern auf sechs Kontinenten. Im Leistungsfeld Delivery Management übernimmt er Rollen wie Delivery Manager, Projektmanager oder Product Owner und gestaltet die Organisation um die Lieferung.

Das Vorgehen folgt dem Niehues Delivery Model. Für Eskalationen sind zwei Prüffragen besonders aufschlussreich: Wer entscheidet, wer liefert, wer nutzt? Und: Welche Rollen, Entscheidungswege sowie Schnittstellen braucht der Betrieb? Wer beide Fragen schriftlich beantwortet, hat die Grundlage eines Eskalationsmodells. Umfang und Konditionen eines Vorhabens werden in der kostenfreien Erstberatung besprochen, die Sie über den Kontakt vereinbaren.