© Shutterstock / RachenArt
Weiterentwicklung des Agilen Manifests

Agile ist tot, lang lebe Modern Agile!


Das Agile Manifest ist mittlerweile 20 Jahre alt und seitdem unverändert. Was einerseits für gute Ideen spricht, läuft Gefahr, nicht mehr zu aktuellen Entwicklungen zu passen. Zudem gibt es zunehmend Kritik an dem, was heute alles als „Agile“ verkauft wird. Modern Agile versucht, darauf eine angepasste, neue Antwort zu geben – oder vielmehr neue Fragen zu formulieren, die uns besser beim Finden möglicher, für uns passender Lösungen helfen.

Vor ziemlich genau 20 Jahren, im Februar 2001, trafen sich auf einer Skihütte in Snowbird, Utah (USA), 17 gestandene Softwareentwickler – darunter so bekannte Namen wie Kent Beck, Alistair Cockburn, Martin Fowler, Andrew Hunt, Ron Jeffries, Robert C. Martin und Jeff Sutherland – und formulierten ihre Ideen, wie Software modern entwickelt werden sollte. Das „Agile Manifest“ (genauer: Das „Manifest für agile Softwareentwicklung“) war geboren [1]. Die vier Werte bzw. Leitsätze dürften heute vielen bekannt sein [2]. Agilisten schätzen

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge,

  • funktionierende Software mehr als umfassende Dokumentation,

  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung,

  • das Reagieren auf Veränderung mehr als das Befolgen eines Plans.

Alle genannten Punkte (auch Dokumentation etc.) sind wichtig, aber die jeweils erstgenannten Werte gelten als wertvoller, weil sie Flexibilität und Pragmatismus fördern. Entsprechend sollten die jeweils zweitgenannten Werte nicht übertrieben werden, weil ansonsten starre Prozesse und zu viel Bürokratie zügige Reaktion auf sich ändernde Kundenanforderungen verhindern.

Dazu wurden dann noch zwölf Prinzipien formuliert, die die Werte etwas genauer beschreiben. Unter anderem geht es darum,

  • wertvolle (nützliche) Software frühzeitig und kontinuierlich zum Kunden auszuliefern,

  • dass Fachexperten und Entwickler täglich zusammenarbeiten,

  • ein besonderes Augenmerk auf technische Exzellenz und gutes Design zu legen.

Und außerdem um regelmäßige Reflexion über das Arbeiten an sich, um ständig immer besser werden zu können.

Das war revolutionär und ziemlich radikal, denn Software wurde damals – und manchmal leider auch heute noch – häufig nur wenige Male pro Jahr, dafür als große Releases mit vielen Änderungen ausgeliefert. Danach folgten dann jede Menge Troubleshooting, Hotfixes – und als Vorbereitung des nächsten Releases der Kampf darum, welche Änderungen es in die nächste Version schafften und welche leider noch ein paar Monate warten mussten.

Die Ideen des Agilen Manifests erwiesen sich für viele Firmen als hilfreich. So hilfreich, dass bei der jährlichen „State of Agile“-Umfrage seit 2016 ca. 95 % aller Befragten angeben, dass ihre Firma bzw. Organisation agile Entwicklungsmethoden einsetzt [3].

Liest man allerdings, was einige der Erstunterzeichner des Agilen Manifests davon halten, was heute aus ihrer Idee geworden ist, wird man stutzig. Ron Jeffries beispielsweise schreibt, dass Entwickler „Agile“ aufgeben sollten [4]. Genauer: Entwickler sollten aufhören, das zu tun, was heutzutage „Agile“ genannt wird. Wir sollen uns von dem Begriff lösen. Warum das? Was bzw. wie war „Agile“ oder vielleicht besser Agilität – denn früher? Denn die Werte und Prinzipien des Agilen Manifests sind immer noch richtig, nur die Umsetzung ist oft toxisch für alle Beteiligten.

Agilität damals

Trotz der damaligen Einfachheit und Radikalität war den Autoren des Manifests daran gelegen, dass Softwareentwicklung nicht im Chaos versinkt, sondern geordnet stattfindet. Man wollte einen Rahmen finden, an dem sich die leichtgewichtigen Vorgehensweisen der damaligen Zeit orientieren konnten.

Und leichtgewichtige Vorgehensweisen gab es in den 1990er Jahren einige. Extreme Programming (XP) ist sicherlich eine der bekanntesten, weil es nützliche Praktiken wie testgetriebene Entwicklung, Continuous Integration, Refactoring und Story Cards vereinte. Aber es gab beispielsweise auch Crystal, eine ganze Methodenfamilie, die für Projekte mit einer unterschiedlich großen Anzahl von Beteiligten auch ein unterschiedliches Vorgehen vorschlug. Oder Feature-driven Development, die Dynamic Systems Development Method oder das Adaptive Software Development. Es gab also eine Vielzahl von unterschiedlichen Vorgehensweisen, passend für verschiedene Situationen und Projekte, weil ein einziges Vorgehen unmöglich alle Anforderungen und Wünsche abdecken kann, wenn es gleichzeitig möglichst konkrete Hilfestellungen geben soll.

Damals entstand auch Scrum, das mittlerweile wohl bekannteste Rahmenwerk. So bekannt, dass viele es heute synonym für agiles Vorgehen verwenden.

Und heute?

Entsprechend ist es heute oft ein Problem, wenn Firmen und Teams unreflektiert Scrum einsetzen. Bitte nicht falsch verstehen: Scrum kann vernünftig umgesetzt werden und unglaublich hilfreich sein, wenn es zum Team und zur Aufgabe passt. Viel zu oft aber findet man einfach nur Cargo Cult vor, d. h., man macht Scrum, weil irgendwer mal irgendwo in einem anderen Team oder Unternehmen gesehen hat, dass es dort ganz gut funktionierte. Hat man dabei aber nicht verstanden, warum gewisse Rituale durchgeführt werden und welche Voraussetzungen notwendig sind, fällt es einem vermutlich schwer zu erkennen, wann man aus dem vorgegebenen Rahmen ausbrechen und sich bzw. sein Vorgehen weiterentwickeln sollte.

Oft werden Begriffe und Rollen aus Scrum nur verwendet, um den vorhandenen Prozess plakativ neu zu benennen und sich zugleich möglichst wenig verändern zu müssen. Nur kein Risiko eingehen, nichts Neues ausprobieren. Entscheidungen sollen safe sein, damit ich nicht zur Verantwortung gezogen werden kann, wenn Probleme auftauchen – doch genau das ist bei Veränderungen völlig normal. Das zementiert einmal getroffene Entscheidungen und schafft neue Prozesse. Frameworks zum Skalieren der noch gar nicht vorhandenen Agilität bringen Komplexität statt Flexibilität und Leichtgewichtigkeit. All das widerspricht komplett den ursprünglichen Ideen des agilen Manifests.

Die Folge? Weil im Wesentlichen nur neue Etiketten drauf sind, läuft der gleiche alte, träge Prozess weiter. Und alle wundern sich, dass sich nicht wirklich etwas ändert. Man merkt das meist daran, dass die neuen Ideen und Rituale dauerhaft Fremdkörper bleiben: Die Daily Stand-up Meetings sind langweilig, die Retrospektiven nicht offen und ehrlich, die Schätz- und Planungsmeetings fühlen sich sinnfrei und wie Zeitverschwendung an. Wir sprechen dann auch von agilem Theater – alle spielen mit, das ist mal ganz lustig anzuschauen. Aber dauerhaft möchte man das nicht erleben. Wir sind Softwareentwickler, keine Schauspieler.

Schlimmer noch ist das sogenannte „Dark Agile“. Denn echte Agilität verlangt Transparenz über die Arbeit, über Probleme und deren Lösung. Wenn das aber als Kontrollinstrument missbraucht wird, um noch mehr Druck auszuüben und die Mitarbeiter zu Überstunden zu zwingen oder bei Problemen Schuldige zu suchen und zu bestrafen, dann ist das nicht nur kontraproduktiv, sondern extrem schädlich. Mitarbeiter werden dadurch krank, brennen aus und verstecken sich schließlich hinter Prozessen und Bürokratie, wo sie möglichst unangreifbar sind. Für Unternehmen ist das der schleichende Weg in den Niedergang, weil dann niemand mehr Probleme offen benennen wird.

Das alles hat Gegenentwürfe provoziert. Ein schönes Beispiel ist die Programmer Anarchy von Fred George [5]: Lasst die Entwickler doch einfach mal machen, vielleicht auch herumfrickeln. Aber dann haben wir etwas, das wir deployen, messen bzw. beobachten und anschließend bewerten können. Und wenn es nicht gut ist, wird es geändert bzw. neu gemacht. Das war vor knapp zehn Jahren innovativ, provokativ, und aus Sicht von uns Entwicklern irgendwie cool. Und es enthielt viele Ideen und Wahrheiten, wie man Aufgaben in akzeptabler Zeit zur letztendlichen Zufriedenheit aller Beteiligten fertigbekommt.

Das Problem dabei: Die Idee war wieder extrem und radikal. Und das mögen Manager häufig nicht. Also wird eine gute Idee aus Angst oder Unwissenheit abgelehnt. Oder weil sie zu leicht missverstanden werden kann (Keine Dokumentation mehr! Keine Unit-Tests mehr!). Damit teilt die Programmer Anarchy das gleiche Schicksal wie Extreme Programming. Dinge geeignet zu benennen ist sehr, sehr schwer.

Und nicht so radikale, aber trotzdem gute und nützliche Ansätze wie das Software Crafting sind im agilen Hype leider etwas untergegangen.

Wenn also Agilität im Sinne des agilen Manifests so schwer zu greifen ist und die anderen Ansätze auf Ablehnung stoßen oder ignoriert werden – wie setzen wir uns dann Ziele, die alle Beteiligten einfacher verstehen können und aus eigenem Antrieb erreichen wollen?

Modern Agile

Warum so eine lange Bestandsaufnahme? Weil man damit die Beweggründe besser versteht, warum sich in den letzten Jahren immer mehr Menschen Gedanken gemacht haben, wie man den Fokus zurück auf die guten und richtigen Grundideen des agilen Manifests bringt bzw. wie man diese neu und besser greifbar formuliert für die Software- und Produktentwicklung in den 2020er Jahren.

Und so formulierten 2015 Joshua Kerievsky und sein Team von Industrial Logic die Ideen zu Modern Agile [6], [7] und entwickelten sie seitdem mit einer ganzen Community und als Open Source weiter [8]. Modern Agile wurde wieder radikal auf ganz wenige Kernelemente vereinfacht. Und es ist keine neue Vorgehensweise oder Methodik, sondern eher eine Hilfestellung, um über den eigenen Zustand und das eigene Vorgehen nachzudenken und dann gezielt anzupassen. Modern Agile definiert vier Guiding Principles, die wir uns im Folgenden genauer anschauen werden:

  • Make People Awesome

  • Make Safety a Prerequisite

  • Deliver Value Continuously

  • Experiment & Learn Rapidly

Im Deutschen könnten wir das mit „Leitprinzipien“ übersetzen, aber wir müssen aufpassen, dass wir das nicht zu starr als strenge Regeln sehen. Vielleicht wäre „Grundideen“ oder „Leitplanken“ die bessere Übersetzung.

Die Leitplanken von Modern Agile sind bewusst sehr allgemein gehalten, dabei aber einfach, verständlich, griffig und in vielen Bereichen einsetzbar. Sie sind also nicht nur rein für die Softwareentwicklung gedacht, sondern für die gesamte Produktentwicklung und auch für ganz andere Arbeitsbereiche. Aber, und das ist für uns wiederum wichtig, es passt hervorragend dazu, wie Software modern und erfolgreich entwickelt und ausgeliefert wird.

Während diese Prinzipien auf den ersten Blick etwas zu einfach, fast trivial wirken mögen, steckt doch sehr viel dahinter, wenn man genauer darüber nachdenkt. Meiner Erfahrung nach wirken diese vier Prinzipien, wenn man sie als Fragen an sich, sein Team...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang