Was zur Hölle ist eigentlich Agilität?
Agilität – ein Wort, das in der Welt der Softwareentwicklung oft missverstanden wird. In den Fluren von IT-Abteilungen und in den Räumen von Management-Meetings wird es häufig als Allheilmittel für alle Probleme angesehen. „Zu langsame Entwicklung? – Kein Problem! Sei agil!“, „Der Wettbewerb rennt uns davon? – Kriegen wir hin! Agilität wird’s richten!“, „Die Mitarbeiter:innen sind demotiviert? – Da haben wir doch was. Agil!“ Aber was steckt wirklich dahinter? Entgegen des Mainstream-Gedanken, dass Agilität eine Art magische Formel ist, die sich in einer endlosen Aufzählung von Methoden und Prozessen verliert, liegt das wahre Ziel von Agilität in etwas viel Einfacherem: der Entwicklung guter Software.
Die Ursprünge der Agilität
Agilität wurde einst ins Leben gerufen, um Softwareentwicklungsprozesse von den Fesseln schwerfälliger, bürokratischer Methoden zu befreien. Agilität entstand als Antwort auf diese Herausforderungen – nicht als theoretisches Konzept, sondern als praktische Notwendigkeit. Dabei geht es nicht darum, einem Trend zu folgen oder sich blindlings an vorgefertigte Methoden zu klammern. Das Herzstück von Agilität ist die Praxis – die Kunst, gute Software zu entwickeln, die wirklich funktioniert und sich in der realen Welt bewährt. In diesem Sinne ist Agilität nicht nur ein Set von Werkzeugen oder Methoden wie Scrum oder Kanban. Es ist eine Denkweise, die sich auf das Ergebnis konzentriert: Software, die Wert schafft, die sich an Anwender:innen orientiert und die sich schnell an verändernde Anforderungen anpassen kann. Dieser Ansatz stellt die Bedürfnisse und das Feedback der Nutzer in den Mittelpunkt und erkennt an, dass der wahre Maßstab für Erfolg nicht in der Einhaltung von Prozessen liegt, sondern in der Qualität und Nützlichkeit des Endprodukts. Oder anders ausgedrückt: Nicht derjenige, der den Scrum Guide am genauesten befolgt, gewinnt das Spiel, sondern derjenige, der die aus Sicht des Marktes beste Software baut.
Das Henne-Ei-Problem der Agilität
Was war denn nun zuerst da in der Agilität? Die Methoden oder das, was wir heute als das Manifest für Agile Softwareentwicklung kennen? Manchmal wird diese Frage mit dem Konstrukt eines ominösen „agilen Mindsets“ beantwortet. In nächsten Schritt folgen dann die übergriffigen Forderungen, Personen in Organisationen sollten doch bitte mal dieses agile Mindset entwickeln. Das ist höchst problematisch, da es zum einen Menschen abstempelt (agil oder nicht agil) und der Mindset-Begriff gleichzeitig extrem unspezifisch bleibt (und übrigens auch nirgendwo im Manifest auftaucht).
Die Ursprünge des Manifests sind deutlich profaner: Alle Unterzeichner waren echte Könner im Bereich der Softwareentwicklung. Sie bedienten und entwickelten für sich dabei eine Reihe von Methoden, die sie als passend für ihre tägliche Arbeit empfanden. Die Methoden waren damals auch noch deutlich vielfältiger, als es die heutige Scrum-Monokultur vermuten lassen würde. [1]
Die legendäre Konferenz in Snowbird, in der das Manifest geschrieben wurde, stand an Tag 2 anscheinend kurz davor, ohne belastbares Ergebnis zu enden: „Lots of great discussions happened over the 2-day event, however, late into day 2, nothing actionable had come out. The team was kind of in analysis paralysis until Dave Thomas and Martin Fowler tried to summarize the discussions so far based on the common ground between the different methods.“ [2] Am Ende konnten sich die Teilnehmer dank der Intervention von Thomas und Fowler auf eine Art kleinsten gemeinsamen Nenner einigen: Die verbindenden Elemente und Gemeinsamkeiten der Methoden, denen sie damals folgten.
Paradoxerweise standen also am Anfang tatsächlich die Methoden. Die Unterzeichner des Manifests waren aber allesamt begnadete Könner ihres Faches, für die ihre Methoden nicht mehr als praktische Werkzeuge bei ihrer Arbeit waren. In diesem Sinne ist das Manifest eine Art Methodenfilter[3], der dabei hilft zwischen sinnvollen und unsinnigen Ansätzen in der Softwareentwicklung zu unterscheiden. Nicht mehr und nicht weniger.
Und auch wenn die Methoden am Anfang standen: Sie sind nichts anderes als Werkzeuge in der Hand talentierter Softwareentwickler:innen. Mithilfe des Manifestes können diese besser entscheiden, welches Werkzeug sie einsetzen wollen. Dies ist auch die gravierendste Abgrenzung zu den schwergewichtigen Prozessen, die den Prozess und deren Befolgung in den Mittelpunkt des Handelns stellen.
Agilität jenseits von Methoden
Die Faszination für Methoden wie Scrum und Kanban in der agilen Welt kann deshalb zu einer eingeschränkten Sichtweise führen. Während diese Praktiken einen Rahmen bieten, besteht die Gefahr, dass sie zu starren Schablonen werden, die das eigentliche Ziel der Agilität verdecken: die flexible und effektive Entwicklung von Software.
Das wahre Potenzial von Agilität liegt darin, diese Methoden als Ausgangspunkt zu nutzen und sie kreativ anzupassen, um den jeweiligen Herausforderungen gerecht zu werden. Gleichzeitig ist es wichtig, die grundlegenden Konzepte der Agilität verinnerlicht zu haben und genau im Sinne des Methodenfilters gute von schlechten Ideen unterscheiden zu können. Es ist zum Beispiel eine gute Idee, auf den Fluss von Arbeit zu schauen und diesen zu optimieren, und es ist eine schlechte Idee, auf die Auslastung einzelner Mitarbeiter:innen zu schauen.
Ein tieferes Verständnis von Agilität erfordert deshalb einen Schritt zurück, um das Gesamtbild zu betrachten: Wie können wir unsere Prozesse und Arbeitsweisen so gestalten, dass sie die Entwicklung hochwertiger Software fördern, anstatt uns in methodischen Feinheiten zu verlieren? Es geht darum, ein Umfeld zu schaffen, in dem ständige Verbesserung, Flexibilität und der Fokus auf das Endprodukt nicht nur als Ideale, sondern als praktische Realität gelebt werden.
Technische Fertigkeiten, Kundenorientierung und Teamarbeit
Das Manifest kann wie eine Art Brille aufgesetzt werden, um damit das konkrete Umfeld zu analysieren und anzupassen. Drei Beispiele dazu findest du hier.
Auch wenn sie ihre Wurzeln in Methoden hat, geht Agilität in der Softwareentwicklung weit über diese hinaus und konzentriert sich auf das grundlegende Ziel, effektive und wertvolle Software zu entwickeln. Wer sich also gefragt hat, was zur Hölle mit Agilität gemeint ist, weiß nun, dass sich wahre Agilität in der Fähigkeit zeigt, Methoden an spezifische Projektsituationen anzupassen und das aus einem tiefen Verständnis für agile Prinzipien heraus.
ÜBER DEN AUTOR
Jonathan Frankenberger hat schon während seines Informatik-Studiums gemerkt, dass sich Software mit agilen Methoden meistens besser entwickeln lässt. Nach einem längeren Ausflug in die Wasserfall-Welt arbeitet er seit 2016 wieder agil in unterschiedlichen Rollen, vor allem mit Scrum. Aktuell unterstützt er als Agile Coach Produktteams bei BettercallPaul dabei, „bessere Wege zu erschließen, Software zu entwickeln“. Daneben beschäftigt er sich auch intensiv mit der Frage, wie Organisationen im 21. Jahrhundert aussehen müssen, um Teams eine gute Umgebung bieten zu können.
[1] https://agilemanifesto.org/history.html
[2] https://www.kaizenko.com/a-behind-the-scenes-look-at-the-writing-of-the-agile-manifesto/
[3] Den Begriff des Methodenfilters habe ich bei Intrinsify von Mark Poppenborg und Lars Vollmer gelernt.
