“Everyone has a plan until they get punched in the face.”
Mike Tyson

Eigentlich ändert sich alles. Das Vorgehen in einem klassischen, sequentiellen phasischen Projekt sieht vor, dass der Umsetzung eine detaillierte Planungsphase vorausgeht, die eruiert und spezifiziert, was zu tun ist. Das ist bei den agilen Ansätzen nicht so.

Agile Ansätze gehen davon aus, dass eine genaue, detaillierte und spezifische Planung in komplexen Projekten – und das sind die meisten Softwareprojekte – vorab nicht möglich ist. Nicht, weil die, die es versuchen, zu dumm sind! Sondern weil Komplexität, Wechselwirkungen, die heutige Veränderungsgeschwindigkeit usw. es nicht zulassen, ein Jahr im Voraus zu wissen, was man genau braucht bzw. will und wie man es erreichen kann. Schieflagen in der Mehrheit großer Softwareprojekte scheinen das zu bestätigen, etwa in Zahlen von Standish, Gartner, Forrester usw.

Zudem geht der agile Gedankenansatz zweitens davon aus, dass funktionierende Software einen höheren Wert hat als umfassende Dokumentation, vor allem up-front erstellte Spezifikation.

Planen Sie nicht ein Projekt, planen Sie einen Outcome
Und nicht zuletzt geht Agile davon aus, dass die Entdeckung von Features, die nützlich sind, um Geschäftsziele zu erreichen, die zentrale Tätigkeit in einem Projekt ist, nicht das Abarbeiten einer “Shoppingliste” von Features, die vordefiniert wurden. Ein Beispiel: Sehr viele Features umzusetzen, um dann hoffentlich das Feature entwickelt zu haben, das User vor allem wollen, ist verschwenderisch. “Minimize output, maximize outcome” ist die Devise (Jeff Patton), “the art of maximizing the amount of work not done”, wie es das agile Manifest ausdrückt. Wenn man sich dabei vor Augen hält, dass meist nur gut 20% der Features einer Applikation genutzt werden, ist es sinnvoll, auf die Entdeckung der richtigen Features zu setzen.

Werden wir hier kurz philosophisch: Entdeckung hat etwas mit Überprüfung der Wirklichkeit zu tun, nicht mit Gedankenspielen (also umfangreicher Vorabspezifikation). Was die richtigen Features sind, können nur die entscheiden, die das Produkt nutzen. Wenn wir also nicht mit Immanuel Kant grundsätzlich von der Unerkennbarkeit der Wirklichkeit ausgehen, sondern versuchen wollen, ökonomisch funktionierende Projekterfolge zu erzielen, dann tun wir gut daran, so schnell und oft wie möglich unsere Annahmen zu testen  – denn das sind Features, bevor sie auf die Welt losgelassen werden: Annahmen.

Heißt Agile gar keine Planung mehr?!

“Plans are nothing; planning is everything.”
Dwight D. Eisenhower

Die Planung ändert sich also ganz grundsätzlich. Agile Planung hat v.a. das Ziel, sich laufend an Veränderungen anzupassen, nicht aber vorab möglichst viel festzulegen. Es mag zunächst unbefriedigend klingen, dass man als Kunde nicht vorab genau erfährt, was man genau bekommt, zu welchem Zeitpunkt es fertig ist und wie viel es kosten wird. Die ehrliche Meinung aus meiner Projekterfahrung dazu: Das wissen Sie mit klassischer Planung auch nicht.

Das heißt nicht, dass es in Agile keinerlei Planung gibt. Es erfolgt eine sehr detaillierte Planung: Besonders die Dinge werden genau spezifiziert, die man als nächstes umsetzen will. Erst in diesem “last responsible moment” muss man sich “just in time” entscheiden, was man in der nächsten Zeiteinheit von wenigen Wochen machen möchte und wie – Scrum Sprints dauern zum Beispiel zwischen 1 und 4 Wochen.

Danach testet man, ob man in die richtige Richtung geht: Man zeigt dem Kunden das Ergebnis. Der Kunde hat die Möglichkeit, mit seinen Stakeholdern, also auch Usern, Endkunden usw. zu testen, wie gut das Ergebnis taugt, also den Business Goals zuträglich ist. Wenn nötig ändert man das Vorgehen, den Ansatz, die Priorität von Features usw.

Dinge, die weit in der Zukunft liegen, werden dagegen nur sehr grob spezifiziert bzw. geplant. Deshalb spricht man von “rolling wave planning”. Die Planungsintensität über die Zeit aufgetragen sieht aus wie eine Welle.

Eine grobe Zusammenfassung könnte aussehen wie folgt: Agile Planung...

• ist leichtgewichtig
• findet über das gesamte Projekt hinweg statt
• beteiligt möglichst alle Stakeholder
• führt zu testbaren und zu testenden Teilergebnissen (Iterationen)
• setzt auf Selbstorganisation und Verantwortung der Ausführenden
• setzt auf transparente Interaktion
• definiert Milestones, lässt aber den Weg dorthin offen und lässt Änderungen zukünftiger Milestones zu

“I know you have narrow, clearly defined titles, roles, and responsibilities. Agile teams don’t care about any of that.”
Jonathan Rasmusson

In einem “klassischen” Projekt gibt es meist eine Vielzahl von Rollen, die fein säuberlich getrennt nebeneinander oder nacheinander arbeiten. In einem Scrum-Team zum Beispiel gibt es nur drei Rollen, nämlich den Product Owner, den ScrumMaster und das Entwicklungsteam. Der Product Owner (PO) ist für das Produkt, für die Produktvision, für die Maximierung des ROI und die Priorisierung der To-Dos zuständig. Er repräsentiert den Kunden, im Idealfall ist er der Kunde. Oft wird jedoch ein PO vom Dienstleister in Anspruch genommen, der dann als sog. Proxy-PO fungiert. Gerade ein Proxy-PO, der meist über weniger Empowerment, also Verfügungs- und Entscheidungsgewalt, verfügt, ist fundamental auf die ständige, interaktive Mitarbeit des Kunden angewiesen, um einen guten Job zu machen.

Der ScrumMaster (SM) ist für die Qualität und Verbesserung des Scrum-Prozesses, des Teamworks, der Entwicklungspraktiken zuständig. Der Kunde hat mit dem SM weniger zu tun als mit dem PO, jedoch steht der SM für alle Fragen und Probleme, die im Projekt entstehen, helfend zur Verfügung. Es ist sogar seine dezidierte Aufgabe, Probleme ans Tageslicht zu bringen und für eine Lösung zu sorgen. Die beiden Rollen, PO und SM, ergänzen sich somit.

Ein agiles Vorgehen lebt von Interaktion, häufigem, kurzfristigem Feedback, von Kommunikation und Transparenz. Ziel ist stets, in möglichst kurzer Zeit ein möglichst wertvolles Inkrement (Teilstück) des insgesamt Angestrebten zu erstellen, welches potentiell in die Produktionsumgebung auslieferbar sein muss. Lieber eine kleine Sache ganz fertig als drei große Sachen angefangen.

Die Pflichten des Kunden: Erfolg sichern!
Dies bringt für den Kunden eine Reihe von Pflichten mit. Sicher, der Kunde ist König, und will oder kann er diesen Pflichten nicht nachkommen, können ihn weder SM noch Proxy-PO dazu zwingen. Doch die Schlagkraft des Teams und Güte der Ergebnisse hängen essentiell davon ab, dass der Kunde die nötige Zeit hat, um die ständig nötige Kooperation mit dem Scrum-Team zu pflegen. Dadurch erhält er eine intensive ständige Teilhabe am Prozess, profitiert von den kurzen Feedback-Zyklen und kann jederzeit steuernd eingreifen.

Die “Pflichten” bzw. Aufgaben des Kunden umfassen dabei eine fortwährende Zusammenarbeit, also etwa bei den definierten Meetings wie Review und Story-Workshops Personen beizusteuern, die inhaltlich und entscheiderisch gestalten können. Ein machtloser Proxy-PO, der in der Kundendomäne nicht ausreichend „zuhause“ ist und keine Entscheidungsbefugnis hat, ist kein PO. Die Rolle wäre somit durch ein Pontius-Pilatus-Hin-und-Her ersetzt, was für den Scrum-Prozess extrem schädlich ist.

Seien Sie dabei kritisch. Eine Devise des agilen Vorgehens heißt: "Fail fast", also „scheitere schnell“. Denn das ist zielführender (und billiger!), als spät zu scheitern. Ein frühes Erkennen, dass etwas nicht in die richtige Richtung geht, ist viel wertvoller als eine "Weichspülergangart" in der Hoffnung "das wird schon noch werden". Ein hartes Beispiel hierfür: Der Berliner Flughafen. War es wirklich erst so kurze Zeit vor der geplanten Fertigstellung offensichtlich, dass es nichts werden kann? Natürlich nicht, das wäre ja absurd. Es gab, grob vereinfacht, vermutlich nur niemanden, der zum frühest möglichen Zeitpunkt mit der gebotenen Brutalität die Pauke schlug. Diese Art von zimperlich sein, Verantwortungsdiffusion oder Intransparenz nutzt letztlich niemandem.

Arbeiten Sie auch außerhalb der Meetings unbedingt eng mit dem Product Owner und dem Entwicklungsteam zusammen, um die richtige Priorisierung und Werthaltigkeit des Backlogs (Liste alles erfassten Aufgaben) zu sichern, und immer wieder auf den Prüfstand zu stellen: Sind wir auf dem richtigen Weg?

"Customer collaboration over contract negotiation" (Agiles Manifest)

Ohne in juristische Details gehen zu können, ein Wort zum Vertragswerk: Es ist möglich, ein agiles Projekt als Werkvertrag zu gestalten, es ist aber nicht besonders sinnvoll. Für einen Dienstleistungsvertrag, der dem agilen Vorgehen am besten entspricht, ist Vertrauen nötig. Dieses Vertrauen aufzubauen, sollte Gegenstand der ersten Iterationen sein. Sieht man nach einigen Wochen dann, dass Ergebnis, Zusammenarbeit oder sonstige Faktoren leider nicht passen, ist der Schaden geringer, als wenn man sich für lange Zeit und umfangreichen Scope an einen Dienstleister gebunden hätte. Ja, Verträge bringen rechtliche Absicherung. Erfolg bedeutet aber erfolgreiche Zusammenarbeit mit optimalen Ergebnissen – nicht aber vor Gericht Recht zu bekommen.

“It is not necessary to change. Survival is not mandatory.”
W. Edwards Deming

Agile Ansätze wie Scrum haben ein Ziel: Früher und öfter bessere Ergebnisse. Weil man davon ausgeht, dass schnelle Anpassungsfähigkeit und empirisches Vorgehen große Vorteile darstellen, vor allem in komplexen Problemlagen und schnellen, globalen, unberechenbaren Zeiten/Märkten wie heute. Wer mehrjährige “Dinosaurierprojekte” auf sich nimmt, wird eventuell von schnelleren (agileren) Konkurrenten rechts überholt. Wer mehrjährige Projekte auf sich nimmt, ohne früh und immer wieder zu prüfen, ob Stoßrichtung, Grundprämisse und Wertschöpfungsansatz noch stimmen, wird vielleicht feststellen, dass er mit viel Geld etwas geschafft hat, was sich leider zu spät als das Falsche herausstellt.

Man muss sich aber auf einen solchen agilen Ansatz wie Scrum einlassen, um die Benefits zu ernten. Als Kunde sollten Sie wissen, worauf Sie sich einlassen – damit sie sich einlassen! Ein agiler Ansatz ist kategorisch anders, selbst, wenn er in Teilen vielleicht gar nicht so erscheint. Er unterscheidet sich von sequentiellen, klassischen Ansätzen so kategorisch, wie sich komplizierte von komplexen Problemstellungen unterscheiden.

Agile bedeutet deshalb Änderung des Vorgehens, vermutlich sogar der Einstellungen. Agile im Kleinen, im Testprojekt, das geht. Ein bisschen Agile geht dagegen nicht. In eingespielten Strukturen und Prozessen eines Unternehmens mag das stellenweise schmerzhaft sein.

Darauf muss man als Kunde bzw. Auftraggeber vorbereitet sein. Doch wie heißt es bei Buddha? “Change is never painful. Only the resistance to change is painful.“

zur Ausgabe