Das agile Projekt – was heißt das für Kunden?

In der Software- und Produktentwicklung sind sogenannte agile Ansätze heute beinah schon Standard. Sie alle haben einen gemeinsamen Nenner, eine gemeinsame Wurzel, und zwar sind sie mehr oder weniger Implementierungen des Agilen Manifests, das eine Gruppe von international anerkannten “Gurus” im Jahr 2001 verabschiedete.
Das „Heilsversprechen“, dass man mit Agile schneller und wirkungsvoller zum Ziel kommt, wird von nennenswerten Studien tendenziell bis eindeutig bestätigt, das zeigen z. B. Zahlen mehrerer Agile Benchmark Studien der QSMA. Darum soll es im Folgenden aber nicht gehen (auch wenn der Autor merklich ein Verfechter von Agile ist), sondern vielmehr darum, was denn die Entscheidung, ein Projekt mit einem agilen Ansatz zu verfolgen, vor allem für den Auftraggeber bedeutet.
Es ist nämlich beileibe nicht so, dass in einem “agilen Projekt” einfach alles so ist wie immer, sprich, wie in einem sequentiell phasisch verlaufenden Projekt, nur dass das Softwareentwicklungsteam ein wenig anders arbeitet, was uns als Auftraggeber ja evtl. nicht einmal interessiert.
Der folgende Artikel will einige grundsätzliche Unterschiede herausarbeiten, die sich im agilen Vorgehen für den Auftraggeber/Kunden ergeben, also allgemeine, vielleicht zunächst nur wenig spürbare Aspekte. Dabei ist es auch nicht sehr erheblich, ob man mit Scrum, Extreme Programming, Feature Driven Development, agilem Kanban oder einer der anderen Implementierungen von Agile arbeitet. Der Schwerpunkt des Artikels liegt aber auf Scrum.
Betrachten wir solche Unterschiede zu einem sequentiellen, “klassischen” Projekt in den Punkten
- Planung
- Rollen, Rechte, Pflichten
- Umsetzung
Im Ergebnis soll dafür eine Sensibilität entstehen – was Agile der Meinung des Autors zufolge ausmacht – die hilft zu entscheiden: Wollen wir uns mit Konsequenz auf einen agilen Ansatz einlassen? Denn natürlich genügt es nicht, das Schild über der Tür “Entwicklungsabteilung” auszutauschen gegen “Scrum-Team” und dem bisherigen PM neue Visitenkarten zu drucken “Product Owner”. Manche der Veränderungen sind augenscheinlich, manche, wie erwähnt, subtil. Manche sind “sozialer Natur”, manche sind rechtlich relevant. Und alle sind vorab zu klären und zu kommunizieren, damit alle auf demselben Stand und mit möglichst demselben Verständnis starten.
Wozu das alles? Wozu agil?
"The agile approach is not a set of rules; it’s a set of principles – a way of looking at the world." Allen Holub
Es ist, wie erwähnt, nicht Fokus dieses Artikels, die Vorzüge von agilen Ansätzen zu analysieren oder gar nachzuweisen. Mehr geht es darum, aufzuzeigen, wo diese Ansätze sich von klassischen unterscheiden mit Wirkung auf den Auftraggeber, ohne dass dies vielleicht gleich ins Auge fällt. Betrachten wir dennoch kurz, welches Ziel agile Ansätze grundsätzlich und ausdrücklich haben: Möglichst viel Wert in hoher Qualität in kurzer Zeit zu erarbeiten. Wir erarbeiten und erreichen so...
- eine optimale Anpassungsfähigkeit bei Änderungen (der Prioritäten, Märkte, Konkurrenzverhalten, Technologien etc.)
- fast umgehend verwertbare Ergebnisse (Iterationen)
- eine wertgetriebene ständige Analyse der Ergebnisse
Was ändert sich bezüglich Planung?
“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
Was ändert sich bezüglich Rollen, Rechte, Pflichten?
“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.
Was ändert sich bezüglich der Umsetzung?
“Treat people as adults. Ask the team.” Christoph Mathis
Im ersten Kapitel haben wir gesehen, dass sich das Requirements Engineering und die Projektplanung grundsätzlich wandeln. Im letzten Kapitel wurde gezeigt, wie sehr der Kunde in einem agilen Projekt gefordert ist, mitzuwirken.
Betrachten wir nun kurz die Aspekte, die sich in der Umsetzung ändern, ohne dass der Kunde dies direkt im Alltag sofort erfährt. Das ist wichtig, denn auf diese Aspekte sollten Sie achten, um zu entscheiden, ob ein Dienstleister es ernst meint mit der Agilität und nicht nur das Buzzword “Agile” oder “Scrum” nutzt, um innovativ und schlagkräftig zu wirken. Es geht dabei um die beiden Aspekte Qualität der Softwareentwicklung und Qualität des Prozesses allgemein.
Ohne automatisierte Tests keine Agilität
Agile Teams setzen sehr stark auf automatisierte Tests und auf Continuous Deployment oder sogar Continuous Delivery. Das heißt: Software soll beinah ständig in möglichst 100% getesteter Qualität ausgeliefert werden. Das hindert Sie, den Kunden, natürlich nicht daran, ein Release in die Produktivumgebung nur alle zwei Monate zu machen.
Wenn man als Entwicklungsteam bereit ist (und bereit sein muss), immer wieder sogar auch grundsätzliche Änderungen am System vorzunehmen, braucht man automatisierte Tests, die das System möglichst vollständig abdecken. Software ist komplex, und jeder hat es schon erlebt: Wenn man an der einen Stelle etwas ändert, geht an der anderen Stelle etwas kaputt. Da der manuelle Testaufwand mit fortschreitendem Projektverlauf immer weniger bewältigbar ist, müsste man ohne automatisierte Tests in der ständigen Angst leben, etwas zu zerstören, was schon einmal funktioniert hat. Erst Testautomatisierung gibt einem Team die Zuversicht und Basis, sich schnell und wirkungsvoll auf Änderungen einzustellen.
Die Qualität des Prozesses: Betreuung statt Zufall
Scrum-Teams haben einen ScrumMaster, das schreibt das Framework vor. Extreme-Programming-Teams haben einen XP-Coach, ebenfalls eine explizit definierte Rolle. Wie sagt Ken Schwaber, einer der Erfinder von Scrum, so schön und lapidar: „Scrum is easy to understand, but difficult to master“.
Teams sind komplexe Systeme, wie alle sozialen Systeme, und Softwareprojekte sind meist komplexe Projekte, also kann man sich getrost trauen, zu behaupten: Es ist sinnvoll, den Prozess, mit dem das Team versucht, seine Ziele zu erreichen, zu betreuen. Dabei geht es um Betreuung der technischen Herausforderungen und Betreuung der Zusammenarbeit im Team, also auch um die Betreuung des Teams als soziales System. Und natürlich gilt es zudem, darauf zu achten, dass das Team das Verständnis und die Qualität des gewählten Prozesses (Scrum, XP, Kanban usw.) ständig verbessert.
Das alles will man nicht dem Zufall überlassen. Deswegen gibt es als feste Rolle im Team den ScrumMaster (SM) bei Scrum, den Coach bei XP usw. Sie haben als Kunde das Recht, diese Personen zu fordern. Auch den Kunden im Prozess zu begleiten, ist Aufgabe des ScrumMaster. Deshalb: Sie haben sogar die Pflicht, den SM zu fordern. Achten Sie darauf, dass diese Rolle im Team adäquat besetzt ist. Vor allem, wenn wir nicht von einem eingespielten Team mit jahrelanger Scrum-Erfahrung sprechen, ist die Qualität des ScrumMasters entscheidend für die Qualität dessen, was das Team leistet.
Ein Fazit: Was bedeutet Agile für den Kunden?
“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.“

Autor
Sacha Storz
Sacha Storz ist zertifizierter Scrum Product Owner und ScrumMaster (CSPO, CSP, PSM I) und enthusiastischer Kanban Practitioner. Als Standortleitung der Münchner Techdivision-Niederlassung leitet er große Magento- und TYPO3-Projekte und verfügt dabei über mehrjährige Scrum-Erfahrung aus der täglichen Praxis. Sacha Storz ist zudem als Dozent und Autor für diverse Veranstaltungen und Medien im Themenbereich „agile Managementmethoden“ tätig.