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
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:
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:
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:
Die Hauptpunkte, die zum Scheitern der Projekte führen sind:
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.