Momentan gibt es eine riesige Nachfrage nach E-Commerce Applikationen. Wir nehmen beispielweise pro Woche an zwei neuen Ausschreibungen teil. Dabei ist sich Jedermann bewusst, dass eine agile Projektorganisation gerade extrem wichtig ist und doch kämpfen viele Unternehmen (in Deutschland?) noch damit, sich wirklich auf agile Methoden einzulassen.

Projektmanagement im klassischen Sinne

Traditionelle Softwareentwicklungsprozesse waren oft Wasserfallprojekte. Innerhalb des Wasserfallmodells folgten die verschiedenen Phasen der Softwareprojekte strikt sequentieller aufeinander. Die verantwortlichen Personen starteten damit, eine Liste aller Anforderungen zu erstellen und diese in ein Dokument zu gießen, sodass solche Anforderungsprotokolle häufig einen Umfang von mehreren Hundert Seiten hatten. Diese waren notwendig, um das gewünschte Softwareprodukt exakt zu beschreiben, indem alles explizit dokumentiert wurde. Jede funktionale und nichtfunktionale Anforderung musste festgehalten werden. Tatsächlich war die Anforderungsphase der einzige Zeitpunkt während des gesamten Projekts, in welcher der Kunde sein eigenes Produkt beeinflussen konnte. In späteren Projektphasen kümmerte man sich dann um das Design, die Implementierung, das Testing und die Wartung. In diesen Phasen war alles, was entwickelt werden musste, in diesen Anforderungsprotokollen festgehalten.

Aber diese Art des Projektmanagement hat zwei entscheidende Schwachstellen:

1. Für komplexe Systeme ist es kaum möglich, alle Anforderungen im Voraus definieren zu können, denn es gibt viel zu viel Spekulations- und Interpretationsfreiraum. Und je nach den gemachten Erfahrungen haben Menschen ein unterschiedliches Verständnis für Prozesse und Terminologien.
2. Dieses Prozessmodell lässt keine Veränderungen zu. Das heißt, dass Anforderungsänderungen enorme Kosten in späteren Entwicklungsstadien des Produkts verursachen. Aber es ist geradezu unmöglich, alle möglichen Probleme und Schwierigkeiten in den frühen Projektstadien zu erkennen.

In einer schnelllebigen Umwelt, wie sie das Web darstellt, ist ein solcher Ansatz zum Scheitern verurteilt. E-Commerce Applikationen sind sehr komplexe Softwaresysteme und die Anforderungen ändern sich ständig. Das Anfertigen von Anforderungsdokumenten, die alle Möglichkeiten enthalten, dauert üblicherweise mehrere Monate. Und das Designen, Implementieren und Validieren der Funktionen nimmt noch mehr Zeit in Anspruch. Das heißt, im Augenblick, in dem man mit der Niederschrift der Anforderungen fertig ist, ist ein Teil der Inhalte schon wieder veraltet. Als müsste man alle zukünftigen Unternehmens- und Kundenbedürfnisse vorhersehen und diese Vorhersagen als Fakten behandeln. Diese Spekulationen sind als Projekt Scope definiert und werden als Grundlage zur Einschätzung der Entwicklungszeit- und Kosten hinzugezogen.

Die agile Alternative

Anstatt Mutmaßungen und Annahmen über zukünftige Anforderungen anzustellen, passen sich die agilen Methoden den verändernden Realitäten an. Statt großer sequentieller Projektphasen wird die Produktentwicklung in kleinere Phasen von 1-4 Wochen heruntergebrochen. In jeder Phase, den sogenannten „Sprints“, fokussiert sich das Entwicklerteam auf bestimmte Aspekte der Applikation. So werden Anforderungsmanagement, Implementierung und Testing wiederholbare Tasks in jeder Iteration. Statt großer Anforderungslisten gibt es eine kleine handliche Liste für jeden Sprint und das Teamziel lautet, jede Iteration mit einer neuen Version einer funktionierenden Software abzuschließen.

Die Vorteile für E-Commerce Projekte liegen auf der Hand. Das Entwicklerteam fokussiert sich auf das kontinuierliche Liefern von Mehrwert für den Kunden. Sobald die aktuell laufende Software ein Minimum Viable Product (MVP) darstellt, kann sie umgehend veröffentlicht werden. Das Problem des unmissverständlichen Anforderungsmanagements wird durch direkte Kommunikation ersetzt.

Und am aller wichtigsten: Agile Methoden begrüßen Veränderung. Kunden verspüren oftmals den Drang, auch während der Implementierungsphase die Anforderungen zu ändern. Das Ändern des Plans stellt kein Problem dar, sondern wird vom Prozessmodell explizit mit eingeplant.

Die Kostenschätzung

Kunden begrüßen diese Aspekte der agilen Entwicklung. Aber sie verlangen eine offene und vorangestellte Definition des Projektumfangs (der sogenannte „Scope“), der Projektdauer, der Timeline und der sich daraus ergebenden Kosten. Der Grund dafür ist der Wunsch nach Sicherheit in einer komplexen Situation, die man nicht gänzlich steuern kann. Traditionelle Prozessmodelle bieten diesbezüglich eine Antwort; agile Methoden dagegen nicht.

Aber diese Antworten erwecken einen falschen Eindruck von Sicherheit. Die interessanteste Frage bleibt dagegen immer noch: Was passiert, wenn der ursprüngliche Plan geändert werden muss? Das führt zu einer Diskussion darüber, ob diese Veränderungen ursprünglich als Teil des Projektes geplant waren. In solchen Situationen haben entweder die Kunden, die Agentur oder im Zweifelsfall beide die unerwarteten Kosten zu tragen. Im Idealfall verständigen sich beide Parteien bezüglich der Kostenübernahme, aber oft genug passiert dies eben auch nicht. Und das wiederum führt zu Unzufriedenheit und höhere Kosten für beide Seiten.

Die Alternative zur Kostensteigerung wäre das Festhalten am Ursprungsplan, was aber dazu führt, dass die Applikation beim Launch bereits veraltet sein wird. Eine Applikation zu entwickeln, die nicht den tatsächlichen und aktuellen Nutzerbedürfnissen entspricht – dann könnte man auch gleich sein Geld verbrennen. Dann ist es auch ganz gleich, ob die Kosten erwartet waren oder nicht. Insofern muss man sich oftmals im Nachhinein eingestehen, dass die Kosten als ursprüngliche Entscheidungsgrundlage keine akkurate Einschätzung des eigentlich umgesetzten Projekts darstellen.

In agilen Umgebungen können die Projekt-Stakeholder eine festen Zeit- und Budgetrahmen definieren. Der Projekt-Scope auf der anderen Seite kann dagegen nicht komplett vorhergesehen werden. Daraus ergibt sich immer noch eine gewisse Unsicherheit im Vorfeld des Projekts, mit dem viele traditionell eingestellte Kunden ihre Probleme haben. Wenn es aber richtig gemacht wird, fokussieren sich die Leute immer darauf, welche Erweiterungen im nächsten Schritt die höchste Priorität genießen. Damit wird immer der größtmögliche Business Value in der schnellstmöglichen Zeit generiert. Theoretisch sollte es zu diesem Zeitpunkt vom Projektteam keine werthaltigere Software geben. Insofern sollte eine agile Vorgehensweise immer die bestmögliche Kosten-Nutzen-Rechnung erzeugen.

Ich bin überzeugt, dass das eigentliche Problem auch gar nicht die Kosten sind. Es ist vielmehr das Fehlen von Vertrauen. Wie kann man sich sicher sein, dass der Service Provider nicht diesen „Freifahrtsschein“ ausnutzt. Es verlangt nach jeder Menge Kommunikation, einem Grundvertrauen im Voraus und die Hingabe, Ergebnisse zu kreieren, die das Vertrauen zurückzahlen. Solange alle Stakeholder in ihre gegenseitigen Fähigkeiten vertrauen, werden diese Methoden zu besseren Ergebnissen führen. Und dies benötigt kontinuierliche Bemühungen, auf technischer, projektorganisatorischer aber auch auf sozialer Ebene dafür zu sorgen, dass alle Projektbeteiligten Vertrauen in das Projektteam haben.

Agil gewinnt immer!

Die Agile Revolution hat definitiv den Mainstream der KMUs in Deutschland noch nicht erreicht. Wir werden regelmäßig von Kunden auf angeblich seriöse Studien angesprochen, die erklären, warum traditionelle Prozessmodelle effektiver als agile Methoden sind. In den meisten Fällen zeigen die angeführten Argumente aber ausschließlich eine engstirnige Abneigung gegen Veränderungen an sich.

Aus meiner Sicht ist eine agile Ausführung kein Nice-to-have mehr. Es ist vielmehr der einzige Weg, um komplexe Softwareprojekte in einer effizienten und fairen Art und Weise anzugehen. Es bedarf der Bereitschaft und der Fertigkeiten, die Veränderungen im Laufe des Projekts zu schätzen und durch viel Kommunikation zwischen allen beteiligen Parteien für einen kontinuierlichen Strom von Ergebnissen zu sorgen. Aber mit der nötigen Geduld werden die Entwicklerteams eine bessere Software in kürzerer Zeit realisieren können.

In der sich ständig ändernden E-Commerce World ist Agilität Trumpf. Agiles Vorgehen gewinnt immer. Und das ist nicht mal so gewagt, wie es zunächst klingt!

(Titelbild: Mark Herreid / Shutterstock)