Agile Methode: Agil Produktentwicklung und das Magische Dreieck des Projektmanagement

Als ich angefangen habe, mich mit agilem Projektmanagement, insbesondere Scrum zu beschäftigen, wurde z.B. in der Scrumguide (http://www.scrumguides.org/download.html) sehr gut beschrieben, wie Scrum gemacht werden sollte und ich fragte mich, warum das Projektmanagement, das ich seit über 10 Jahre lehre, so kompliziert ist.

Mein ganzes Leben wurde leichter. Alle Schwierigkeiten des Projektmanagements, Risiken, Änderungen, Anforderungen, Verträge, Projektcontrolling, Teammotivation, Ressourcenmanagement, Planung, waren auf einmal nicht mehr da. Ich war begeistert.

Stakeholder und Scrum Team erarbeiten gemeinsam das Product Backlog. Das wird in Sprints in einzelnen Inkrementen erstellt. Im Review kommen alle Stakeholder und Scrum Teams wieder zusammen und diskutieren die Änderungen und nach vielen Sprints ist das Product Backlog abgearbeitet und alle sind glücklich.

Insbesondere hat es mich gefreut, dass dieses Magische Dreieck des Projektmanagement, dieser Dreiklang von Scope, Time und Budget, diese Waage mit drei Waagschalen aus Leistung, Zeit und Kosten endlich aus meiner Welt verschwunden war.

Kurz formuliert besagt das Magische Dreieck, dass in einem Projekt zumeist drei Zielbereiche gleichzeitig erreicht werden müssen: Eine bestimmte Leistung soll mit eine bestimmten Budget, innerhalb einer bestimmten Zeit erstellt werden. Stimmt die Relation zwischen diesen drei Zielen nicht, dann befindet sich das Projekt im Ungleichgewicht. Mindestens eines der Ziele kann nicht erreicht werden. 

Mit Scrum besteht dieses Problem auf einmal nicht mehr. 

Ich habe leider den ersten Satz der Scrum Guide überlesen. "Scrum is a framework for developing and sustaining complex products" 

Scrum sagt nichts über Projektmanagement. Es beschäftigt sich nicht mit Projektmanagement. Es ist ausschließlich ein Verfahren zur Produktentwicklung. 

Anders formuliert: Es beschreibt einen Leistungserstellungsprozess. 

Projektmanagement interessiert sich im Gegensatz dazu nicht für den Leistungserstellungsprozess. Es beschreibt nur den Projektmanagementprozess. Und der Projektmanagementprozess ist einer der vielen Unterstützungsprozesse, die den Leistungserstellungsprozess koordinieren sollen.

Leider werfen vielen Menschen agile Leistungserstellungsprozesse und Projektmanagement durcheinander. Dann entstehen Wortkombination von "Agilem Projektmanagement nach Scrum". Diese Wortkombination verbinden Äpfel mit Birnen und der Fellpflege von Katzen. Es sind Wörter, die nichts miteinander zu tun haben. 

Trennen wir uns von der reinen Theorie der agilen Methoden und transferieren wir sie in die Praxis, dann klopft der böse Geist des Magischen Dreiecks bei der Visionsentwicklung für das Produkt wieder an die Hintertür, wenn wir von dem Auftraggeber eine Freigabe für die Produktentwicklung erhalten wollen. Spätestens bei der Entwicklung des Product Backlogs hat uns dieser Dämon dann wieder in seinen Klauen.

Der Auftraggeber stellt so unangenehme Fragen wie:

• Wieviel kostet das Projekt den jetzt genau?
• Wann bekomme ich die Funktionalitäten?
• Welche Leistung bekomme ich den jetzt im Detail?

Fragen, die er zunächst beantworte haben möchte, bevor er einen Auftrag vergibt, bzw. einen Vertrag unterschreibt. 

Agil hat recht. Es ist fast unmöglich genaue Vorhersagen über alle drei Zielvariablen zu machen. Wie sich diese drei Faktoren in der Zukunft entwickeln werden, ist nicht vorhersehbar.

Das löst allerdings unser Problem in der Verhandlung mit dem Auftraggeber nicht. Auch die meisten Auftraggeber sind darauf angewiesen, diese Informationen zu erhalten. 

Die Frage ist jetzt: Gibt es eine "agile Lösung"?

Rubin, K.S. (2014, ISBN 978-3-8266-9047-1, S.351 ff) hat sich dazu einige Gedanken gemacht.

Schauen wir einmal auf den Inhalt einer Timebox, z.B. auf einen Sprint und damit auf die zweitkleinste Einheit der agilen Planung (Tasks sind noch kleinere Einheiten). 

• So eine Timebox ist zeitlich begrenzt. Sie hat immer die gleiche Dauer. 
• In einer solchen Timebox arbeitet ein festgelegtes Entwicklerteam. Da alle Entwickler ihre gesamte Arbeitszeit ausschließlich an der Erstellung der Inkremente für dieses Produkt arbeiten, sind die Arbeitskosten festgelegt.
• Die User Stories, die als Inkremente erstellt werden sollen, werden für jeden Sprint festgelegt und dürfen über den Verlauf der Timebox nicht mehr verändert werden.
• Sollte es einmal dazu kommen, dass doch nicht alle Inkremente erstellt werden können, gehen die damit verbunden User Stories zurück in das Product Backlog.

Damit sind die Variablen des Magischen Dreieckes bestimmt. Die Zeit durch die Dauer der Timebox, die Kosten durch die Personenkosten des Entwicklerteams und die Leistung ist relativ variabel, durch die ausgewählten User Stories, die in seltenen Einzelfällen auch zurück gegeben können.

Berücksichtigen wir zusätzlich, dass die Vorhersagedauer dieser Timebox maximal 4 Wochen lang ist, dann dürfte die Schätzung recht zuverlässig sein. Scrum hat hier ja noch zusätzlich eine Sicherung gegen zu große Wünsche der Stakeholder eingebaut: Die Entscheidung darüber, welche User Stories in dem Sprint aufgenommen werden, liegt exklusiv in den Händen der Leistungsersteller.

Bei den Planungsinstrumenten, in denen größere Einheiten festgelegt werden, ist die Lösung ungleich schwieriger. Bei der Planung des Product Backlogs wird das Problem noch größer. Welche Handlungsmöglichkeiten gibt es:

1. Der erste Fall ist, wie wir gesehen haben, nicht empfehlenswert. Er setzt voraus, dass die Planung über den gesamten Projektverlauf in einem Gleichgewicht steht. Es ist recht unwahrscheinlich, das zu erreichen.

2. Wenn das Budget variabel ist, Leistung und Zeit aber fest stehen, dann bedeutet das meistens, dass wenn "es eng werden sollte" zusätzliche Mitarbeiter in dem Projekt mitarbeiten können, damit die Arbeit auf mehr Menschen verteilt werden kann und damit der Leistungserstellungsprozess schneller durchgeführt wird. Ob diese Möglichkeit in der Realität vorhanden ist, hängt sehr stark von der Gesamtsituation ab. Brooks F. P. (2008, ISBN 978-3826613555) formuliert so schön: "Selbst neun Frauen können nicht in einem Monat ein Baby auf die Welt bringen". Er stellt fest, dass ein verspätetes Sotwareprojekt durch zusätzliche Arbeitskräfte nur noch später fertig gestellt wird. Bevor sich das Management für die zweite Variante entscheiden sollte, lohnt sich also ein sehr genauer Blick auf den Leistungserstellungsprozess des Produktes und die Teamsituation.

3. Auch die dritte Variante bietet nur unter bestimmten Voraussetzungen eine Lösung. Zumeist ist hier kein positiver Effekt zu erwarten. Wenn ein Team mehr Zeit für einen Leistungserstellungsprozess benötigt, dann arbeiten die Menschen zumeist auch länger an diesem Prozess. Das bedeutet aber, dass die Arbeitsleitung über einen längeren Zeitraum bezahlt werden muss, was wiederum zu einer Kostensteigerung führt. Diese Variante ist also nur dann möglich, wenn das Unternehmen die Arbeitskosten der eigenen Mitarbeiter nicht in die Projektkosten einrechnet. Dieses Vorgehen ist kaufmännische allerdings irgendetwas zwischen zweifelhaft und falsch.

4. Die vierte Variante findet sich in der Praxis recht häufig - auch wenn sie meistens "versteckt" praktiziert wird. Einfach können wir auch sagen: "Ist das Geld zu Ende, ist das Projekt zu Ende." Für ein agiles Vorgehen ist das immer dann akzeptabel, wenn viele der User Stories "nice to have" sind. Da die wertmäßig größten Funktionen in der agilen Produktentwicklung zuerst erstellt werden, sollten am Ende der Entwicklung nur noch relativ unbedeutende, wenig wertvolle Anforderungen zu finden sein.

5. Die fünfte Variante stellt ebenfalls einen erfolgversprechenden Lösungsweg dar. Sie ist immer dann zu empfehlen, wenn ein Produkt zu einem bestimmten Zeitpunkt zur Verfügung stehen muss. Wenn das Budget variabel ist, können gegebenfalls mehr Menschen in der Produktentwicklung mitarbeiten (allerdings immer unter der bereits unter 2. genannten Prämisse). Der stärkst Effekt geht von der variablen Leistung aus. Auch hier kommt es zu dem unter 4. beschriebenen Effekt.

6. Die sechste Variante ist die, die in der agilen Produktentwicklung am einfachsten zu realisieren ist. Es ist allerdings sehr unwahrscheinlich, dass ein Kunde einen solchen Auftrag vergeben wird. Für interne Produktentwicklungen kann dieses Vorgehen sehr sinnvoll sein. Hier kann von Timebox zu Timebox im Review entschieden werden, ob die Stakeholder mit den erstellten Funktionalitäten zufrieden sind, oder ob weiterhin an dem Produkt gearbeitet werden soll. Auch der agilen Idee entspricht das am besten. Ausgehend von einer Produktvision und ein paar Epics wird mit der ersten Timebox begonnen, langsam eine optimale Lösung zu erarbeiten. In vielen kleinen Zyklen erfolgt eine Annäherung an ein optimales Ergebnis, das zu Beginn der Produktentwicklung noch nicht bekannt ist. 

Agile Methoden: Übersicht

Alle Seminarangebote 

Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org