Klingt einfach, ist es auch. Jedoch gibt es in der Entwicklung einige Vorgehensmodelle, die eben diese Reaktion auf Veränderungen nicht ermöglichen. Viel zu häufig führt genau das in der Praxis zu unzufriedenen Kunden und frustrierten Entwicklern. Aus diesem Grund arbeiten wir agil. Anscheinend mit Erfolg, denn unsere Kunden adaptieren diese Vorgehensweise bereits auf eigene Projekte. Grund genug für ein Gespräch mit Daniel, der mir von seinen Erfahrungen mit verschiedenen Modellen erzählte und ein Befürworter der agilen Herangehensweise an ein Projekt ist, welche er anhand eines Projekts für einen führenden Markenhersteller erklärt.
„Agiles arbeiten stellt einen extremen Mehrwert sowohl für den Kunden als auch den Alltag des Entwicklers dar, denn es führt definitiv zu Ruhe, Struktur und Organisation. Ziel ist es, die Entwicklung flexibler zu gestalten.“
In weniger erfolgreichen Projekten läuft es häufig wie folgt ab:
Am Anfang steht die Anforderungsanalyse – was braucht eigentlich der Kunde? Gemeinsam wird ein Anforderungskatalog erstellt, der jedoch oftmals eher vom Entwickler getrieben wird. Auf dieser Basis wird ein Angebot mit Fixpreis erstellt, welches der Kunde abnimmt. So weit so gut – nur leider ergeben sich die wichtigsten Fragen und Anforderungen meist erst während der Entwicklung. So merkt ein Kunde erst nach einem hohen zeitlichen und finanziellen Invest, dass auf dem Papier zwar alles super aussah, die Praxis jedoch nicht zu dem benötigten Ergebnis führt. Da liegt das Problem. Je enger man sich an die Planung hält, umso wahrscheinlicher ist es, zu erreichen, was man geplant hat. Jedoch ist das leider oft nicht das, was man eigentlich braucht.
In klassischen Entwicklungsmodellen fällt das leider erst spät im Prozess auf. Schaut man sich das Wasserfallmodell an, sieht man das sehr gut. Die einzelnen Projektphase bauen aufeinander auf und die Zwischenergebnisse sind Grundlage für die nächste Phase. Die anfängliche Definition aller Ergebnisse ist jedoch problematisch und nicht realistisch. Fehler werden häufig zu spät erkannt, sind schwer steuerbar und müssen teuer und vor allem zeitintensiv behoben werden. Auch schwierig gestaltet sich der geringe Einbezug des Auftraggebers. Nach der Anfangsphase ist keine weitere Kommunikation vorgesehen, nachfolgende Änderungswünsche sind Neuaufträge.
Daraus resultiert Unzufriedenheit beim Kunden, weil seine Investitionen in Zeit und Geld kein zufriedenstellendes Ergebnis erzielt haben. Dies wiederum führt zu Unzufriedenheit bei den Entwicklern, weil Mehraufwand entsteht und zwangsläufig wird häufig weniger qualitativ gearbeitet.
Die Interaktion mit dem Kunden steht über einem verbindlichen Maßnahmenkatalog
Aus diesem Grund setzen unsere Entwickler bereits zu Beginn anders an, wie Daniel ausführt. Am Anfang eines Projekts findet auch hier ein Gespräch mit dem Kunden statt. Anstelle eines Pflichtenhefts werden nur grob die Features besprochen, die umgesetzt werden sollen.
„Es handelt sich tatsächlich um eine sehr grobe Einschätzung mit einer Abstimmung auf den geschätzt benötigten Zeitrahmen. Dieser wird auf einzelne Sprints runtergebrochen, die beispielsweise in diesem Projekt zwei Wochen dauerten und sich jeweils auf eine Teilaufgabe, ein Feature sozusagen, beziehen.“
Während eines Sprints konzentrieren Entwickler und Kunde sich komplett auf die Feinkonzeption dieses möglichst atomaren Features. Ebenfalls in diesen zwei Wochen finden die Entwicklung, das Testing und der Go Live statt.
„In einem Sprint von zwei Wochen war es in diesem Projekt immer möglich, ein Feature komplett und gründlich abzuschließen. Erst danach wurde das nächste in Angriff genommen.“
Damit das so gelingt müssen Kunde und Entwickler gemeinsam die Features so eng schnüren, dass die vollständige Umsetzung in einem Sprint realistisch ist. Ein so enger Zeitraum muss bestmöglich genutzt werden. Deshalb startet jeder Sprint mit einem Konzeptions-Call. Dort wird gemeinsam ein fester Fragebogen erstellt und verschiedene Punkte für die jeweiligen Sprints definiert. Sowohl auf Kunden- als auch auf Entwicklerseite wird der Verantwortliche für ein Feature bestimmt, denn das Projekt läuft nur durch das gegenseitige Feedback, man sieht gemeinsam was der Kunde wirklich benötigt. Das ist das Paradigma. Beispielsweise werden folgende Fragen für jeden Sprint geklärt:
- Wer testet das Feature?
- Wie steht es in Abhängigkeit zu anderen Aufgaben?
- Welche Risiken gibt es?
- Werden Schnittstellen zu anderen Systemen benötigt?
- Wenn ja, welche?
Es ist sehr hilfreich, alles auf möglichst kleinschrittige Teilaufgaben runter zu brechen und, falls nötig, innerhalb eines Sprints konkretere Konzeptionen separat zu terminieren, um z.B. ein technisches oder visuelles Konzept expliziter zu erarbeiten. Eine intensive Vorbereitung und möglichst effiziente Umsetzung in jeder Phase sind unumgänglich.
Im Optimalfall wird gemeinsam ein Budget für die jeweiligen Sprints abgesprochen und ungefähr besprochen, wie die einzelnen Features am Ende aussehen sollen. Allerdings gibt es keine genaue Zeitschätzung und Budgetierung und es wird klar kommuniziert, dass es vielleicht nicht möglich ist alle Features umzusetzen. Dafür ist es jedoch möglich, direkt auf alle Probleme oder Änderungen innerhalb eines Sprints zu reagieren und höchste Transparenz zu gewährleisten. Die stetige Kommunikation mit dem Auftraggeber ist essenziell.
In diesem Projekt konnte der Plan letztlich genauso umgesetzt werden, wie ursprünglich von Entwickler und Kunde gewünscht. Mehr als das: Trotz unvorhergesehener Probleme und Verzögerungen durch technische, organisatorische oder kommunikative Herausforderungen konnten wir gemeinsam reagieren und dennoch die harte Deadline halten. Dies war nur möglich, weil die Risiken der Sprints spezifisch eingeplant wurden und daher vermieden oder frühzeitig behoben werden konnten.
Der Kunde ist mit dem Ergebnis mehr als zufrieden, weil er pünktlich bekommen hat, was er sich gewünscht hat, obwohl sich seine Anforderungen zwischendurch änderten.
Auch Daniel war zufrieden, weil durch strukturiertes Arbeiten eine hohe Planbarkeit gegeben war, an dessen Ende eine Software stand, die sich sehen lassen konnte. Außerdem: Ist der Kunde glücklich, sind wir glücklich!
Ist es möglich in jedem Projekt agil zu arbeiten?
„Jein, überall wo ein Projekt neu- oder weiterentwickelt werden soll und weitere Features umgesetzt werden sollen. Im Grunde geht das in jedem Projekt, man muss nur die individuelle Situation betrachten und schauen, was man da anwenden kann.“
Die agile Arbeitsweise lässt ihn bewusster arbeiten, wie er gerade im Vergleich zu anderen Entwicklungsmodellen feststellen konnte. In der ersten Projektphase hat er noch einen anderen, klassischeren Ansatz gewählt und festgestellt, dass ihm die Flexibilität fehlte, auf Probleme zu reagieren. Diese Schwierigkeiten führten in der zweiten Phase dann zu dem agilen Ansatz.
Sein Fazit:
„Anfangs einen Plan zu haben ist sehr wichtig. Wichtiger ist es jedoch, sich am Anfang jeden Sprints Zeit zu nehmen den Plan zu hinterfragen, um jederzeit die Möglichkeit zu haben, auf jede Veränderung zu reagieren.“
Dieses Interview führte Dalia (Online Marketing Managerin) mit Daniel (Software-Developer) aus dem #teamWABSOLUTE®.
