Variablen des Eisernen Dreiecks: Scope, Ressourcen und Termin
Das ‘Eiserne Dreieck des Projektmanagements’ zeigt die drei Variablen Scope, Ressourcen und Termin:
- Scope (Inhalt und Umfang): Was soll während des Projektes entstehen und in welche Qualität? Welche inhaltlichen Ziele wurden mit dem Stakeholder vereinbart?
- Ressourcen (Kosten): Welches Budget steht zur Verfügung? Was kostet die Umsetzung des Projektes?
- Termin (Zeit): Wann startet das Projekt und bis wann ist der Scope zu erreichen? Welche Meilensteine gibt es?
In plangetriebenen Projektmanagement-Methoden ist der Umfang (scope) fixiert.
Was am Ende eines Projektes als Ergebnis stehen soll, wird zuvor festgelegt. Dann ein Plan erstellt und abgearbeitet.
Die Dreiecksbeziehung bedeutet: mindestens eine der beiden anderen Größen ist variabel.
Der Projektleiter ist dafür verantwortlich, das Projektziel unter den gegebenen Rahmenbedingungen zu realisieren. Erfahrene Projektleiter wissen, dass Unvorhergesehenes immer geschieht.
Fast alle Entscheidungen in Projekt und zuvor nicht kalkulierte äußere Einflussfaktoren haben Einfluss auf diese Dimensionen. Wird eine der drei Größen Scope, Ressourcen oder Termin verändert, so hat das direkte Auswirkungen auf die beiden anderen Größen.
Um die Projektziele zu erreichen, müssen Änderungen in einem Parameter durch die beiden anderen Größen ausgeglichen werden. Der Projektleiter hat die Aufgabe, diese Zielgrößen auszubalancieren und die Verantwortung für die erfolgreiche Umsetzung.
Die völlig verständliche Reaktion auf Unwägbarkeiten und um den Plan auch unter widrigen Umständen zu erfüllen, werden häufig Zeit- und Budgetpuffer in die Aufwandschätzungen eingeplant. Also Reservetanks für Variablen, die aktiviert werden können, wenn es in der Planung enger wird.
Puffer sind nichts Verkehrtes und wir nutzen das im Alltag ständig. Ein wenig früher zum Zug, ein bisschen mehr kochen als im Rezept steht. In einer Projektsituation sind Puffer aus gleichen Gründen natürlich ebenso unverfänglich.
Allerdings leidet die Transparenz. Sie leidet zweifach, wenn es Puffer gibt und sie nicht kommuniziert sind.
Agil organisierte Vorhaben planen fließend
Agile Entwicklung liefert Wert in kurzen Zyklen der Validierung.
In agilen Organisationsformen sind Änderungen ebenso lästig wie in in allen anderen Methoden. Der Unterschied ist nur: sie werden als realistische Möglichkeit akzeptiert, nicht zurückgewiesen sondern gar begrüßt. Die Welt ändert sich, also auch Bedürfnisse.
Damit stellt sich das ‘Eiserne Dreieck’ auf den Kopf:
- Ressourcen (d.h. das Team) werden stabil gehalten. Es gibt keine ständige Neufindung des Teams, was einen positiven Einfluss auf die Qualität und Produktivität hat, da wiederholte soziale Rüstzeiten entfallen und
- Termine (regelmäßige Releases) werden festgelegt. Es geschehen regelmäßige Lieferungen wertstiftender Funktionalität nach z.B. jedem Sprint. Ungefähr alle zwei Monate werden die Ergebnisse der Sprints in einem release gebündelt und die Verbesserungen ausgeliefert. Das Feedback des Kunden fließt in kurzen Abständen direkt in die Weiterentwicklung ein.
agile Umsetzung: Scope ist variabel, Ressourcen und Termine werden stabil gehalten
In agiler Organisation ist der scope variabel — was nicht bedeutet, dass ‘alles Mögliche’ herauskommen kann.
Ein variabler Scope bedeutet: Das Team versucht so gut als möglich mit den gegebenen Randbedingungen das zu liefern, was der Kunde im unmittelbar nächsten Planungshorizont am Nötigsten braucht. Es werden diejenigen features zuerst implementiert und ausgeliefert, die akut den meisten Nutzen stiften.
Natürlich macht man sich auch zu Beginn einer agil organisierten Softwareentwicklung Gedanken über den Scope: in der Produktvision werden Eigenschaften des fertigen Produktes festgelegt ohne ins Detail zu gehen oder Lösungen zu setzen. Schließlich weiß am Anfang noch niemand — auch der Kunde nicht — wo genau die Reise hingeht.
must-haves stiften den Nutzen im Produktkern
Es wird in jeder Produkt- oder Softwareentwicklung ein paar must-have-Features geben, die den Produktkern ausmachen. Und ebenso nice-to-have oder pet-Features, die nicht ganz so entscheidend sind. Diese randständigen Produkteigenschaften werden im Laufe des Projektes implementiert und wenn dafür Kapazitäten vorhanden sind.
Hier wird der Hauptnutzen eines sauber gepflegten Backlog einleuchtend: da immer die wertvollsten Eigenschaften oben liegen, kann man sicher sein, dass die Dinge mit dem höchsten Wert auch zuerst erledigt werden.
pet features stecken im Feature-Puffer
Gegen Ende des Vorhabens kommen die pet-Features, die einen geringeren angenommenen oder erwarteten Kundennutzen oder business value haben.
Pet-Features sind ein weiterer Puffer. Man kann jederzeit transparent sehen, was noch erledigt werden könnte, wenn Kapazität bleibt.
Das ist ein großer Unterschied zu Zeitpuffern in konventionell-deterministischer Planung, in der die Präzision einzelner Schätzwerte für Meilensteine und Tasks die Planungsqualität massgeblich bestimmt.
Bewegung im Anforderungskorridor
Wenn sich an den ursprünglich formulierten Anforderungen nichts ändert, wird man in einem Korridor zwischen einer optimistischen und einer pessimistischen Schätzung dieser Anforderungen landen.
Wenn sich doch etwas an Anforderungen ändert, kann frühzeitig der Nutzen einer Implementierung abgewogen werden.
Es stimmt also nicht, dass ‘man agil nichts planen kann’.
Im Gegenteil: durch laufende Priorisierung und die Integration von Nutzerfeedback wird zielgerichtet dafür gesorgt, dass die wichtigsten Eigenschaften geliefert werden. So kann produktiv mit Unsicherheiten umgegangen werden.
Die Prognose, wann welches Feature vorhanden sein wird, hat mit agilen Methoden keinen Zeitpunkt, sondern einen Zielbereich.
In konventioneller Planung steht bei Störungen der gesamte Liefertermin und nicht einzelne Features zur Disposition.
Dass mit agiler Planung keine sichere Aussage über den Auslieferungstermin eines einzigen Features gemacht werden, liegt nicht an der verwendeten Methode — sondern an der mit Unsicherheiten behafteten, komplexen Umgebung und daran, dass die beiden Variablen Ressource und Termin als Ecken des Dreiecks fixiert werden und damit der Scope variieren muss.
Release burn-down Chart: wann kriege ich mein feature?
Die Grafik zeigt ein stilisiertes Release burn-down Chart eines Teams.
Auf der vertikalen Achse sind die noch zu implementierenden Features aufgetragen, gemessen in story points als relative Aufwandschätzung. Auf der horizontalen Achse ist die Zeit bis zum geplanten Release-Datum aufgetragen.
Das Release burn-down Chart wird nach jedem Sprint aktualisiert.
Der Wert auf der y-Achse ‘schrumpft’ dabei um die Story Points der in diesem Sprint umgesetzten Stories.
Der blau hinterlegte Bereich zeigt die Lieferprognose, wenn alles kommt, wie geplant. Das heißt: wenn dem Team nichts dazwischen kommt, die Schätzungen nach einheitslosen, die Komplexität beschreibenden Story Points passen und die Velocity unverändert bleibt.
Die beiden roten Strichlinien zeigen die Prognosen für eine optimistische (steile Kurve links) bzw. pessimistische (flache Kurve rechts) Annahme für die Velocity. Kommt das Team mit der Umsetzung schneller voran (Kurve links): gute Chancen, dass der rote Bereich auch noch geliefert werden wird. Treten Schwierigkeiten auf und die Dinge verzögern sich dadurch, dann sinkt die Velocity und es können weniger Story Points ausgeliefert werden.
Der Schnittpunkt mit den grau gestrichelten Release-Terminen, welche Features bis zu diesem Datum voraussichtlich fertig werden. Fertig werden WENN das Team stabil bleibt, nichts schief geht und nichts Neues und Wichtiges hinzukommt. Der Product Owner kann frühzeitig mit seinen Stakeholdern über eine Verschiebung von Features in ein späteres Release nachdenken.
Velocity als teamindividuelles Muster
Nach vielen Sprints zeigt sich in diesem Muster die Velocity des Teams. Es ist also die teamindividuelle Geschwindigkeit, das Muster für jedes stabile Team. Keinesfalls ist die Velocity eine Vergleichsgröße zwischen Teams. Jedes Team ist spezifisch und hat einen eigenen Footprint.
Gleichzeitig kann das Release burn-down Chart genutzt werden, um eine Prognose und Orientierung zu geben ob es möglich sein wird, den noch im Backlog vorhandenen Feature-Umfang bis zum geplanten Release-Termin umzusetzen.
Wie gesagt und wichtig: für jedes stabile Team eine eigene Prognose und nicht übertragbar oder vergleichbar zwischen Teams. Velocity ist kein KPI.
Änderungen? Gerne!
In agiler Entwicklung wird erwartet, dass Wünsche nach Features sich in der Implementierung ändern. ‘Embrace change’ bedeutet: Änderungen herzlich willkommen. Es wird anerkannt, dass die Welt sich ändert und mit ihr auch Bedürfnisse.
Es ist eine gute Praxis, diese unterwegs neu hinzukommenden Features in einer anderen Farbe im Backlog zu markieren.
Das einfache Burn-Down-Chart erzeugt also Transparenz über die realistischen Bedingungen. Schwierigkeiten mit dem Lieferumfang kündigen sich rechtzeitig an, um angemessen darauf reagieren zu können.
Das muss man aushalten lernen und das Backlog laufend nach den Bedarfen aller Stakeholder priorisieren.
Reflexionsfragen
- Wie oft haben Sie in Ihren Projekten eine Punktlandung erreicht?
- Und wenn es gelang: was waren die Gründe?
Was hat dazu geführt, dass eine Planung auch wie geplant umgesetzt wurde? - Was hat dazu geführt, dass Planungen im konventionellen Projektgeschäft nicht eingehalten werden konnten?
- Wie zufrieden waren die Kunden mit dem Ergebnis bei einem konventionellen Projekt?
Gab es nachträglich Change Requests?