Agile Festpreisprojekte

In diesem Blogeintrag werden die wesentlichen Erfahrungen aus der Durchführung von agilen Festpreisprojekten zusammengefasst. Der Autor hat viele agile Festpreisprojekte in einer Größenordnung von bis zu 3000 Manntagen pro Release/Vertrag durchgeführt. 

Der Widerspruch

Der „Agile Festpreis“ ist auf den ersten Blick ein Widerspruch in sich. Zum einen enthält der Begriff das Wort „agil“, welches für einen fixen Zeitrahmen, ein fixes Budget und variable Anforderungen steht, zum anderen das Wort „Festpreis“, was einen fest definierten Anforderungskatalog und ein festes Budget bedeutet. Meistens ist auch der Zeitrahmen vertraglich fixiert oder über Pönalregelungen gesondert festgelegt.

Warum sollte es agile Festpreisprojekte geben?

  • Zum einen haben sich agile Projekte in den letzten Jahren als erfolgreiche Modelle der Softwareentwicklung bewährt. Business und IT haben die Vorzüge schätzen gelernt.
  • Zum anderen werden Budgets für größere Projekte nur noch selten vergeben, wenn im Vorfeld nicht definiert ist, was im Rahmen des Projektes umgesetzt werden soll. Wenn die Dienstleistung dann auch noch durch einen externen Dienstleister erbracht werden soll, bestehen die Einkaufsabteilungen in der Regel auf einem Vertrag, der es ermöglicht, das Risiko mit dem Dienstleister zu teilen oder es komplett bei ihm zu lassen.  

Was gehört in ein Angebot bzw. Projektproposal?

Bei der Angebotserstellung für ein Festpreisprojekt gilt es im Vorfeld einige Dinge zu beachten. Diese sind „Best Practices“ und unabhängig davon, ob ein interner oder externer Dienstleister die Implementierungsleistung erbringt.

  •  Die Anforderungen sind so zu beschreiben, dass sie zum einen hinreichend genau sind und zum anderen ausreichend Gestaltungsspielraum im Projektverlauf lassen.
  • Beispiel: Möchte man einen „eCommerce“-Shop aufbauen, so kann man die Anforderung „Einkaufsvorgang“ folgendermaßen beschreiben: „Implementierung eines Checkout-Prozesses, der es dem Kunden ermöglicht, seine Einkäufe über die Bezahlmethoden „Kreditkarte“ oder „Rechnung“ abzuwickeln“. Damit hat man noch nicht definiert, wie der Checkout-Prozess aussieht (ein- oder mehrseitig), ob eine direkte Anbindung an einen Kreditkarten-Dienstleister stattfindet oder eigene Inhouse-Systeme angebunden werden etc. (Ob man die Anforderung als User Story schreibt oder in Prosa, ist dabei unerheblich und eher abhängig von der Fachkenntnis des Vertragspartners. In der Regel ist diese gerade beim Einkauf nicht gegeben.)
  • Eine Liste aller Anforderungen muss unbedingt im Vorfeld und im Rahmen einer Expertenschätzung erstellt werden. Es hat sich bewährt, die Größen der einzelnen Anforderungen in einer abstrakten Punktzahl zu bemessen (ähnlich den Feature Points auf Teamebene).
  • Die Projektlänge und die Anzahl der Sprints (Implementierungsintervalle) müssen definiert werden.
  • Es muss eine Roadmap bzw. eine Sprintplanung der Anforderungen erstellt werden, welche die Anforderungen für die einzelnen Sprints festlegt.
  • Die Mitwirkungspflichten des Auftraggebers müssen festgelegt werden. Besonders hervorzuheben sind die die proaktive Teilnahme an Sprint Plannings, Sprint Priorizations und Sprint-Retrospektiven.

 

Was muss man im Projektverlauf beachten?

Wie in jedem Projekt ist Disziplin ist der Schlüssel zum Erfolg.

In einem Wasserfallprojekt ziehen sich viele Fachabteilungen nach Abgabe der Fachkonzepte in der Implementierungs- und den ersten Testphasen zurück. In der Regel werden sie in Steering Committees über den Projektverlauf informiert und bei Bedarf bei Change Requests hinzugezogen.

Im Unterschied dazu sind in einem agilen Festpreisprojekt Disziplin und aktive Beteiligung während des gesamten Projektverlaufs gefordert. Oder mit anderen Worten, der Auftraggeber – in der Regel die Business-Einheiten – muss zwingend am Projekt teilnehmen und in die Pflicht genommen werden. Diese Disziplin muss gelebt und durch geeignete Instrumentarien operationalisiert werden.

In der Praxis haben sich die folgenden Instrumente bewährt:

  • Die Projekt-Roadmap, welche die Anforderungen auf Sprints verteilt darstellt. Sie schafft im Projektverlauf immer wieder Transparenz.
  • Ein Expertenteam aus mindestens einem Lead Business Analyst und einem Lead-Architekten. Diese müssen mit dem gesamten Anforderungskatalog vertraut sein, die Expertenschätzungen zusammen mit der Projektleitung durchführen und immer beobachten, ob sich Anforderungen signifikant ändern. Beide behalten den Überblick und müssen aufwandsteigernde Anforderungen erkennen und kommunizieren.
    Das Expertenteam ersetzt nicht den Product Owner. Der Product Owner, der den Kunden repräsentiert, trifft weiterhin die Entscheidungen über die umzusetzenden Anforderungen. Das Expertenteam hat in der Beziehung zum Product Owner die Rolle des Beraters. Diese ausgewiesenen Experten in ihrem Bereich sollen Lösungsansätze zu den Anforderungen erarbeiten und mit Product Owner und Team diskutieren und bewerten. Sie haben somit die wichtige Aufgabe, Lösungsvorschläge für Anforderungen so zu entwerfen, dass die Roadmap eingehalten werden kann.
  • Regelmeetings mit dem Auftraggeber. Diese sind:
  • Sprint Priorization Meetings
  • Mindestens einmal pro Sprint wird das Backlog betrachtet, analysiert und auf Veränderungen in den Anforderungen untersucht.
  • Aufwandstreiber – z.B. neue Business-Anforderungen – werden besprochen und bei Bedarf gegen ursprünglich geplante Anforderungen ausgetauscht. Dabei sollte ein Austausch immer dem Leitsatz „Quid pro Quo“ folgen, d.h. die Aufwände sollten sich bei einem Austausch neutralisieren.
  • Änderungen in der Roadmap müssen besprochen und neue Risiken transparent dargestellt und bewertet werden.
  • Expertenschätzungen für neue Business-Anforderungen werden ebenfalls in diesem Kreis vorgestellt. Hier gilt es aus Sicht des Projektteams darauf zu achten, dass häufige Änderungen unterbleiben, sodass die Experten nicht ständig mit neuen Anforderungen konfrontiert und damit in ihrer Arbeit blockiert werden.
  • Sprint Refinements
  • Der Kunde muss eine aktive Rolle spielen, wenn Anforderungen im Team vorgestellt und besprochen werden.
  • Bewährt hat sich ein wöchentliches Refinement Meeting, in dem die geplanten Anforderungen für den Folgesprint besprochen werden. Die Teilnahme der Experten an dieser Runde ist verpflichtend.
  • Sprint Commitments (am Endes des Sprint Plannings)
  • Am Ende des Sprint Planning Tags stellen die Teams ihre Ziele für den nächsten Sprint vor und verpflichten sich auf diese.
  • In der Regel sollten für das Sprint Planning die für diesen Sprint geplanten Anforderungen der Roadmap bestätigt werden. Falls es zu Abweichungen kommt, ist dies seitens der Projektleitung zu untersuchen. Sollte die Ursache nicht in Unzulänglichkeiten des Projektteams liegen (z.B. Urlaub, Krankheit, Skill-Abwanderung), sondern in unerwarteten Anforderungen, so muss dies spätestens in den Sprint-Priorisierungs-Runden erörtert werden. Bei selbstverschuldeten Verzögerungen ist der Auftragnehmer gefordert, diese aufzuholen.
  • Die Commitments eines Sprints sind ebenfalls schriftlich zu fixieren und zu kommunizieren.
  • Sprint Reviews
  • Dem Kunden werden die Ergebnisse des Sprints vorgestellt. Implizit nimmt er in diesen Runden die Ergebnisse an.
  • Die Projektleiter müssen die Abarbeitung der Roadmap erläutern; einerseits, um den Projektfortschritt transparent darzustellen, und zum anderen, um sich vom Kunden die erreichten Ziele bestätigen zu lassen.
  • Ergebnisse des Sprint Reviews müssen schriftlich fixiert werden. In der Regel reicht eine kurze Darstellung, welche Anforderungen umgesetzt wurden.
  • Nicht erreichte Ziele des Projektteams gehen in der Regel zu Lasten des Auftragnehmers.

Wünschenswert ist die Teilnahme des Auftraggebers an den folgenden Meetings:

  • Tägliche Teilnahme an den Daily Scrums; bei Projekten mit mehr als einem Team die Teilnahme an den Scrum Of Scrums.
  • Sprint Plannings

Fazit

  • Ein agiles Festpreisprojekt ist ein geeignetes Instrument, um Umsetzungsdisziplin in der agilen Vorgehensweise einzuhalten.
  • Das wesentliche neue Instrument gegenüber dem „normalen“ agilen Ansatz ist die bindende Projekt-Roadmap.
  • Der Auftraggeber wird besonders stark in die Verantwortung genommen und trägt somit zum eigenen Projekterfolg bei.
  • Agile Festpreisprojekte sind in der Regel anstrengend, da sich alle Beteiligten während des Projektverlaufs stetig überprüfen müssen.
  • Agile Festpreisprojekte sind nur dann sinnvoll, wenn man sich im Vorfeld schon über die Ziele des Projektes im Klaren ist.
  • Ein agiler Festpreisprojektvertrag sollte in der Regel nicht länger als 3–6 Entwicklungssprints dauern, da sonst die Vorhersehbarkeit und Planbarkeit leidet.
  • Zum Schluss ist noch anzumerken, dass es wenig juristische Erfahrung bei der Erstellung von Verträgen für Festpreisprojekte gibt, da diese Verträge den Spagat zwischen verpflichtender Zulieferung und der Freiheit der Umsetzungstiefe ermöglichen müssen. Die mir bekannten Verträge basieren immer auf dem Vertrauen zwischen den Vertragspartnern, welches gerade durch den agilen und kooperativen Ansatz gefördert wird.