Architektur

Missverständnis 3: „Agilität macht uns 10 mal schneller!“

Zuvor wurde diese Blog-Artikel-Serie über typische Missverständnisse im Kontext Agilität und Software-Architektur bereits gestartet.

Missverständnis 3: „Agilität macht uns 10 mal schneller!“

Agilität ist immer in einem iterativen Prozess verankert. Der Zugewinn an Geschwindigkeit sollte hierbei jedoch nicht mit „Lines of code pro Sprint und Mitarbeiter“ oder „Anzahl realisierter Features pro Sprint und Mitarbeiter“ bemessen werden. Denn diese Art von „Geschwindigkeit“ wird bei einem agilen Projekt nicht primär gesteigert.  In einem agilen Projekt sollte stattdessen sehr viel Wert auf Maßnahmen zur Qualitätserhaltung (bspw. über Retros und Reviews) gelegt werden, was diese Art von „Geschwindigkeit“ auf den ersten Blick reduziert.

Die Art von Geschwindigkeit, die in einem agilen Projekt gesteigert wird, bezieht sich vielmehr darauf, dass tendenziell Projektziele in einem unscharfen und sich stetig verändernden Umfeld über agile Vorgehensweisen schneller erreicht werden können. Durch kurze Iterationen, regelmäßigen Abgleich mit der Kundenerwartung bzw. Kundenreaktion und integrierten Methoden zur stetigen projektinternen Verbesserung (z. B. Retrospektive), werden zu große Schritte in die falsche Richtung vermieden. Zudem werden nach agilen Prinzipien Features schrittweise ausgebaut und verfeinert oder erweitert. Nach jeder Iteration sollte eine intensive Auseinandersetzung mit den Stakeholdern (idealerweise inklusive Endkunden) stattfinden, um feststellen zu können, ob das Erreichte dem Gewünschten entspricht und ob die ursprünglichen Ziele noch gelten oder ob sich Details der Zielsetzung inzwischen verändert haben oder evtl. erst im Rahmen der Umsetzung bekannt geworden sind.

Der agile Weg zum Ziel

Man gelangt also mit agilen Methoden tendenziell schneller ans Ziel, wenn man das Ganze in einer Langfristperspektive betrachtet, weil weniger große Umwege gegangen werden müssen. Zudem stellt die Agilität so besser sicher, dass man an das „richtige“ Ziel gelangt, nämlich jenes, welches den Kunden wirklich zufrieden stellt.

Der agile Weg zum Ziel im Vergleich

Im Sinne einer Software- und Systemarchitektur haben wir zuvor schon beschrieben, warum ein Architekt in einem Softwareprojekt gewissermaßen der „Hüter der Langfrist- und Qualitätsperspektive“ ist. Wird nun ein zu starker Fokus auf die „Steigerung der Geschwindigkeit“ im zuvor beschriebenen falschen Sinn gelegt, dann ergeben sich viele Probleme im Rahmen der technischen Lösung. Um schnell das erwartete Feature liefern zu können, leidet die technische Qualität der Lösung. Zeitdruck ist der Faktor Nummer eins, der zum Aufbau von technischer Schuld führt. Qualitätserhaltende/-steigernde Maßnahmen wie die Durchführung von Code-Reviews oder Refactorings, das Implementieren automatisierter Tests oder das Durchführen von Retrospektiven werden besonders gerne aus „Zeitgründen“ gestrichen. Das Ergebnis ist insbesondere dann unbefriedigend, wenn einer der Hauptgründe für die Einführung des Projekts überhaupt die Ablösung technischer Schuld war, welche die Lieferfähigkeit neuer Features immer stark behindert hatte.

Fazit

Grundsätzlich gilt: Wer aus Zeitgründen „inspect and adapt“ nicht befolgt, der kann nicht aus Fehlern lernen. Das sollte jedoch jedem agilen Prozess zugrunde liegen und auch im Rahmen der agilen Architekturentwicklung, insbesondere bei der Gestaltung einer hochindividuellen Problemlösung, muss es genug Raum zum Lernen geben.

Zu Missverständnis Nr. 4: „Agilität ist doch nur was für Entwickler“.

Unsere Leistungen rund um IT-Architektur

Mehr erfahren