Vieles an der heutigen Agilität  ist nicht mehr so, wie sich die Gründer das gedacht haben. Das heißt aber nicht, dass man sie komplett aufgeben sollte! 

Von Al Tenhundfeld, veröffentlicht am 31. August 2021, aktualisiert am 8.4.2022 

Dieser Text ist eine Übersetzung. Das Original des Softwareentwicklers Al Tenhundfeld ist hier zu finden. 

Das  Agile Manifest hat 2021 20-jähriges Jubiläum gefeiert - und es gab zwei offensichtliche Fakten:

• Das Label "Agile" hat sich durchgesetzt; niemand möchte als "nicht agil" bezeichnet werden. 
• Und: Agile Methoden, wie sie heute praktiziert werden, bleiben weit hinter den revolutionären Ideen ihrer Begründer zurück. 

Wie sind wir an diesen Punkt gekommen? Jeder sagt, dass er oder sie agil arbeitet - und doch ist fast niemand tatsächlich agil. 

Es war einmal vor langer Zeit ... 

Im Februar 2001 traf sich eine Gruppe von 17 Softwareexperten in der Lodge des Snowbird-Ski-Resorts in der Wasatch-Bergkette in Utah. Sie diskutierten und debattierten einige Tage lang und schrieben gemeinsam das Manifest für Agile Softwareentwicklung. 

Der erste Punkt, der dabei hervorzuheben ist: Es handelte sich um Menschen aus der Praxis. Keine Projektmanager, CTOs oder Vizepräsidenten, sondern Entwickler, Programmierer, Wissenschaftler und Ingenieure. Sie haben Code geschrieben (*) und mit allen Beteiligten an der Lösung von Problemen gearbeitet. Das ist wichtig zu wissen. 

(*) Ich kenne nicht die persönliche Geschichte eines jeden einzelnen Unterzeichners; aber von denen, die ich kenne, haben alle zu diesem Zeitpunkt entweder aktiv Code geschrieben oder sie haben es lange getan. 

Der andere wichtige Punkt ist, dass das Agile Manifest nicht in einem Vakuum entstanden ist. Viele dieser Leute hatten bereits eine Methodik, die sie entwickelt hatten und/oder propagierten. Ich bin wegen des Zeitpunkts nicht hundertprozentig sicher, glaube aber, dass alle Methoden bereits vor "Agile" existierten: Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming. Ich weiß, dass Ken Schwaber und Jeff Sutherland 1995 öffentlich über Scrum gesprochen haben. Und nach meiner Erinnerung begannen Kent Beck und Ron Jeffries 1996 damit, Extreme Programming (XP) bekanntzumachen. 

Alle Mitglieder dieser Gruppe verfügten über große Erfahrung in der Softwareentwicklung und suchten nach Alternativen zu den dokumentationsbasierten, schwerfälligen Softwareentwicklungsprozessen, die damals vorherrschten. Den Kern des Manifests bildeten vier Aussagen über Werte: 

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 stehen über Prozessen und Werkzeugen. 
Funktionierende Software steht über einer umfassenden Dokumentation. 
Zusammenarbeit mit den Kunden steht über Vertragsverhandlungen. 
Reaktion auf Veränderung steht über dem 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. 

Eine neue Hoffnung

Vom Jahr 2021 aus gesehen war es leicht, viel in der modernen Softwareentwicklungspraxis für selbstverständlich zu halten. 2001 waren diese Ideen jedoch sehr radikal. 

Wie, Sie möchten mit der Entwicklung der Software beginnen, bevor alle Anforderungen gesammelt und alle einzelnen Funktionen bestimmt wurden? Das ist doch verrückt! 

Ein Punkt, der oft vergessen wird, ist, dass Agilität in ihren Anfängen offen und sehr deutlich gegen das Management gerichtet war. Ken Schwaber zum Beispiel hat sein Ziel, alle Projektmanager loszuwerden, klar formuliert - nicht nur, um sie aus seinen Projekten zu bekommen, sondern um den Berufsstand komplett aus unserer Branche zu verbannen. 

Agilität und das PMI (Project Management Institute)

"Wir haben festgestellt, dass die Rolle des Projektleiters bei komplexer, kreativer Arbeit kontraproduktiv ist. Die Denkweise eines Projektleiters, repräsentiert durch den Projektplan, schränkt die Kreativität und Intelligenz aller anderen Projektbeteiligten auf die des Plans ein, anstatt die Intelligenz aller zur bestmöglichen Lösung der Probleme zu nutzen." 

(Ken Schwaber, Unterzeichner des Manifests und Scrum-Mitbegründer) 

Scrum Master hatten damals so gut wie keine Befugnisse und keine Stimmrechte bei Problemen. Sie waren dienende Anführer, die das Team abschirmten und Blockaden aus dem Weg räumten, aber das Team nicht leiteten. Bei XP war es ähnlich. Wenn ich mich recht erinnere, gab es bei XP ursprünglich Tracker und Coaches, die eine ähnliche, unterstützende Aufgabe hatten. 

Alistair Cockburn, Unterzeichner des Manifests sowie Erfinder der Crystal-Methode und der hexagonalen Architektur, hat kürzlich einen wunderbaren, aufschlussreichen Beitrag zu diesem Thema verfasst, in dem er unter anderem diese Idee (sinngemäß) darlegt: 

"Scrum hat in feindlichem Gebiet eigentlich einen guten Deal abgeschlossen: 

• Das Management hatte zwölfmal im Jahr die Möglichkeit, nach jedem Sprint die Richtung zu ändern. 

• Die Teams hatten einen ganzen Monat lang Zeit, in Ruhe und ohne Unterbrechungen oder Richtungswechsel zu arbeiten und nachzudenken. 
• Die Teams durften festlegen, was sie im Laufe des Monats tun würden (und was nicht), ohne dass das Management eingriff. 

Keine Führungskraft hat jemals ein besseres Angebot erhalten. 

Kein Entwicklerteam hat je ein besseres Angebot erhalten." 

Ich bin zertifizierter Scrum Master, arbeite seit über 15 Jahren in agilen Teams und habe viele der gängigen Bücher zu diesem Thema gelesen. Doch niemand hat die Idee so deutlich und prägnant formuliert (noch mal Cockburn): 

"Scrum wurde erfunden, um in feindlichen Umgebungen zu funktionieren. Es ist ein Vertrag zwischen den drängenden Managern und den Entwicklern, die Zeit zum Nachdenken und Entdecken brauchen." 

Das Imperium schlägt zurück

In gewisser Weise war das Konzept der Agilität eine Graswurzel-Arbeiterbewegung. Sie begann mit den Praktikern vor Ort und wurde nach oben ins Management getragen. Wie konnte das überhaupt gelingen? 

Zum Teil, weil die Zahl der Entwickler und ihr Wert für die Unternehmen stiegen und sie an Einfluss gewannen. Wichtiger noch war aber meiner Meinung nach, dass die traditionelle Wasserfallmethode einfach nicht mehr funktionierte. Software wurde immer komplizierter, das Arbeitstempo immer höher und die Benutzer wurden immer anspruchsvoller, so dass es unmöglich wurde, alles im Voraus zu planen. Die Umstellung auf eine iterative Entwicklung war logisch, wenn auch ein bisschen beängstigend für die Manager, die es gewohnt waren, alles zu planen. 

Ich erinnere mich an Besprechungen Mitte der 2000er Jahre, bei denen man merkte, dass das Management nicht richtig überzeugt war, es aber auch keine anderen Ideen mehr hatte. 

Was soll's - probieren wir diese verrückte Idee aus, von der die Entwickler ständig reden. Wir halten schon jetzt die Fristen nicht ein. Schlimmer kann es eigentlich nicht werden. 

Und zu ihrer Überraschung funktionierte es irgendwie, nicht sofort, aber etappenweise. Die Teams kämpften eine Weile und kamen dann langsam in Fahrt. Sie entdeckten, welche Muster für das jeweilige Team funktionierten und gerieten richtig in Schwung. Nach einigen Sprints begann man zu erkennen, wie gut das mit der Priorisierung funktionierender Software, der Zusammenarbeit und der Zeit für Überprüfung und Anpassungen klappte. 

Innerhalb von nur fünf Jahren wurde Agile von einer Methode, von der man zwar gehört hatte, die aber eher nicht verwendet wurde, zu einer, die jeder nutzte. 2005 wechselte ich den Job und weiß noch, dass mein Wissen über Agile und TDD damals ein Alleinstellungsmerkmal war. 2010 wurde dann schon vorausgesetzt, dass moderne Softwareteams in irgendeiner Form agil arbeiteten. Zumindest galt das für meine Job-Blase in der Beratungswelt; große Unternehmen bewegen sich dagegen immer langsamer. 

🎉🎉🎉 Wir haben es geschafft! 
Wir haben gewonnen! 
Herzlichen Glückwunsch an alle! 🎉🎉🎉 

Das ist das Ende der Geschichte. Sie können jetzt den Browser-Tab schließen.🥳 

"Gewinnen war leicht, junger Mann. Regieren ist schwieriger." 
(George Washington in dem Musical Hamilton) 

Wie bei vielen Revolutionen ging es auch mit der Agilität leider nicht so weiter, wie die Gründer sich das vorgestellt hatten. 

• Es hat sich gezeigt, dass das Konzept, Menschen und Interaktionen in den Vordergrund zu stellen, schwierig zu verkaufen ist. Prozesse und Tools lassen sich viel einfacher verkaufen. 
• Es hat sich gezeigt, dass funktionierende Software schwieriger zu produzieren ist als unrealistische Pläne und Unmengen an Dokumentation. 
• Es hat sich gezeigt, dass die Zusammenarbeit mit Kunden Vertrauen und Sensibilität erfordert, was in einem geschäftlichen Umfeld nicht immer gegeben ist. 

• Es hat sich gezeigt, dass die Reaktion auf Veränderungen oft davon bestimmt wird, dass Führungskräfte das Gefühl haben möchten, die Kontrolle zu haben. Und dass sie immer noch das (legitime) Bedürfnis haben, langfristige Pläne für ihr Unternehmen zu machen. 

 Es hat sich gezeigt, dass Agilität, wenn sie schlecht umgesetzt wird, sich oft wie Chaos anfühlt. 

Das heißt nicht, dass die vier Werte falsch sind. Es bedeutet nur, dass es Kraft kostet, alles richtig zu machen, und dass es den Mut braucht zu akzeptieren, dass Software eben manchmal chaotisch und kompliziert ist. Es ist wichtig, zu verstehen und daran zu glauben, dass ständiges Lernen, Anpassen, Verbessern und Ausliefern schließlich dazu führen wird, dass alles viel besser läuft, als es mit der Wasserfallmethode je möglich wäre. 

"Die agile Bewegung ist nicht gegen Methodologie, viele von uns wollen dem Wort Methodologie sogar wieder Glaubwürdigkeit verleihen. Wir wollen ein Gleichgewicht herstellen. Wir befürworten Modellierung, aber nicht, um ein Diagramm in einem verstaubten Firmenarchiv abzulegen. Wir begrüßen Dokumentation, nicht jedoch Hunderte Seiten nie gepflegter und selten genutzter Wälzer. Wir planen, erkennen aber die Grenzen der Planung in einem turbulenten Umfeld. All jene, die Befürworter von XP, Scrum oder einer anderen agilen Methodik als 'Hacker' bezeichnen, kennen weder die Methodik noch die ursprüngliche Definition des Begriffs 'Hacker'." 
(Jim Highsmith: Geschichte des Agilen Manifests) 

Das sind wichtige Punkte. Wir müssen immer noch planen, dokumentieren - und bei der Agilität konsequent sein. Es geht um Ausgewogenheit. Wenn Ihr Unternehmen jedoch mit einer agilen Transformation kämpft und im Chaos versinkt, werden Sie sofort Ja sagen, wenn Ihnen jemand ein Rettungsboot in Form von Zertifizierungen, Prozessen und Tools anbietet. Führungskräfte verstehen Prozesse und Tools viel besser als sich selbst organisierende Teams. 

Die Rückkehr der  Rogue One?

An dieser Stelle bricht meine Trilogie-Struktur in sich zusammen, denn leider sehe ich nicht, dass die tapferen Rebellen hier zurückkommen werden, zumindest nicht unter dem Label "Agile". 

Die Branche ist mittlerweile überschwemmt worden von Tool-Anbietern, Prozessberatern und Experten, die Versprechungen machen, die niemals eingehalten werden können. So sind wir bei SAFe und Scaled Scrum und all den anderen Agile-Varianten für Unternehmen gelandet. 

Diese Frameworks wurden nicht in böser Absicht entwickelt und im richtigen Kontext haben sie wahrscheinlich sogar einen gewissen Wert. Aber ich würde sie nicht als "agil" bezeichnen. Der Versuch, eine Methodik zu skalieren, die sich auf Einzelpersonen und Interaktionen konzentriert, führt unweigerlich zu Problemen - und untergräbt den ursprünglichen Wert der Methodik. 

Also: Schluss mit Agile?

So kommen wir also zu diesem berühmten Beitrag von Ron Jeffries, dem Unterzeichner des Manifests und Miterfinder von XP, aus dem Jahr 2018. 

Entwickler sollten Agile aufgeben

"Wenn 'agile' Ideen schlecht umgesetzt werden, führen sie oft zu mehr Konflikten mit den Entwicklern, weniger Zeit für die Arbeit, höherem Druck und der Forderung, 'schneller' zu arbeiten. Das ist schlecht für die Entwickler und letztlich auch für das Unternehmen, denn eine schlechte Umsetzung von 'Agile' führt in den meisten Fällen zu weitaus mehr Fehlern und einem viel langsameren Fortschritt, als man erreichen könnte. Oft verlassen gute Entwickler solche Organisationen, was das Unternehmen weniger effektiv macht, als es vor der Einführung von 'Agile' war." 

Und so kommen wir auch zu dem berühmten Beitrag von Dave Thomas, Unterzeichner des Manifests und Mitbegründer von Pragmatic Programming, aus dem Jahr 2014. 

"Das Wort 'agil' wurde bis zu einem Punkt ausgehöhlt, an dem es praktisch bedeutungslos ist - und das, was als agile Gemeinschaft gilt, scheint größtenteils eine Plattform für Berater und Anbieter von Dienstleistungen und Produkten zu sein ... Mit der steigenden Popularität des Manifests wurde das Wort 'agil' zu einem Magneten für jeden, der eine Idee vorzubringen, Stunden in Rechnung zu stellen oder Produkte zu verkaufen hatte. Es wurde zu einem Marketingbegriff. Daher denke ich, dass es an der Zeit ist, das Wort 'Agile' in den Ruhestand zu schicken." 

Rückbesinnung

Das eigentlich Traurige daran ist für mich, dass junge Entwickler Agile ablehnen und als Mittel des Managements betrachten, ihren Entwicklern unrealistische Versprechungen abzuringen und sie zu haufenweise Überstunden zu zwingen. Ich verstehe das. Die einzige Agilität, die sie je kennengelernt haben, ist Agilität als Kontrollmechanismus und nicht als Werkzeug der Selbstermächtigung, das sie mit Freude annehmen könnten. Ich hoffe aber, dass uns der Anstoß zu Diskussionen über die Geschichte und die ursprüngliche Vision von Agilität dabei helfen kann, uns zu erinnern, wie es eigentlich laufen sollte. 

Die gute Nachricht bei all dem ist, dass die Grundsätze des Agilen Manifests heute genauso klug und wichtig sind wie vor 20 Jahren. Selbst vermeintliche Abtrünnige wie Jeffries und Thomas sehen das so. 

Jeffries sagt in dem oben erwähnten Artikel: "Die Werte und Prinzipien des Manifests für agile Softwareentwicklung sind jedoch immer noch der beste Weg, den ich kenne, um Software zu entwickeln, und aufgrund meiner langen und umfangreichen Erfahrung würde ich diesen Werten und Prinzipien folgen, ganz gleich, welche Methode die übergeordnete Organisation verwendet." 

Dem stimme ich zu. 

Es ist nicht mehr hip oder cool, über Agile zu sprechen. Agile ist langweilig. Es macht eh jeder, oder? Deswegen war das Jubiläum des Manifests die perfekte Gelegenheit, über die vorhergehenden 20 Jahre nachzudenken und uns ein paar Fragen zu stellen: 

• Was lief gut? 
• Was lief schlecht? 
• Was möchten wir in Zukunft anders machen? 

Einige von uns hier bei Simple Thread, die die Revolution miterlebt haben, planen, in den kommenden Monaten über jedes der ursprünglichen zwölf agilen Prinzipien nachzudenken, ihre eigentliche Bedeutung und ihren Wert im aktuellen Umfeld der Softwareentwicklung zu erfassen. 

Ich hoffe, dass wir durch das eingehende Betrachten der Gründungsprinzipien aus der Vergangenheit lernen können und, um es mit den Worten von Dave Thomas zu sagen, unsere Agilität bewahren können, selbst wenn wir uns entscheiden, "Agile" aufzugeben. 

Bild: Pexels