Der Begriff hat eine erstaunliche Karriere erlebt. Ich erinnere mich gut an meine ersten Jahre als Softwareentwickler. Die Probleme mit traditionellen Entwicklungsmethoden und -prozessen waren in der Softwareindustrie allzu offensichtlich. Begeistert habe ich 2001 das Buch „Extreme Programming Explained: Embrace Change“ von Kent Beck bei einer Reise nach Kanada entdeckt. Damit war ein erfrischend neuer Blick verbunden. So richtig wusste man damals nicht, ob man als Softwareentwickler mehr Handwerker, Künstler, Ingenieur oder eine ganz eigene Spezie sein sollte. Extreme Programming (XP) schien eine mögliche Lösung, weil es die handwerklichen Notwendigkeiten mit einer intellektuellen Flexibilität zu verbinden suchte.

Kent Beck war auch einer der Protagonisten hinter dem Agilen Manifest. Schaut man sich die 'Prinzipien' an, dann erkennt man die Nöte und Probleme der Softwareindustrie gut darin wieder:

Wir erschließen bessere Wege, Software zu entwickeln,
indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,
schätzen wir die Werte auf der linken Seite höher ein.

Heutzutage ist Softwareentwicklung ohne eine mehr oder weniger umfängliche Überführung in den Arbeitsalltag kaum vorstellbar. Ist da, wo viel Licht ist, möglicherweise auch Schatten? Dazu sollte die Motivation und die Rezeption dieser agilen Vorgehensweise genauer betrachtet werden.

Agilität ist wiederholt als ein eigenes Prozess-Modell verstanden worden. Dem Wortlaut des Manifests nach steht aber ein Denken in Prozessen gar nicht im Vordergrund. Zur Jahrtausendwende war das quälende Problem der Softwareentwicklung, dass das Verhältnis von Auftraggebern und Auftragnehmern sehr viel schwieriger als bei traditionellen Gewerken erschien. Man schien aneinander vorbei zu reden und Erwartungen wurden enttäuscht. Dieses Problem stellt sich bei Techniken, die seit Jahrzehnten (oder gar Jahrhunderten) etabliert sind, so nicht. Der Versuch, bekanntes Vorgehen vom Maschinen- Hausbau beim Bestellen, Abnehmen und Inbetriebnehmen von Software wiederzuverwenden, führte zu Enttäuschungen und Frustration - ganz zu Schweigen von Regress bzw. Fehlinvestitionen. Hat man keinen unmittelbaren Auftraggeber wie bei einer Fachanwendung bzw. einer Individuallösung, dann gibt es eine vergleichbar problematische Beziehung zwischen dem Marketingbereich und der Entwicklungsabteilung.

Agilität scheint die Lösung für die wesentlichen Probleme zwischen Kunde/Auftraggeber und der Softwareindustrie zu sein. Primär:

• Funktion: Entwicklung eines gemeinsamen Verständnisses, einer gemeinsamen Sprache
• Funktion: Vermeidung von Enttäuschung, weil früh Feedback eingeholt wird
• Fokussierung der Entwickelnden auf die Kundenerwartung, keine selbstverliebten Technikspielereien