Sind agile Projekte und Termintreue von Roadmap-Meilensteinen zu vereinbaren?

Question

In Zusammenarbeit mit meinen Kunden kommt häufig die Frage auf, ob sich agile Projekte mit der Einhaltung von klassischen Meilensteinen oder auch "moderneren" Roadmapansätzen vereinbaren lassen.
Bei klassischen Ansätzen steht ja häufig die Frage im Mittelpunkt: 

• "Wie schaffen wir den Termin für Meilenstein x?" 

In agilen Ansätzen steht dagegen die Frage im Vordergrund: 

• "Ist das, was wir bauen überhaupt das, was wir brauchen um die Bedürfnisse der Kunden zu erfüllen / sie zu begeistern?"

Ich persönlich habe hierfür unterschiedliche Ansätze kennengelernt, z.B. Magic Estimation sowie Event Storming zur Identifikation eines Minimal Viable Products (MVP), womit man eine erste Übersicht zu Terminen auf Quartalsebene zur Erreichung von Zielen auf Epic-Ebene erarbeiten kann. Was aber, wenn die Kunden agiler Projekte eine höhere Detailtreue wünschen? Sind agile Ansätze dann noch das "richtige" Vorgehen und wenn ja: Was ist erforderlich, um mit den Kunden einen erfolgreichen Weg zur Zielerreichung gemeinsam zu gestalten?

Answer 1

Aus meiner Sicht ist das nicht nur kein Widerspruch, sondern bedingt geradezu eine agile Vorgehensweise. Ziele zu haben ist zunächst einmal eine Voraussetzung, damit alle verstehen, was überhaupt erreicht werden soll. Nun kommt der agile Gedanke ins Spiel: Was ist in der verfügbaren Zeit das Wichtigste und Mögliche, um das Ziel erreichen zu können? Um hier mit innovativen Lösungsideen einen passablen Weg zum Ziel zu finden, ist eine enge Kommunikation zwischen dem Entwicklungsteam und dem Ziel-Owner nötig. Diese enge Kommunikation muss - falls noch nicht vorhanden - zunächst ermöglicht werden. Nur wenn das Entwicklungsteam das zu lösende Problem, Kundenbedürfnis oder schlicht zu erreichende Ziel gut verstanden hat, ist eine lösungsfokussierte Herangehensweise überhaupt erst möglich.

Leider beobachtete ich oft, dass außerhalb des Entwicklungsteams bereits Lösungsideen entwickelt wurden und diese dann als 'Anforderungen' im Backlog niedergeschrieben sind. Dies hat jedoch ziemliche Nachteile, die ich hier erwähnen möchte:

- Wenn Lösungsideen bereits als 'Anforderungen' beschrieben wurden, steht nicht mehr im Fokus, was das eigentlich zu lösende Ursprungsproblem war. Die Diskussionen drehen sich dann nur noch darum, ob die Lösungsidee in der gegebenen Zeit umgesetzt werden kann oder nicht? Was aber, wenn die Zeit nicht ausreicht? Die Folge: Druck, Druck, Druck.

- Lösungsideen sind deshalb keine Anforderungen (= etwas müsse sein). Tatsächlich sind Lösungsideen lediglich Hypothesen, dass diese Idee das zugrunde liegende Problem lösen könne. Das muss aber nicht so sein. Softwareentwicklung ist zu komplex, als das man alle dynamischen Überraschungsmomente vorhersehen könnte. Also Vorsicht! Es gibt meistens mehr als einen Weg zum Ziel und Agilität nimmt für sich in Anspruch, dass sich die beste Lösungsidee schnell herauskristallisiert. Dazu muss ein Entwicklungsteam jedoch experimentieren können. Kann es das, wenn eine im Backlog niedergeschriebene Idee sich bereits manifestiert hat?

Was sich trotz oberflächlich korrektem iterativen Scrum-Vorgehen so wie eben beschrieben darstellt ist im Grunde sehr ähnlich dem traditionellem Wasserfallvorgehen. Irgendwo wurde ein zu lösendes Problem sichtbar und eine Idee zur Lösung wird geboren. Diese wird im Backlog niedergeschrieben und nicht mehr weiter hinterfragt. Ein Entwicklungsteam soll diese 'Anforderungen' umsetzen. Getestet wird gegen die 'Anforderung' und nicht gegen das eigentlich zugrunde liegende Problem. Das hat sehr wenig mit Agilität zu tun.

Der Schlüssel zum lösungsfokussiertem, agilen Umgang mit herausfordernden und zeitlimitierten Zielen liegt also nicht in der iterativen Umsetzung bereits manifestierter 'Anforderungen', sondern in der experimentellen und selbstorganisierten Herantastung auf ein Ziel hin, durch ein befähigtes und autonom entscheiden könnendes Entwicklungsteam, das das zugrunde liegende und von ihm zu lösende Problem (oder das Kundenbedürfnis) vollumfänglich verstanden hat.

Das klingt jetzt recht abstrakt. Dazu ein anschauliches Beispiel:

Man stelle sich ein Fahradverleih-Unternehmen vor. Der Chef (oder zuständige Verkäufer) kommt auf sein Wartungsteam zu und sagt: "Wir benötigen für dieses Wochenende 20 Fahrräder, für die wir Buchungen bereits entgegen genommen haben. Bitte sorgt dafür, dass 20 intakte Radl bereitstehen." Das Wartungsteam stöhnt und entgegnet dem Chef: "Das werden wir nicht schaffen können. Wir haben zur 12 funktionierende Fahhräder, bei 4 anderen müsste noch die Kette instandgesetzt werden und bei weiteren 4 müssten noch neue Mäntel auf die Räder aufgezogen werden. Alleine das wird nicht möglich sein, da wir die Mäntel erst noch besorgen müssten. Das bekommen wir so schnell nicht geliefert." Der Chef bleibt hartnäckig - schließlich sind die Fahrräder ja schon beauftragt. Also lässt sich das Wartungsteam unter Widerwillen ein auf die Forderung. Es werden Überstunden gemacht und weil die notwendigen Mäntel nicht geliefert werden können, montiert das Wartungsteam bereits gebrauchte, aber gerade noch akzeptable Mäntel auf die Fahrräder (Stichwort: secret toolbox, mindere Qualität wird verbaut. Das Team hofft, dass es schon keine Platten geben wird).

Die eben erzählte Geschichte wäre das klassische Wasserfallvorgehen. Nun die agile Variante:

Wiederum kommt der Chef zum Wartungsteam. Dieses Mal erklärt er jedoch Folgendes: "Ein 20 Personen starker Tennisverein möchte am Wochenende einen gemeinsamen Fahrradausflug machen. Wir haben dem Kunden bereits zugesagt, dass wir die Radl bereitstellen können. Bitte macht das möglich." Das Wartungsteam antwortet genau wie in der ersten Variante der Geschichte: "12 intakte Radl, noch 4 Ketten instandzusetzen, 4 neue Mäntel aufzuziehen, die aber erst noch bestellt werden müssen. Kurzum: nicht zu schaffen." In Kenntnis des eigentlichen Kundenbedürfnisses (20 Personen starker Tennisverein) kann JETZT das Wartungsteam jedoch innovative Lösungsalternativen anbieten: "Die Instandsetzung aller Fahrräder werden wir nicht schaffen, ABER wir haben 2 intakte Tandems hier. Vielleicht sind beim Tennisverein ein paar Menschen dabei, die gerne mal Tandem ausprobieren möchten und Spaß daran finden? Dann wären nur noch 4 Fahrräder anstatt weitere 8 instandzusetzen, was leicht möglich wäre." (Nebenbemerkung: Und das ohne Überstunden und ohne mindere Qualität!) Man hält kurz Rücksprache mit dem Tennisverein und siehe da, diese Lösungsalternative ist für den Tennisverein akzeptabel.

Was ist hier also passiert? Zunächst überprüft das Wartungsteam eine Lösungsoption, bei dem 8 normale Einzelfahrräder instand zu setzen gewesen wären. Dies wäre aber weder zeitlich, noch in der geforderten Qualität möglich gewesen. Diese Option scheidet also aus und sofort überlegt sich das Wartungsteam eine alternative Lösungsoption, die nun mit den gegebenen Bedingungen (Zeit und Qualität) gut vereinbar ist. Es hat also spontan auf agile Art und Weise reagiert und konnte somit sein Ziel erreichen. Das ist Agilität, die aber nur deshalb möglich gewesen ist, WEIL das Wartungsteam direkt mit dem Kundenbedürfnis konfrontiert wurde und nicht mit einer geforderten Arbeitsanweisung wie in der ersten Version der Geschichte.

Freilich ist nicht immer garantiert, dass jedes Ziel und jeder Meilenstein auf diese Art und Weise gelöst werden kann. Zum Beispiel hätte es sein können, dass die Idee mit den Tandems vom Tennisverein abgelehnt worden wäre. Darum geht es mir hier aber nicht. Vielmehr geht es mir darum, dass OHNE die wirkliche Kenntnis des zugrundeliegenden Problems, erst gar keine Lösungsalternative hätte gefunden werden können. Und das ist schade, weil ein Unternehmen damit vom Innovationspotential seiner Mitarbeiter erst gar nicht profitieren kann. Aus diesem Grunde empfehle ich meinen Kunden: Schreibt keine 'Anforderungen' in Form von bereits vorgedachten Lösungsideen ins Backlog, sondern beschreibt lediglich das Kundenbedürfnis und lasst das Entwicklungsteam dann innovative Lösungen finden. Dies entspricht übrigens auch ganz dem Sinne der User Stories, die ja gerade deshalb so heißen, weil sie nichts anderes sind als ein 'Platzhalter für eine noch zu haltende Diskussion'.

Answer 2

Ich möchte zusätzlich noch eingehen auf den Wunsch nach mehr Detailtreue. Wir alle sind es gewohnt, dass wir versuchen einen möglichst guten Plan von vorne herein zu definieren, damit die Risiken früh erkannt werden und man überhaupt erst gar nicht in ein Problem läuft. Dieser Wunsch nach früher Sicherheit ist nur zu verständlich, ist nur leider nicht vereinbar mit einem komplexen Sachverhalt, bei dem sich erst auf dem Weg herauskristallisiert, was funktioniert und was nicht.

Hier wird also das eigentliche Problem verursacht. Denn wir denken nur, dass unser Plan bereits so gut ist, dass die meisten Risiken bereits berücksichtigt sind. Auch hier kommt wieder das psychologisch wirksame und schädliche Denken in 'Anforderungen' zum Tragen. Denn unter Komplexität gilt: Jede Lösungsidee, die noch nicht umgesetzt wurde ist und bleibt eine Hypothese!

Hat man sich erst einmal mit diesem Gedanken angefreundet, fällt es leichter eben nicht mehr zu versuchen, alles vorweg zu planen. Und zwar aus ganz logischen Gründen: Was, wenn die Hypothese sich als falsch erweist? Dann wären nämlich alle bisherigen Anstrengungen (in Form von Zeit und Geld) unwiederbringlich verloren. Deshalb drängt sich beim Denkmodell in Form von Hypothesen statt Anforderungen sofort die Frage auf: Wie können wir möglichst schnell heraus finden, ob unsere Hypothese richtig ist?

Man hangelt sich also von einer Hypothese zur nächsten vor, immer in Richtung auf das Ziel und kann dabei schnell gegensteuern, sollten Überraschungen auftreten. Es mag unserem Wunsch nach Sicherheit widersprechen, so zu arbeiten. Defacto bleibt aber festzuhalten, dass diese Herangehensweise die besten Chancen auf Erfolg hat.

Auf der anderen Seite möchte man frühzeitig wissen, ob denn überhaupt das Ziel erreicht werden kann. Das heißt, eine gewisse Planung (in Form von Lösungshypothesen!) ist nicht nur wünschenswert, sondern auch sinnvoll. Woher soll man sonst wissen, ob ein Meilenstein gehalten werden kann? In der Praxis ist dies mit schlanken Herangehensweisen, wie Du das schon angedeutet hast, sehr einfach und ohne große Aufwände möglich. Dazu bieten sich neben den bereits genannten Werkzeugen Magic Estimation und Event Storming, z.B. Burnup-Charts an. Mittels dieser kann ein Überblick gegeben werden können, mit welcher Wahrscheinlichkeit der aktuelle favorisierte Plan (wiederum: in Form von Lösungshypothesen) den Meilenstein einhalten kann. Stellt sich heraus, dass es sehr unwahrscheinlich ist, müssen eben andere Wege gefunden werden, um das Ziel zu erreichen. Dwight D. Eisenhower hat einmal gesagt: "Plans are worthless, but planning is everything." Dem stimme ich zu. Im Agilen wird - wie oft missverständlich behauptet wird - nicht nicht geplant, sondern es wird ständig geplant und Änderungen am Plan sind an der Tagesordnung. Wie agil hier eine Organisation solche Änderungen erarbeiten kann, hat maßgeblichen Einfluss auf die Erfolgschancen, dass die gesteckten Ziele auch erreicht werden. Traditionelle Strukturen, abgeteilte Funtionseinheiten, viele Abhängigkeiten zwischen Abteilungen, Kommunikation über Dokumente anstatt miteinander zu Reden, Entscheidungsbefugnisse nur an zentralen Stellen (= Engpass!) machen diese Notwendigkeit nach schneller Planänderung zu langsam und damit zu teuer und verhindern effektive Agilität. Und erhöhen damit vehement die Risiken, dass ein Ziel nicht erreicht wird.