Es ist ein weit verbreitetes Missverständnis, dass sich agile Methoden wie Scrum oder Kanban nicht mit Deadlines oder fixen Lieferterminen in Einklang bringen lassen. Diesem Missverständnis möchte ich mit diesem Artikel widersprechen und Wege aufzeigen, wie agile Methoden unter festen Lieferzusagen vorteilhaft eingesetzt werden können.
In über zwölf Jahren praktischer Erfahrung mit agilen Projekten habe ich durchweg gute Erfahrungen mit den folgenden Ansätzen gemacht, die auch in der Fachliteratur ausführlich beleuchtet worden sind.
Voraussetzungen und Rahmenbedingungen für den Einsatz agiler Methoden
Agile Methoden spielen ihre Stärken vor allem in Problemstellungen aus, in denen eine ausführliche Analyse und eine Planung im Vorfeld schwierig, aufwendig oder fehleranfällig sind. Dafür kann es eine Reihe von Gründen geben:
- Anforderungen können im Vorfeld nicht ermittelt werden oder ändern sich im Projektverlauf.
- Es werden innovative oder ungewöhnliche Technologien verwendet.
- Das Projektumfeld ist von einer hohen Dynamik geprägt, Rahmenbedingungen werden sich voraussichtlich auf unvorhersehbare Weise verändern.
- Es besteht ein hoher Druck, früh erste Ergebnisse zu liefern.
- Wichtige Stakeholder erwarten, im Projektverlauf eng einbezogen zu werden.
- Durch die Lieferung von Ergebnissen werden erwartbar Änderungen der Anforderungen provoziert ("Jetzt, wo wir es sehen, brauchen wir doch etwas anderes …").
- Es gibt Abhängigkeiten zu antagonistischen Akteuren (z.B. Mitbewerber, feindselige Stakeholder), die im Projektverlauf Störungen und Überraschungen einbringen werden.
Je mehr dieser Herausforderungen gegeben sind, desto wahrscheinlicher (und häufiger) werden im Projektverlauf Anforderungen, Lösungsentwürfe und Projektpläne angepasst werden müssen. Das bedeutet nicht, dass eine vorherige Planung deshalb weniger wichtig wäre! Planen ist eine zentrale Aktivität agiler Methoden (in Scrum z.B. im Sprint Planning ritualisiert). Es stellt aber besondere Anforderungen an die Projektpläne, die jederzeit änderbar und daher besonders schlank und leichtgewichtig sein müssen. Projektskizzen auf einem Whiteboard oder dynamische Backlogs sind schneller angepasst als detaillierte Feinspezifikationen oder vertraglich vereinbarte Pflichtenhefte.
Allgemeine Dos und Don'ts im Umgang mit Deadlines
Für den Fall, dass bereits eine detaillierte Feinplanung vorliegt, plädiere ich dafür, das Projekt einfach klassisch umzusetzen. Agile Methoden können kaum einen Mehrwert stiften, wenn bereits eine exakte Durchführung mit fixen Lieferobjekten vereinbart wurde und im Verlauf nicht mit größeren Änderungen zu rechnen ist. Im Folgenden gehe ich daher davon aus, dass es im Projekt zwar feste Liefertermine geben mag, aber zumindest bei Umfang und Funktionalität noch Entscheidungsspielräume offen sind.
Ein bewährter Standardansatz in agilen Projekten mit festen Lieferterminen besteht darin, den Zeit- und Kostenrahmen im Vorfeld zu fixieren, innerhalb dessen Ergebniswert und Kundennutzen über den Projektverlauf hinweg maximiert werden. Mit agilen Methoden für die Planung von Umfang und Aufwand, wie z.B. User Story Mapping (Patton, 2015) und Magic bzw. Affinity Estimation (Gloger, 2014), kann dieser Rahmen initial festgelegt werden, ohne dabei den Funktionsumfang schon allzu genau festlegen zu müssen.
Insgesamt empfiehlt es sich auch bei festen Lieferterminen, das Projekt auf Basis bewährter agiler Prinzipien aufzubauen. Hierzu gehört unter anderem
- ein empirisches, faktenbasiertes Vorgehen,
- Optionen offen zu halten,
- Entscheidungen so früh wie nötig, aber so spät wie möglich zu treffen,
- die Fähigkeit, einen anfangs groben Plan laufend auf Basis neuer Erkenntnisse zu aktualisieren und zu verfeinern.
Techniken für die Praxis
Eine Herausforderung des Ansatzes "Zeit/Kosten fix, Inhalt/Umfang variabel" ist, dass Projekte in der Regel bestimmte Mindestziele erreichen müssen, ihr Scope also nicht komplett frei gestaltet werden kann. Beispielsweise wird ein neues Onlinebanking-System ohne grundlegende Funktionen wie An- und Abmeldung, Kontoübersicht, Überweisungen und Daueraufträge nicht in den Produktivbetrieb gehen können. Diese Kernfunktionen sind bereits zum Projektstart ermittelbar und stehen in den meisten Fällen auch nicht zur Diskussion.
Bewusstes Unterspezifizieren
Eine nützliche Technik ist hier das bewusste Unterspezifizieren von Anforderungen. Es spricht auch in agilen Projekten nichts dagegen, Anforderungen wie "Nutzer müssen sich anmelden und ihren Kontostand überprüfen können" bereits zu Projektstart in Form von Akzeptanzkriterien festzuhalten und ihre Umsetzung zu vereinbaren. Der genaue Funktionsumfang, mögliche Komfortfeatures, Feinschliff im Design und ähnliche Aspekte können dann noch während der späteren Umsetzung entschieden werden und bieten dem Team wichtige Entscheidungsspielräume. Viele Teams nutzen die Formulierung von User Storys als Hilfsmittel, um kritische Anforderungen schon früh grob festzuhalten, ohne dabei schwerfällige Feinspezifikationen erstellen zu müssen.
Konsequente Priorisierung
Das ist ja mal ein toller Ratschlag
18.09.2024
Zitat: "Für den Fall, dass bereits eine detaillierte Feinplanung vorliegt, plädiere ich dafür, das Projekt einfach klassisch umzusetzen."
Genau das ist aber bei mir der Fall. Ich habe aber kein Mitspracherecht bei der Implementierung der Prozesse, sondern "agil" ist gesetzt und zwar ausnahmslos für die ganze Firma.
Unsere Kunden (Automobilhersteller) geben auch ganz klare Vorgaben hinsichtlich detaillierte Lastenhefte und zu erreichenden Projektmeilensteinen und Performancezielen zu definierten Zeitpunkten.
Da bleibt kein Raum für das im eigentlichen agilen Gedanken des "Backlog" und "komm ich heut' nicht, komm ich morgen"
Diese Dinge sind einfach UNVEREINBAR!
Und daraus erklärt sich auch, warum Projekte so katastrophal laufen: Es ist die einzige Möglichkeit, wenn sich einige Zahnräder im Getriebe vorwärts drehen und die andere rückwärts.
Ich hatte gehofft in diesem Artikel Lösungshinweise für die existierenden Probleme zu bekommen, aber stattdessen wurde ich vollumfänglich in meiner Meinung bestätigt: Es geht (zumindest bei uns( NICHT!