Erfolgreiche agile Projekte jenseits von Anarchie und Kontrollwahn

Am 8. Juni 2016 hatte ich die Gelegenheit, auf dem 7. PM Symposium in Wien einen Vortrag über agile Projekte zu halten. Das Thema der Veranstaltung lautete „Projektcontrolling, Risiko- und Claimmanagement zwischen Anarchie und Kontrollwahn“. Aus meiner Perspektive, der des agilen Projektmanagements, wurde mir schnell klar, dass ich agile Methoden als gute Balance zwischen diesen beiden Extremen vorstellen kann - vorausgesetzt, die Methodik wird diszipliniert eingesetzt.Warum werden Agilität und Scrum oft mit Chaos oder Anarchie verbunden? Ich denke, es liegt leider tatsächlich an den vielen Organisationen, die agile Methoden eingeführt haben, aber dessen Werte und Prinzipien in der täglichen Arbeit nicht leben und sich mit einer Vielzahl von Kompromissen zufrieden geben. Agile Methoden bieten sehr wohl geeignete Ansätze, um Aufgaben des Controllings und Risikomanagements wahrzunehmen. Beim Claimmanagement drängt sich die Frage auf, ob es in seiner PM-Definition so überhaupt noch Anwendung finden kann. Aber alles der Reihe nach.

Das Projektcontrolling

In agilen Projekten plädiere ich gerne dafür, das magische Projektmanagement-Dreieck auf den Kopf zu stellen. Ausgehend von einem fixen Termin und einem fixen Budget soll mit Hilfe eines variablen Scopes das optimale Ergebnis zu den fixierten Randbedingungen erzielt werden. Mit Hilfe kurzer Iterationen können wir regelmäßig die gelieferten Ergebnisse begutachten und Feedback geben. Das Management kann so als Venture Capitalist agieren und wie in einem Stage-Gate-Prozess schrittweise mehr Geld für die Investition freigeben oder das Vorhaben „killen“. Eigentlich logisch und plausibel. In der freien Marktwirtschaft passiert das genau so!Wichtig ist auch, das Richtige zu messen, nämlich den Nutzen oder die Zufriedenheit mit dem Ergebnis. Die Standish Group stellt im aktuellen CHAOS Report einmal mehr fest, dass auch die Einhaltung aller Ecken des PM-Dreiecks (Budget, Zeit und Scope) den Kunden nicht automatisch zufrieden stellt. Stattdessen sollten die Features priorisiert nach Kundennutzen oder Business Value kontinuierlich entwickelt werden, bis man nüchtern feststellen kann, dass sich jede weitere Investition nicht mehr lohnen würde, da es sich nur mehr um Add-ons handelt, die selten benötigt werden. Man schließt das Projekt ab und widmet sich dem nächsten Vorhaben.Der klassische Ansatz der agilen Releaseplanung arbeitet mit Hilfe eines Worst und Best Case Szenarios für die Velocity des oder der Teams. Anhand dieser Szenarien kann der Liefertermin für eine definierte Anzahl an User Story Points prognostiziert werden. Das erlaubt dem Product Owner eine rechtzeitige Einschätzung, ob das gesetzte Ziel erreicht werden kann. Eine weitere Variante der agilen Releaseplanung orientiert sich an der durchschnittlichen Lead Time von User Stories. Der Vorteil dieses Modells ist das Controlling der Durchsätze und der Lieferzeiten, um so dem Kunden genaue Aussagen über den Liefertermin bei Einmeldung der Anforderung zusagen zu können. Wichtigster Bestandteil für diese Steuerung ist die Begrenzung des Product Backlogs auf eine fixe Anzahl an Items (idealerweise <= 50). Anschließend wird für jede Anforderung, sobald sie in diesem sogenannten Committed Backlog landet, mit einem „Entry Date“ versehen. Nach Fertigstellung durch das Team erhält die Anforderung ein „Delivery Date“. Über eine größere Menge an User Stories kann so herausgefunden werden, was die durchschnittliche und die maximale Lead Time des Teams ist. Wird eine neue Anforderung vom Kunden nun aufgenommen, kann mit diesen Werten eine gute Einschätzung gegeben werden.

Das Risikomanagement

Meines Erachtens ist das Risikomanagement dem agilen Prozess inhärent. Durch die regelmäßige Lieferung von Ergebnissen kann ein katastrophales Projektergebnis de facto ausgeschlossen werden, parallel dazu reduziert sich das Risiko, vollkommen an der Zufriedenheit des Kunden vorbei zu arbeiten. Durch eine kleine Timebox wird das Team außerdem zum kreativen Umgang mit Risiken gezwungen, denn es ist nicht möglich, große Konzepte innerhalb von zwei Wochen zu erstellen. Stattdessen geht es darum, schnell Prototypen oder Proof of Concepts zu entwickeln, um zu beweisen, dass das Versprochene tatsächlich möglich ist. Und zu guter Letzt gibt es natürlich den ScrumMaster, eine Rolle in Scrum, die sich gänzlich der Produktivität des Teams verschrieben hat. Eine seiner wesentlichen Aufgaben ist das Führen und Pflegen eines öffentlichen Impediment-Backlogs, das alle Hindernisse des Teams und etwaige Risiken transparent für alle sichtbar darstellt.

Das Claimmangement

Bei Betrachtung des agilen Manifests wird schnell klar: Es geht um eine vertrauensvolle Zusammenarbeit mit dem Kunden und nicht um das Pochen auf Verträge. Im Claimmanagement wird häufig davon gesprochen, vereinbarte Bereitstellungen des Kunden einzufordern. Kurz und knapp könnten wir in agilen Projekten sagen, dass der Haupt-Claim die Mitwirkung des Kunden im Entwicklungsprozess ist. Es geht darum, den Kunden so in den Prozess zu integrieren, dass er kontinuierlich Feedback gibt und Verantwortung bei der Priorisierung der nächsten Anforderungen übernimmt. So entsteht eine neue Dimension der Zusammenarbeit, in der direkt am Kunden entwickelt wird und an deren Ende vielleicht sogar die Abschaffung von Anforderungslisten entsteht.