Gutes muss nicht originell sein. Aber manches, was vielen einleuchtend erscheint, ist oft alles andere als selbstverständlich. Es gibt Menschen, die halten Grundlagen für banal, um sie dann doch zu missachten. Ich halte es dagegen für wichtig, auch solide Werte nicht als trivial abzuschieben, sondern diese auf einen Sockel zu stellen.

Aus Wikipedia: Agile Softwareentwicklung

  1. Individuen und Interaktionen gelten mehr als Prozesse und Tools. Zwar sind wohldefinierte Entwicklungsprozesse und hochentwickelte Entwicklungswerkzeuge wichtig, wesentlich wichtiger ist jedoch die Qualifikation der Mitarbeitenden und eine effiziente Kommunikation zwischen ihnen.
  2. Funktionierende Programme gelten mehr als ausführliche Dokumentation. Gut geschriebene Dokumentation kann zwar hilfreich sein, das eigentliche Ziel der Entwicklung ist jedoch die fertige Software. Außerdem ist eine intuitiv verständliche Software hilfreicher als umfangreiche Dokumentation, die sowieso niemand liest.
  3. Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen. Ein Vertrag ist normalerweise die Grundlage für die Zusammenarbeit. Was der Kunde aber wirklich will, kann nur in ständiger Kommunikation mit ihm ermittelt werden.
  4. Der Mut und die Offenheit für Änderungen steht über dem Befolgen eines festgelegten Plans. Im Verlauf eines Entwicklungsprojektes ändern sich viele Anforderungen und Randbedingungen ebenso wie das Verständnis des Problemfeldes. Das Team muss darauf schnell reagieren können.

Dass über diesen Prinzipien Agiles Manifesto steht heißt nun nicht, dass man diese getrost in eine Ecke schieben kann, die eben nicht der Praxis entspricht.

Vielmehr bin ich durch langjährige Berufserfahrung oft genug auf einen Mindset gestoßen, der nach Orientierung und dem Heil im Abarbeiten fester Vorgaben bestand. Menschen denken oft gerne in Ordnungen und starren Strukturen.

Ceteris Paribus - unter sonst konstanten Bedingungen - so ist die vereinfachende Modellannahme: Um Probleme lösen zu können, vereinfacht man die Problemstellung, in dem man auf möglichst eine einzige Variable fokussiert. Dieses Modell ist in einer sich stets verändernden Welt zuweilen recht erfolgreich. Wenn man vor allem genügend Mitstreiter, am Besten von der Unternehmenshierarchiespitze abwärts, auf ein derartiges Denken einschwören kann, erhält es normative Kraft.

Mutatis mutandis - alles fließt - ist das Gegenprinzip. Wir leben in einer dynamischen Welt und es ist eben nicht angemessen, diese einfrieren zu wollen. Lebensbejahung heißt auch ein Ja zu Veränderungen. Das erschwert sicherlich die Projektarbeit, denn ein Fortschritt kann nur erzielt werden, wenn auf einem Fundament aufgebaut wird.

Das Problem hier ist aber die Grundorientierung: Soll man die Struktur so eng konzipieren, dass jede Planabweichung einer kleinen Katastrophe gleich kommt? Um in Bildern zu sprechen:

  • Das High Tech - Automatikgetriebe wurde genial konzipiert und prazise gebaut: Es liefert effiziente Ergebnisse gemäß Spezifikation und einen enormen Wirkungsgrad. Was aber, wenn ein Sandkorn am falschen Platz ist? Was ist, wenn sich ein Defekt einstellt? Was ist, wenn der Flansch zur Antriebswelle des Motors nicht passt?
  • Ein Einfach-Getriebe geringerer Präzision mag ein geringeres Leistungsvermögen haben als das erstgenannte. Vielleicht ist es schwerer, ist lauter und hat einen geringeren Wirkungsgrad. Aber es ist unempfindlicher gegen Verunreinigungen und leichter reparierbar. Man spricht von Fehlertoleranz und angepasster Technologie.

Nun mag man festhalten: Unterschiedliche Anforderungen führen zu unterschiedlichen Spezifikationen. Beide Getriebevarianten haben ihre Berechtigung in unterschiedlichen Umfeldern und stellen somit keinen Widerspruch dar. Mit dieser vermeintlichen Synthese verfehlt man aber meine Intention.

Denn hier geht es nicht um Getriebe, sondern um abstrakte Vorgehensmodelle, und das Getriebe ist nur die Metapher. Das metaphorische High-Tech-Getriebe passt in eine ansonsten saubere Welt, die keinen Bedarf für Fehlertoleranz hat. Aber ist unsere Welt so gestrickt? Gibt es Situationen, in der sich ein ausgefeiltes Vorgehensmodell ohne Spiel und Freiheitsgrade die zutreffende Beschreibung ist? Ich meine nein!

Sicher ist es sinnvoll, möglichst präzise Bedarfsanalysen und ein Design zu machen, bevor man das Codieren beginnt. Reiner Pragmatismus ignoriert die Erfahrungen des Software Engineering und ist dazu verdammt, die gleichen Fehler zu wiederholen. Und auch das metaphorische Einfach-Getriebe erfordert solides Engineering und Handwerkskunst. Doch es gibt ein Zuviel an Methode, Design und Spezifikation. Und somit kommen wir zum agilen Kern: Wir benötigen lose gekoppelte Methoden und Verfahren, die die Realität nicht einfrieren wollen: Embrace the Change!

Denn der Erfolg von Software-Projekten ist alles andere als selbstverständlich. Bekannt wurde der Chaos-Report der Standish Group. gemäß der untersuchten Projekte sind:

  • 16,2% - Projekt erfolgreich abgeschlossen: Das Projekt wurde rechtzeitig, ohne Kostenüberschreitung und mit dem ursprünglich geforderten Funktionsumfang abgeschlossen.
  • 52,7% - Projekt teilweise erfolgreich: Das Projekt wurde abgeschlossen, es kam jedoch zu Kosten- und/oder Zeitüberschreitungen oder es wurde nicht der vollständige geplante Funktionsumfang erreicht.
  • 31,1% - Projekt nicht erfolgreich: Das Projekt wurde abgebrochen.

Andere Studien ähnlicher Intention weisen teilweise noch schlechtere Ergebnisse aus. Wikipedia weiter:

Die Studie untersucht Ursachen für Erfolg und Misserfolg und stellt eine Korrelation von Erfolgswahrscheinlichkeit und Projektgröße fest.

Die festgestellten Haupterfolgsfaktoren sind:

  • Einbindung der Endbenutzer
  • Unterstützung durch das obere Management
  • Klare Anforderungen

Die Hauptpunkte, die zum Scheitern der Projekte führen sind:

  • fehlende Zuarbeit durch Benutzer
  • unvollständige/unklare Anforderungen
  • häufige Anforderungsänderungen

Hier greift die Analyse etwas kurz. Sicher stimmen die Faktoren und können kaum kräftig genug notiert werden. Allerdings bleibt das Vorgehensmodell zu sehr außerhalb des Fokus. Denn wenn eine schwergewichtige Analyse auf abstraktem Niveau - oder auf einem virtuellem Detail-Niveau - End-User befragt, so werden diese oft hinsichtlich ihrer Antizipationsfähigkeit überfordert sein: Also der Fähigkeit, die Konsequenzen aus völlig anderen, noch nicht realisierten Gegebenheiten zu ermessen.

Jede Detail-Spezifikation im klassischen Wasserfall bleibt darum systematisch weit hinter dem erhofften Nutzen. Ein Einbezug von Iterationsschleifen ist darum eine nötige, aber nicht hinreichende Bedingung. Darum ist zwar sehr wohl an einer klaren Anforderung und einem intensiven Anforderungsmanagement zu arbeiten, aber nicht zwingend im Sinne einer ausgedehnten Up-front-Spezifikationsphase, sondern unter einem teambezogenen agilen Vorgehensmodell, dass den Anspruch, Vollständigkeit in einem Wurf zu erreichen, nicht anstrebt.