Rechnet sich der Einsatz von agilen Methoden?

Weniger Fehl- und Blindleistung

Studien gehen davon aus, dass fast zwei Drittel der Funktionen in einer Anwendung selten oder überhaupt nicht genutzt werden [4]. Im Umkehrschluss bedeutet das: Der Geschäftswert der Anwendung steckt hauptsächlich im verbleibenden Drittel. Die Problematik in Softwareprojekten ist, schon zu Beginn eines Projekts genau das Drittel zu identifizieren, das den größten Geschäftswert liefert. Frau Schneider und ihr Fachbereich hatten beispielsweise nur eine sehr vage Vorstellung davon, wie ihre Ideen in konkrete Funktionen umgesetzt werden sollen. Diese vage Vermutung über die benötigte Funktionalität konkretisiert sich aber, sobald man ein System benutzt hat [5]. In unserer fiktiven Geschichte war es wichtig, die Anwendung auf dem iPad schon sehr früh auszuprobieren, um ein Gefühl für die Bedienung zu bekommen.

Selbst unter der idealisierten Annahme man kenne zu Projektbeginn schon alle Anforderungen im Detail und weiß um deren Geschäftswert, bleibt das Risiko, dass sich diese Anforderungen im Projektverlauf ändern, weil sich die Rahmenbedingungen geändert haben. Beispielsweise durch eine gesetzliche Änderung wie der Einführung der EU-Vermittlerrichtlinie.

Bei agilen Methoden hat man nach jeder Iteration die Möglichkeit, den aktuellen Stand zu kontrollieren und ggf. nachzusteuern.

Abb. 2 : Iteratives herantasten an die tatsächlich benötigte Funktionalität

Durch das kontinuierliche Feedback der Kunden und Benutzer zu den bereits fertiggestellten Releases, nähert man sich schrittweise dem wertschöpfenden Anforderungsdrittel im Projektverlauf. Zudem werden die tatsächlichen Anforderungen des Kunden durch die intensive Kommunikation besser verstanden, was in der Tendenz zu günstigeren Lösungen des eigentlichen Problems führt.

Risikomanagement von komplexen Situationen

Wie Friedrichsen in seinem Artikel „Agil oder doch lieber ingenieursmäßig?“ [6] dargelegt hat, ist die Softwareentwicklung eine komplexe Aufgabenstellung, die sich durch die hohe Dynamik der Randbedingungen (Anforderungen, Technologien, Menschen) auszeichnet. Um einen komplexen Prozess steuern zu können, bedarf es eines empirischen Vorgehens. Eine Analogie zur Verdeutlichung: Auch Klimaanlage und Heizung können nicht für Stunden oder Tage im Voraus programmiert werden um eine konstante Raumtemperatur zu erreichen. Die aktuelle Temperatur muss ständig gemessen werden, um dann die Regler nachsteuern zu können. Erst dadurch können Änderungen der Randbedingung wie Sonneneinstrahlung, Anzahl und Aktivität der im Raum befindlichen Personen ausgeglichen werden. Analog verhält es sich mit der Softwareentwicklung: Erst mit einem Prozess, der viele Messpunkte und Möglichkeiten zur Nachsteuerung bietet, kann man in komplexen Situationen das Risiko in den Griff bekommen. Gemessen wird z. B. in Scrum auf vielen Ebenen: Täglich beim Daily Scrum, um zu prüfen, ob das Sprint Commitment noch gehalten werden kann. Bei der Sprint Review, um zu prüfen, wie viel Fortschritt innerhalb des Sprints gemacht wurde, und welche Auswirkungen das auf das Release hat.

Das größte Risiko, das man dann eingeht, ist eine Iteration, die komplett am Geschäftsnutzen vorbeigeht: Man hat also keinerlei Kundennutzen aus der Arbeit der Iteration generieren können. Der iterative Ansatz deckelt das Risiko aber auch auf eine Iterationslänge. Im Gegensatz zu schwergewichtigen Prozessen, bei denen sehr häufig erst gegen Projektende gemerkt wird, ob der „grüne“ Status eher auf Hoffnung oder lauffähiger Software basiert, die den Kundenanforderungen entspricht. Der Business Case von Agilität kann im Extremfall sogar darin liegen, das Projekt zu beenden – der finanzielle Schaden kann durch die frühzeitige Validierung von Risiken reduziert werden.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.