en
de
Vorteil eines Delegationsframeworks

Was kein Manager hätte entscheiden können

Sprüche wie «Das können nur die da oben entscheiden!!!» oder «Was hat der Chef sich dabei gedacht?!?» begegne ich als Coach und Berater regelmässig. Doch was machen Sie als Chef, wenn es die einzig richtige Entscheidung ist und die MitarbeiterInnen mit im Boot sein müssen?

Das Beste ist es, wenn es gar nicht Ihre Entscheidung, sondern die Entscheidung der Mitarbeiter und Mitarbeiterinnen ist. Dies geht nur, wenn Sie Ihren Untergebenen Vertrauen (in Massen) geschenkt haben, dass diese Entscheide (innerhalb von Rahmenbedingungen) selber fällen dürfen. Stichwort Delegation-Framework. Was das ist und wie was geht? – ein anderes Mal.

Ich habe in diesem Blog-Beitrag den Drang verspürt über ein Erlebnis an einem PI-Planning zu erzählen.

Was ist ein PI-Planning?

PI Planning steht für Programm Increment Planning. Ein Team von Teams (=Release Train) plant gemeinsam das nächste Inkrement (=die nächsten Sprints/Iterationen) eines Produkts. In SAFe ist dies ein Zweitages-Workshop. Mehr dazu zum Beispiel auf meinem Blog «Big Room Planning: Was Teilnehmer begeistert».

Das Planning beginnt mit einer Ansprache vom höchsten Business-Vertreter. In diesem Fall, von dem ich hier schreibe, hat der CEO eröffnet.

Der CEO erzählt

Der CEO erzählt über die Vision des Produkts und erwähnt die wichtigsten zwei Meilensteine. Er hebt hervor, wie wichtig das nächste Inkrement ist, denn der Kunde entscheidet, nachdem er das ausgelieferte Inkrement auf Herz und Nieren geprüft hat, ob er weiterfahren (also weiter entwickeln lassen) möchte oder nicht. Es ist eine Entscheidung,die sich substantiell auf die Firma in Geld und Ruf auswirkt. Den Mitarbeitern und Mitarbeiterinnen ist die Tragweite des Increments/Releases bewusst. Es wird auch klar, auf was der Kunde als Auftraggeber Wert legt.

Management Review and Problem-Solving Session

Am Ende des ersten Tages des PI-Plannings ist die Session «Management Review and Problem-Solving Session» vorgesehen. Der Plan, den die Teams erstellt haben, wird geprüft. Schaffen wir alles, was wir uns vorgenommen haben? Gibt es Probleme, die wir lösen müssen?

In dieser Geschichte stellte sich leider heraus: Das geht nie auf! Wir haben ein grosses Risiko, dass die Bedienbarkeit am Ende des Inkrements schlimmer ist als jetzt. Dies ist dann der Fall, wenn die Arbeiten an den UI-Komponenten nicht rechtzeitig fertig werden.

Wie würden Sie entscheiden? Wie hat der CEO entschieden?

Der CEO musste gar nicht entscheiden. Jeder Anwesende an dieser Session hat gegen seine persönlichen Interessen und zum Wohle der Firma entscheiden!

Kostprobe gefällig?

  • Der System-Architekt hat für die nächsten 4 Sprints gegen seine Überzeugung eine UI-Task-Force vorgeschlagen. Dieses Team sollte sich ausschliesslich ums Aussehen der Oberfläche kümmern, also ein UI-Schicht-Team.
  • Der Scrum-Master des einen Teams hat eingewilligt, dass seine erfahrensten UI-Entwickler für 4 Sprints abgezogen werden und in der UI-Task-Force mitmachen.
  • Der Scrum-Master eines anderen Teams hat eingewilligt, einen neuen UI-Mitarbeiter einzubinden
  • Der UX-Verantwortliche hat die vollständige Erstellung von UI-Komponenten auf später verschoben und in dieser Iteration die Taskforce übernommen mit dem Ziel, zuerst eine guten User-Experience sicherzustellen und nur dort, wo es ohne grösseren Aufwand möglich ist, saubere Komponenten zu erstellen

Und ich… Ich fand es cool, diese Entscheidungen zu unterstützen, die einigen agilen Prinzipien widersprechen. Manchmal muss man  Prinzipien brechen, um ans Ziel zu kommen; was sich hier richtig und gut angefühlt hat. Die Prinzipien verlieren dadurch nicht an Wert, aber das Ziel ist in diesem Fall höher zu gewichten. Denn in der Summe konnte nur so das Ziel wenigstens potentiell erreicht werden.

Hatten wir eine Garantie, dass es aufgeht? Nein. Aber der Entscheid wurde von allen getragen und am nächsten Tag gemeinsam vor der versammelten Mannschaft (in SAFe: Agile Release Train) vertreten.

Stellen Sie sich vor, der CEO hätte alleine so entschieden. Alle wären sauer gewesen. «Was hat der Chef sich dabei gedacht? Der hat doch von nichts ’ne Ahnung! Und schon gar nicht von Agile.»

Ich habe mit diesem Blogpost einige Monaten abgewartet. Warum? Ich darf nun eine Erfolgsstory erzählen. Das Team wurde fertig und konnte einen guten ersten Wurf des neuen Produktes ausliefern.

Was sind die Lehren daraus?

  1. Nicht alle Entscheidungen muss oder soll der CEO fällen
  2. Eingebunden und informierte Mitarbeiterinnen und Mitarbeiter finde ihre pragmatische Seite, wenn es hart auf hart kommt und bestimmen gemeinsam eine umsetzbare Lösung

Kommentare (0)

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.