Missverstandene Agilität
- “Unsere Entwicklung ist zu langsam? Kein Problem! Fortan arbeiten wir agil!”
- “Die Konkurrenz ist schneller? Kein Thema! Mit Agilität überholen wir sie!”
- “Die Mitarbeiterinnen und Mitarbeit sind demotiviert? Wir haben die Lösung: Agiles Arbeiten!”
Leider übersehen diese “Lösungsansätze” das primäre Ziel von Agilität: die Entwicklung guter Software. Genau darum geht es im Manifest für agile Softwareentwicklung. Gute Softwareentwicklung. Nicht mehr, aber auch nicht weniger.
Die Praxis – das Herzstück der Agilität
Agilität wurde ursprünglich ins Leben gerufen, um Softwareentwicklungsprozesse von den Fesseln schwerfälliger und bürokratischer Methoden zu befreien. Agilität entstand als Antwort auf diese Herausforderungen – nicht als theoretisches Konzept, sondern als praktische Notwendigkeit. Es ging nicht darum, einem Trend zu kreieren oder oder starre Methoden zu definieren. Das Herzstück von Agilität ist die Praxis – die Kunst, gute Software zu entwickeln. Software, 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, sich an den Anwenderinnen und Anwender orientiert und sich schnell an verändernde Anforderungen anpassen kann. Dieser Ansatz stellt die Bedürfnisse und das Feedback der Anwender:innen in den Mittelpunkt und erkennt an, dass der wahre Maßstab für Erfolg nicht die Einhaltung von Prozessen ist, sondern die Qualität und Nützlichkeit des Endprodukts.
Anders ausgedrückt: Nicht derjenige, der sich am genauesten an den Scrum Guide hält, gewinnt das Spiel, sondern derjenige, der die aus Sicht des Marktes beste Software entwickelt.
Das agile Mindset oder die Ergebnisse im Fokus
Was war zuerst da in der Agilität? Die Methoden oder das, was wir heute als Manifest für agile Softwareentwicklung kennen? Manchmal wird diese Frage mit dem Konstrukt eines ominösen “agilen Mindsets” beantwortet. Der nächste Schritt ist dann die übergriffige Forderung, die Menschen in den Organisationen sollten doch bitte dieses agile Mindset entwickeln. Das ist höchst problematisch, weil es zum einen Menschen etikettiert (agil oder nicht agil) und zum anderen der Begriff Mindset extrem unspezifisch bleibt (und im Übrigen auch nirgendwo im Manifest auftaucht).
Die Ursprünge des Manifests sind viel profaner: Alle Unterzeichner waren echte Experten auf dem Gebiet der Softwareentwicklung. Sie nutzten und entwickelten für sich selbst eine Reihe von Methoden, die sie für ihre tägliche Arbeit für geeignet hielten. Diese Methoden waren damals auch deutlich vielfältiger, als es die heutige Scrum-Monokultur vermuten lässt. [1]
Die legendäre Konferenz in Snowbird, auf der das Manifest geschrieben wurde, stand am zweiten Tag offenbar 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] Dank der Intervention von Thomas und Fowler konnten sich die Teilnehmer schließlich auf eine Art kleinsten gemeinsamen Nenner einigen: Die verbindenden Elemente und Gemeinsamkeiten der Methoden, die sie zu diesem Zeitpunkt verfolgten.
Paradoxerweise waren es also die Methoden, die am Anfang standen. Die Unterzeichner des Manifests waren aber allesamt begnadete Könner ihres Fachs, für die ihre Methoden nicht mehr als praktische Werkzeuge ihrer Arbeit waren. In diesem Sinne ist das Manifest eine Art Methodenfilter[3], der hilft, sinnvolle von unsinnigen Vorgehensweisen in der Softwareentwicklung zu unterscheiden. Nicht mehr und nicht weniger.
Auch wenn Methoden am Anfang stehen: Sie sind nichts anderes als Werkzeuge in den Händen talentierter Softwareentwicklerinnen und -entwickler. Mit Hilfe des Manifests können diese besser entscheiden, welches Werkzeug sie einsetzen wollen. Dies ist auch der gravierendste Unterschied zu den schwerfälligen Vorgehensmodellen, die den Prozess und seine Einhaltung in den Mittelpunkt des Handelns stellen.
Agilität jenseits von Methoden
Die Faszination für Ansätze wie Scrum und Kanban in der agilen Welt führt in der gelebten Praxis immer wieder zu eingeschränkten Sichtweisen. Während diese Ansätze 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, Methoden als Ausgangspunkt zu nutzen und sie kreativ an die jeweiligen Herausforderungen anzupassen. Dabei ist es wichtig, die Grundkonzepte der Agilität zu verinnerlichen und im Sinne des Methodenfilters gute von schlechten Ideen unterscheiden zu können. So ist es zum Beispiel eine gute Idee, auf den Fluss von Arbeit zu schauen und diesen zu optimieren, und eine schlechte Idee, auf die Auslastung einzelner Mitarbeiter:innen zu schauen.
Ein tieferes Verständnis von Agilität erfordert daher einen Schritt zurück, um das Gesamtbild zu betrachten: Wie können wir unsere Prozesse und Arbeitsweisen so gestalten, dass sie die Entwicklung qualitativ hochwertiger Software fördern, anstatt uns in methodischen Feinheiten zu verlieren? Es geht darum, ein Umfeld zu schaffen, in dem kontinuierliche Verbesserung, Flexibilität und der Fokus auf das Endprodukt nicht nur als Ideale, sondern als praktische Realität gelebt werden.
Zusammenfassung
Das Manifest für agile Softwareentwicklung kann als Brille dienen, um das konkrete Umfeld zu analysieren und anzupassen. In der agilen Softwareentwicklung spielen bspw. technische Fähigkeiten eine entscheidende Rolle. Die Fähigkeit, qualitativ hochwertige Software effizient zu entwickeln, ist das Fundament, auf dem Agilität aufbaut. Es geht nicht nur darum, schnell zu liefern, sondern auch sicherzustellen, dass das Gelieferte von hoher Qualität und nachhaltig ist. Agile Teams müssen daher ständig bestrebt sein, ihre technischen Fähigkeiten zu verbessern und sich mit den neuesten technologischen Entwicklungen vertraut zu machen. Unterstützt mich mein Umfeld dabei, genau das zu erreichen, oder bevorzugt es schnelle, kurzfristige und unsaubere Lösungen, die meine Softwareentwicklung langfristig verlangsamen?
Auch wenn Agilität ihre Wurzeln in Methoden hat, geht sie weit darüber hinaus und konzentriert sich auf das grundlegende Ziel, effektive und wertvolle Software zu entwickeln. Die Kunst von Agilität liegt in der Fähigkeit, Methoden basierend auf einem tiefen Verständnis der agilen Prinzipien an spezifische Projektsituationen anzupassen. Möglicherweise wird dadurch auch Ihre Entwicklung schneller, vielleicht überholen Sie so auch Ihre Konkurrenz, und evtl. hilft das auch dabei, Mitarbeiterinnen und Mitarbeiter zu motivieren; insgesamt sind das allerdings nur Randaspekte. Das eigentliche Thema bei Agilität ist und bleibt die Entwicklung guter Software.
Hinweise:
Wollen Sie sich mit Jonathan Frankenberger über agile Arbeitsweisen, Machine Learning oder Softwareentwicklung austauschen? Leicht können Sie mit ihm über LinkedIn Kontakt aufnehmen.
[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 Methodenfilter habe ich bei Intrinsify von Mark Poppenborg und Lars Vollmer gelernt.
Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!
Jonathan Frankenberger hat einen weiteren Beitrag im t2informatik Blog veröffentlicht:
Effektive Praktiken für eine erfolgreiche Softwaretransition
Jonathan Frankenberger
Jonathan Frankenberger hat schon während seines Informatik-Studiums gemerkt, dass sich Software mit agilen Methoden häufig 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.