20 Jahre Agile: die gescheiterte Rebellion
(simplethread.com)<p>- 20 Jahre nach der Veröffentlichung des Agile Manifesto sind zwei Dinge offensichtlich:<br />
1. Als Bezeichnung hat Agile gewonnen. Niemand möchte als non-Agile bezeichnet werden.<br />
2. In der praktischen Umsetzung von Agile bleibt man weit hinter den revolutionären Ideen der Gründer zurück.<br />
- „Alle sagen, sie machen Agile, aber kaum jemand ist wirklich agil.“ Wie ist es zu dieser Situation gekommen?<br />
<br />
[ Whence The Manifesto : Wie begann das Manifest? ]<br />
- Im Februar 2001 traf sich eine Gruppe von 17 Softwareexperten in einem Skigebiet in Utah.<br />
- Nach einigen Tagen Diskussion verfassten sie gemeinsam das „Agile Software Development Manifesto“.<br />
<br />
- Wichtig ist, dass sie „Practitioners“ waren. Sie waren keine PMs, CTOs oder VPs of Engineering. Sie waren Entwickler, Programmierer, Wissenschaftler und Ingenieure. Sie schrieben damals weiterhin selbst Code und arbeiteten mit Stakeholdern zusammen, um Probleme zu lösen. Das ist wirklich wichtig.<br />
- Ein weiterer Punkt ist, dass das Agile Manifesto nicht aus dem Nichts entstand. Viele von ihnen hatten bereits Methodologien entwickelt oder verbreiteten sie gerade.<br />
→ XP, Scrum, DSDM, Adaptive Software Development, Crystal, FDD, Pragmatic Programming<br />
<br />
- Alle Mitglieder der Gruppe hatten viel Erfahrung in der Softwareentwicklung und suchten nach einem Ersatz für die damals marktbeherrschenden, dokumentationsgetriebenen und schwergewichtigen Softwareentwicklungsprozesse.<br />
- Der Kern des Manifests ist die Erklärung von vier Werten.<br />
<br />
„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir schätzen gelernt:<br />
- Individuen und Interaktionen mehr als Prozesse und Werkzeuge<br />
- Funktionierende Software mehr als umfassende Dokumentation<br />
- Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung<br />
- Reagieren auf Veränderung mehr als das Befolgen eines Plans<br />
Das heißt, obwohl wir die Werte auf der linken Seite wichtig finden, schätzen wir die auf der rechten Seite höher.“<br />
<br />
[ A New Hope : Eine neue Hoffnung ]<br />
- Aus der Perspektive von 2021 ist es leicht, moderne Praktiken der Softwareentwicklung als selbstverständlich anzusehen, aber 2001 waren diese Ideen ausgesprochen radikal.<br />
- Software entwickeln, bevor alle Anforderungen gesammelt und alle Features bewertet sind? Verrückt!<br />
- Ein wichtiger Punkt, der leicht vergessen wird: Agile war anfangs offen und kämpferisch anti-management.<br />
<br />
- Zum Beispiel plädierte Scrum-Mitbegründer Ken Schwaber dafür, alle Projektmanager abzuschaffen — nicht nur PMs aus Projekten zu entfernen, sondern den Beruf in der Branche ganz abzuschaffen.<br />
<br />
„Wir haben festgestellt, dass die Rolle des Projektmanagers bei komplexer, kreativer Arbeit unproduktiv ist.<br />
Die Gedanken des Projektmanagers, wie sie sich im Projektplan ausdrücken,<br />
bündeln nicht die Intelligenz aller, um das Problem bestmöglich zu lösen,<br />
sondern begrenzen die Kreativität und Intelligenz aller auf das, was im Plan steht.“<br />
<br />
- Scrum Master hatten fast keine Autorität und kein Stimmrecht bei Issues. Sie waren Servant Leader*, schützten das Team und räumten Hindernisse aus dem Weg, aber sie managten das Team nicht.<br />
→ Servant Leader: eine Führungskraft, die den Mitarbeitenden dient, ihr Wachstum und ihre Entwicklung unterstützt, Vertrauen zwischen Führung und Team aufbaut und so dazu beiträgt, dass Mitarbeitende selbstständig zum Erreichen der Organisationsziele beitragen<br />
- Auch XP hatte ursprünglich Tracker und Coach, die ähnlich funktionierten.<br />
<br />
- Alistair Cockburn, Erfinder von Crystal und der hexagonalen Architektur, sagte kürzlich in einem Tweet-Thread Folgendes:<br />
„Scrum hat in feindlichem Gebiet einen großartigen Deal abgeschlossen:<br />
- Das Management konnte 12-mal im Jahr, nach jedem Sprint, die Richtung nach Belieben ändern.<br />
- Das Team bekam einen vollkommen ruhigen Monat ohne Unterbrechungen oder Richtungswechsel, um schwere Denkarbeit und Umsetzung zu leisten.<br />
- Das Team konnte im Bid (zur Priorisierung) erklären, was in einem Monat machbar ist und was nicht — ohne Einmischung des Managements.<br />
- Kein Management hat je einen besseren Deal gemacht.<br />
- Kein Entwicklungsteam hat je einen besseren Deal gemacht.<br />
“<br />
(Der Tweet-Thread begann mit der Frage: „Woher kommt die Idee, dass Scrum-Teams 100 % aller einem Sprint zugewiesenen Items abschließen müssen? Das ist doch Unsinn.“ Es lohnt sich, den gesamten Original-Thread zu lesen.)<br />
<br />
- Ich bin zertifizierter Scrum Master, habe über 15 Jahre in Agile-Teams gearbeitet und viele populäre Bücher in diesem Bereich gelesen, aber ich habe selten eine so klare und prägnante Erklärung von Scrum gesehen.<br />
- Scrum wurde dafür gebaut, in feindlichen Umgebungen zu funktionieren. Es war ein Vertrag zwischen Entwicklern, die Zeit zum Nachdenken und Erkunden brauchten, und druckausübenden Managern.<br />
<br />
[ The Empire Strikes Back : Das Imperium schlägt zurück ]<br />
- In gewisser Weise war Agile eine Graswurzel-Arbeiterbewegung. Sie begann bei Praktikern und stieg bis ins Management auf. Wie konnte das erfolgreich sein?<br />
- Zum Teil, weil die Zahl der Entwickler zunahm und ihr Wertbeitrag fürs Geschäft stieg.<br />
- Der größere Grund war, dass traditionelle Wasserfall-Entwicklung nicht richtig funktionierte.<br />
- Software wurde komplexer, das Geschäftstempo schneller und die Nutzer anspruchsvoller, sodass es unmöglich wurde, alles im Voraus zu planen.<br />
- Iterative Entwicklung zu akzeptieren war logisch, für Manager, die alles planen wollten, aber auch etwas beängstigend.<br />
<br />
- Mitte der 2000er Jahre hatten Managements das noch nicht wirklich angenommen.<br />
- Dann kam irgendwann: „Probieren wir doch mal diese verrückte Idee aus, von der die Engineers dauernd reden. Wir reißen den Termin ohnehin, wie viel schlimmer kann es werden?“<br />
- Überraschenderweise begann es zu funktionieren. Die Teams waren anfangs etwas gehemmt (und langsam), aber sie fanden allmählich heraus, welche Muster für jedes Team funktionierten, und kamen auf Touren.<br />
- Nach ein paar Sprints erkannten sie die Kraft von funktionierender Software, Zusammenarbeit, Zeit für Inspektion und Anpassung — und davon, all das über alles andere zu priorisieren.<br />
<br />
- Über etwa fünf Jahre hinweg entwickelte sich Agile von einer Methode, von der man schon einmal gehört hatte, zu etwas, das zwar nicht allen vertraut war, aber immer bekannter wurde.<br />
- 2005 waren Agile und TDD echte Differenzierungsmerkmale.<br />
- 2010 machten moderne Softwareteams in irgendeiner Form alle Agile.<br />
- Zumindest in der Beratungsbranche war es eine Blase. Große Unternehmen bewegten sich allerdings wie immer langsamer.<br />
<br />
„Wir haben es geschafft! Wir haben gewonnen! Lasst uns alle feiern.“<br />
Das wäre das Ende der Geschichte, und man könnte den Browser-Tab schließen.<br />
<br />
„Winning was easy, young man. Governing’s harder.“<br />
„Zu gewinnen war leicht, junger Mann. Regieren ist schwerer.“<br />
→ George Washington, wie im Musical Hamilton dargestellt<br />
<br />
- Leider verlief die Geschichte von Agile, wie bei vielen Revolutionen, nicht so, wie die Gründer sie sich vorgestellt hatten.<br />
→ Es stellte sich heraus, dass „Individuen und Interaktionen“ schwer zu verkaufen sind. Prozesse und Tools zu verkaufen ist viel einfacher.<br />
→ Es stellte sich heraus, dass „funktionierende Software“ schwerer zu erstellen ist als unrealistische Pläne und viel Dokumentation.<br />
→ „Zusammenarbeit mit dem Kunden“ erfordert Vertrauen und Verletzlichkeit, aber beides ist im Business nicht immer vorhanden.<br />
→ Bei „auf Veränderung reagieren“ wurde oft dem Management mehr Gewicht gegeben, das langfristig planen und kontrollieren will.<br />
<br />
„Es stellte sich heraus, dass Agile sich oft wie Chaos anfühlt, wenn es nicht richtig umgesetzt wird.“<br />
<br />
- Aber diese vier Werte sind deswegen nicht falsch.<br />
- Es bedeutet vielmehr, dass all das etwas Aufwand braucht und den Mut, zu akzeptieren, dass Software ihrem Wesen nach unordentlich und chaotisch ist.<br />
- Man muss verstehen und daran glauben, dass man durch ständiges Lernen, Anpassen, Verbessern und Ausliefern am Ende an einen viel besseren Ort gelangt als beim Wasserfall — an einen ehrlicheren, realistischeren und produktiveren Ort.<br />
<br />
„Die Agile-Bewegung ist keine Anti-Methodology-Bewegung.<br />
Tatsächlich möchten viele von uns, dass das Wort ‚Methodologie‘ wieder Vertrauen gewinnt. Wir wollen das Gleichgewicht wiederherstellen.<br />
Wir akzeptieren Modellierung, aber nicht, um Diagramme in verstaubten Firmenarchiven abzulegen.<br />
Wir akzeptieren Dokumentation, aber nicht Hunderte Seiten Bücher, die nicht gepflegt und kaum genutzt werden.<br />
Wir machen Pläne, erkennen aber die Grenzen von Plänen in turbulenten Umgebungen an.<br />
Wer Unterstützer von XP, Scrum oder anderen Agile-Methodologien als ‚Hacker‘ abstempelt, zeigt Unwissen über die ursprüngliche Bedeutung der Begriffe ‚Methodologie‘ und ‚Hacker‘.“<br />
- Jim Highsmith, History: The Agile Manifesto<br />
<br />
- Das sind wichtige Punkte. Wir erstellen weiterhin Pläne und Dokumentation und müssen bei Agile diszipliniert bleiben. Es geht um Balance.<br />
- Wenn Ihre Organisation aber mit der Agile-Transformation kämpft und im Chaos versinkt, dann springt man leicht in ein Rettungsboot, das Zertifizierungen, Prozesse und Tools anbietet.<br />
- Management versteht Prozesse und Tools sehr viel besser als „selbstorganisierte Teams“.<br />
<br />
[ R̶e̶t̶u̶r̶n̶ ̶o̶f̶ ̶t̶h̶e̶ Rogue One : Rogue One (kehrt nicht zurück) ]<br />
- Hier bricht meine Drei-Akt-Struktur etwas zusammen. Denn ich sehe keine mutigen Rebellen zurückkehren, ohne das Agile-Label zu tragen.<br />
<br />
- Tool-Vendoren, Prozessberater und Experten machen oft Versprechen, die sie niemals einlösen können.<br />
- Deshalb haben wir SAFe (Scaled Agile Framework for Enterprise), Scaled Scrum und andere Enterprise-Versionen von Agile geschaffen.<br />
- Diese Frameworks wurden nicht in böser Absicht entwickelt und haben im richtigen Kontext vermutlich einen gewissen Wert.<br />
- Aber ich würde sie nicht Agile nennen.<br />
- Wenn man eine Methodologie skalieren will, die auf Individuen und Interaktionen fokussiert, entstehen zwangsläufig Probleme, und die ursprünglichen Werte der Methodologie werden beschädigt.<br />
<br />
- Ein berühmter Text, den Ron Jeffries, Unterzeichner des Agile Manifesto und Mitbegründer von XP, 2018 schrieb:<br />
<br />
„Entwickler sollten Agile aufgeben.<br />
Wenn ‚Agile‘ nicht richtig angewandt wird, führt es dazu, dass Entwickler stärker gestört werden, weniger Zeit für die Arbeit haben, stärker unter Druck gesetzt werden und aufgefordert werden, ‚schneller voranzukommen‘. Das ist schlecht für Entwickler und letztlich auch schlecht für das Unternehmen, weil falsch gemachtes ‚Agile‘ oft zu weit mehr Fehlern und langsameren Fortschritten führt, als tatsächlich erreichbar wäre. Häufig verlassen hervorragende Entwickler solche Unternehmen, sodass am Ende die Effizienz schlechter ist als vor der Einführung von ‚Agile‘.“<br />
<br />
- Ein weiterer berühmter Text stammt von Dave Thomas, ebenfalls Unterzeichner und Mitbegründer von Pragmatic Programming, aus dem Jahr 2014:<br />
<br />
„Agile ist tot. (Es lebe Agility.)<br />
Das Wort ‚Agile‘ ist faktisch bis zur Bedeutungslosigkeit subvertiert worden, und die Agile-Community ist im Großen und Ganzen zu einem Ort geworden, an dem Berater und Vendoren ihre Services und Produkte verkaufen. Als das Manifest populär wurde, wurde das Wort Agile zu einem Magneten für alles, das Unterstützung suchte, Stunden abrechnen wollte oder ein Produkt zu verkaufen hatte — und so zu einem Marketingbegriff.<br />
<br />
Deshalb denke ich, dass es Zeit ist, das Wort ‚Agile‘ in den Ruhestand zu schicken.“<br />
<br />
[ Retro : Zurück in die Vergangenheit ]<br />
- Besonders traurig ist es, junge Entwickler zu sehen, die Agile als Mittel verachten, mit dem Management unrealistische Versprechen herausholt und Entwickler dazu drängt, extrem viele Stunden zu arbeiten.<br />
- Das einzige Agile, das sie kennen, ist ein ihnen auferlegter Kontrollmechanismus — nicht ein Werkzeug der Selbstermächtigung, das man einst begrüßt hat.<br />
- Ich hoffe aber, dass eine Diskussion über die Geschichte und die ursprüngliche Vision uns hilft, uns daran zu erinnern, wie wir künftig weitermachen sollten.<br />
<br />
- Die gute Nachricht ist trotzdem, dass die Prinzipien des Agile Manifesto heute genauso klug und relevant sind wie vor 20 Jahren. Und selbst vermeintliche Apostaten wie Jeffries oder Thomas sehen das immer noch so.<br />
<br />
- In dem oben erwähnten Text sagt Jeffries Folgendes:<br />
„Die Werte und Prinzipien des Manifesto for Agile Software Development liefern jedoch weiterhin die beste mir bekannte Art, Software zu bauen, und auf Grundlage meiner langen und vielfältigen Erfahrung werde ich diese Werte und Prinzipien befolgen, unabhängig davon, welche Methodologie in größeren Organisationen verwendet wird.“<br />
<br />
- Dem stimme ich zu.<br />
- Heute über Agile zu sprechen ist weder hip noch cool. Agile ist langweilig.<br />
„Ihr macht doch alle Agile, oder?“<br />
- Gerade jetzt ist der perfekte Zeitpunkt, auf die letzten 20 Jahre zurückzublicken und sich ein paar Fragen zu stellen:<br />
→ Was ist gut gelaufen?<br />
→ Was ist schiefgelaufen?<br />
→ Was würden wir beim nächsten Mal anders machen?<br />
- Ich plane, in den nächsten Monaten zu den ursprünglichen 12 Agile-Prinzipien zurückzukehren, ihre ursprüngliche Bedeutung zu kontextualisieren und ihren Wert in der heutigen Softwareentwicklungslandschaft zu betrachten.<br />
<br />
„Meine Hoffnung ist, dass wir durch das Studium der Gründungsprinzipien aus der Vergangenheit lernen und — um es mit Dave Thomas zu sagen — selbst wenn wir ‚Agile‘ aufgeben, ‚Agility‘ bewahren können.“</p>
3 Kommentare