Dienstag, 1. September 2015

Zwei Begriffe von Agilität

Ist Agilität definierbar?


Vor einiger Zeit äußerte Ralf Westphal in seinem Blog eine recht scharfe Kritik an Martin Fowler. Fowler hatte die Meinung geäußert, agile Entwicklungsmethoden versagten sich per se einer strengen Definition – das sei nun mal eine Folge ihrer Agilität. Ob eine praktizierte Vorgehensweise agil sei, lasse sich bestenfalls intuitiv beurteilen („I know it when I see it“), und gerade dann könne man noch verschiedener Meinung sein.

Westphal kritisiert, dass damit der kritischen Überprüfung agilen Vorgehens die Grundlage entzogen wird: Warum agile Vorgehensweisen eigentlich besser sein sollen als andere, lässt sich eben nur dann begründen, wenn man auch sagen kann, was agile Vorgehensweisen denn überhaupt ausmacht. In der Folge liefert Westphal dann auch eine „persönliche“ Definition von Agilität, die im Wesentlichen drei Punkte nennt: Eine Vorgehensweise ist agil, wenn
  • das Ergebnis in Inkrementen hergestellt wird, die sich an für den Kunden verwertbarer Funktionalität orientieren
  • sie einen kontinuierlichen Lernprozess, insbesondere hinsichtlich des herzustellenden Produkts beinhaltet,
  • und wenn dabei unmittelbare Kommunikation zwischen Kunden und Herstellern besteht.
Zwei Dinge fallen an dieser Debatte auf: Zum einen geht es nicht um einzelne Vorgehensmodelle – also etwa um Scrum, Software Kanban, eXtreme Programming. Diese sind nämlich in der Regel durchaus klar beschrieben, und eine Überprüfung, ob und inwieweit z.B. „nach XP“ entwickelt wird, ist relativ leicht. Es geht vielmehr um die Frage nach dem Agilen als solchen, nach dem Kern, der den agilen Vorgehensmodellen, so verschieden sie im Einzelnen auch sein mögen, gemeinsam zugrunde liegt. Das führt zur zweiten Auffälligkeit: Auf das agile Manifest und die agilen Prinzipien gehen die Autoren nicht (bzw. nur ganz am Rande) ein. Dabei sollte man doch denken, dass sich die Frage, ob eine Vorgehensweise agil ist oder nicht, am ehesten anhand dieser zentralen Dokumente der agilen Bewegung beantworten lassen sollte. Oder?

Die Crux mit dem Manifest 


Ich kann die Zurückhaltung der Autoren allerdings verstehen. Das Manifest selbst ist eine Vorgabe für die Praxis, aber viel zu wenig spezifisch, um daraus unkontroverse Kriterien für die Bewertung von Vorgehensmodellen zu gewinnen. Das gilt, wenngleich in geringerem Maße, auch für die Prinzipien. Und das ist auch kein Wunder. Agile Vorgehensweisen wurden zunächst von Praktikern entwickelt, die konkrete Antworten auf die Herausforderungen eines Entwicklungsalltags fanden, der als starr und als wenig kundenorientiert empfunden wurde. Diese Vorgehensweisen wurden ja nicht aus dem agilen Manifest abgeleitet, sondern umgekehrt: Aus Vorgehensweisen, die aus verschiedenen Gründen erfolgreich waren und der sehr nahe liegenden Annahme, dass es bei all diesen Ansätzen einen gemeinsamen Wesenskern gibt, wurde das agile Manifest und wurden die agilen Prinzipien zusammengetragen.

Aber ist nun nur agil, was nachweislich allen agilen Prinzipien gerecht wird? Oder gibt es wichtige und weniger wichtige Prinzipien? Was ist notwendig, was hinreichend für Agilität? Bei der Beantwortung solcher Fragen ist man letztlich auf sich allein gestellt. Das heißt: Man muss mutig aus der Deckung treten, und diese Entscheidungen selbst fällen. Liegt erst einmal ein Ansatz vor, kann dieser dann diskutiert und weiterentwickelt werden.

Genau das hat Ralf Westphal gemacht, und das Ergebnis gefällt mir ausgesprochen gut: Wenige, dafür leicht verständliche und überprüfbare Kriterien, von denen sich zudem gut argumentieren lässt, dass sie den Kern der ursprünglichen Agilitätsidee abdecken. Zugleich sind sie so allgemein, dass sie auf vielfältige Weise von konkreten Vorgehensmodellen erfüllt werden können.

Agilität - historisch und intuitiv


Ist das Thema „Agilität definieren“ damit also erledigt? Ich denke, nicht. Vielmehr glaube ich, dass wir noch eine weitere Definition von Agilität benötigen. Warum?

Nun, Ralf Westphal definiert Agilität im Sinne der „historischen“ Agilitätsbewegung. Er abstrahiert von konkreten Neuerungen, die durch diese Bewegung in die Softwareentwicklung eingeführt wurden und gelangt so zu den drei Kriterien. Ein Projekt, das diese Kriterien nicht erfüllt, ist nicht agil, weil es seiner Organisationsform und Praxis nach nicht zu dieser Schule gerechnet werden kann. Doch daneben gibt es einen allgemeineren Agilitätsbegriff, von dem ich ziemlich sicher bin, dass wir ihn regelmäßig ganz intuitiv verwenden. Ich will versuchen, diese intuitive Verwendung explizit zu machen und genauer zu fassen.

Agilität im Wortsinne


Wie schon erwähnt, entstand die Agilitätsbewegung als Reaktion auf eine Praxis, die als starr und unbeweglich empfunden wurde. Der Begriff „agil“ bedeutet ja nichts anderes, als „beweglich“, „wendig“, „fähig, die Richtung zu ändern“. Verfolgt man diesen Gedanken weiter, so ist Agilität im Kern die Fähigkeit eines Projekts, Änderungen gerecht zu werden, insbesondere natürlich mit Bezug auf Anforderungen. [1]

Ein erster, naheliegender Gedanke ist daher, dass ein Projekt umso agiler ist, je kurzfristiger es auf solche Änderungen reagieren kann. Doch der zeitliche Aspekt ist oft gar nicht das wichtigste Kriterium. Entscheidender ist häufig die Frage nach dem zusätzlichen Aufwand, den eine Kursänderung hervorruft. Ist der Änderungsaufwand zu hoch – dies kann technische genauso wie organisatorische Aufwände betreffen – so kann eine Anforderungsänderung unter Umständen das Ende eines Projekts bedeuten. [2]

Ein dritter Gesichtspunkt ist die Sicherung des bisher im Projekt geschaffenen Wertes: Wenn man sich mit Windeseile neuen Themen zuwenden muss – was wird dann aus der bisher geleisteten Arbeit? Ist sie verloren oder muss sie erst mit großem Aufwand in einen verwertbaren Zustand gebracht werden oder ist sie bereits von vorn herein in einem verwertbaren Status? Diese Frage stellt sich insbesondere bei einem Projektabbruch aus projektexternen Gründen, der ja im Grunde nur die extremste Form von Anforderungsänderung darstellt: Gar keine Anforderungen mehr.

Drei Dimensionen der Agilität


In diesem Sinne ist Agilität also eine Eigenschaft von Projekten. Oder genauer: Das Potenzial von Projekten, auf Anforderungsänderungen zu reagieren. Und ich schlage vor, dieses Potenzial anhand von drei Dimensionen zu messen:
  • der Reaktionszeit, die verstreicht, bis die Änderung in Angriff genommen werden kann, 
  • des Aufwands, der betrieben werden muss, um die Änderung in Angriff nehmen zu können
  • des Werts an bisheriger Projektarbeit, der trotz Änderung erhalten bleibt (und des Aufwands, der für diesen Erhalt geleistet werden muss).
Ich behaupte nicht, dass das der Weisheit letzter Schluss ist, ganz im Gegenteil: das soll nichts weiter sein, als ein erster Wurf, dessen konkrete Ausgestaltung noch sehr offen ist. Davon abgesehen sind mir zwei Aspekte jedoch ausgesprochen wichtig.

Der erste ist: Ich bin davon überzeugt, dass diese Verwendung von „agil“ einen intuitiven Kern hat. Es ist kein unverständlicher, verkopfter, rein akademischer Begriff. Wäre es denkbar, dass die agile Bewegung so heißt, weil sie auf Agilität in diesem Sinne abzielte? [3]

Der zweite: Ich glaube, dass dieser Begriff auch nützlich ist. So können Projekte nun hinsichtlich ihrer Agilität auf Skalen eingeordnet und miteinander verglichen werden. Die Aussage, ein Projekt a sei agiler als ein Projekt b, kann mit Sinn gefüllt und vielleicht sogar quantifiziert werden.

Ein Beispiel: Nehmen wir an, in Projekt a wird in zeitlich festgelegten Iterationen gearbeitet, die unbedingt zu Ende zu führen sind, bevor neue Aufgaben begonnen werden dürfen; in Projekt b gibt es die Möglichkeit, für besonders wichtige Aufgaben (nennen wir sie „Silver Bullets“) die Bearbeitung anderer Aufgaben zu unterbrechen. Die Aussage, dass Projekt b (im Hinblick auf die Reaktionszeit) agiler ist als Projekt a, ist hoffentlich eine verständliche Aussage. [4]

Einen weiteren Nutzen sehe ich in der Möglichkeit, die Auswirkungen organisatorischer und technischer Maßnahmen auf die Agilität eines Projekts zu den vorgeschlagenen Dimensionen in Beziehung zu setzen. Vorgehensweisen wie kontinuierliche Integration oder testgetriebene Entwicklung stehen z.B. in einem offenkundigen Zusammenhang zur Werterhaltung und zum Änderungsaufwand. Ein Beispiel für die Dimension „Reaktionszeit“ habe ich ja gerade erst gegeben. Ob die Nutzenerwartung bezüglich der Projektagilität auch gerechtfertigt ist, muss sich natürlich auch in der Praxis erweisen, aber der Zusammenhang ist häufig ähnlich offensichtlich wie der zwischen Brandschutz und dem Bereitstellen von Feuerlöschern.

Beispiel: Hohe Agilität erfordert, dass Änderungen kurzfristig eingebracht werden können (Dimension: Reaktionszeit). Die etablierten agilen Vorgehensmodelle haben dafür natürlich Vorsehungen getroffen - bei Kanban kann z.B. ein freier Aufgabenslot im Idealfall just-in-time mit einer neuen Aufgabe belegt werden. So gesehen ist die Erklärung, warum Projekte, die im historischen Sinne agil sind, auch im intuitiven Sinne agil sind, häufig trivial. Und das war ja auch zu erwarten.

Die agilen Seiten "klassischer" Projekte


Aber, und das ist der dritte Nutzen, Agilität ist nun eine Eigenschaft, die auch solchen Projekten in entsprechendem Maße zukommt, die nicht per se im Verdacht stehen, einer historischen Agilitätsdefinition zu entsprechen. Denn auch in „klassischen“ Projekten gibt es etliche Möglichkeiten, qualitätssichernde und risikoverringernde Maßnahmen zu ergreifen, die sich positiv auf den Werterhaltungs- und Änderungsaufwand auswirken. Dazu zählen Maßnahmen wie die schon erwähnten Beispiele „kontinuierliche Integration“ und „testgetriebene Entwicklung“ und weitere, die zwar historisch mit der agilen Bewegung assoziiert sind, aber eigentlich völlig unabhängig vom Entwicklungsumfeld zum Handwerkszeug eines jeden Software-Ingenieurs mit Anspruch gehören sollten. [5] Schon simple Maßnahmen wie der verständige Einsatz eines Versionskontrollsystems oder eines Coding Styleguides verbessern nachhaltig die Agilität eines Projekts!

Schlussgedanken


Historisch bedingt gibt es eine Frontstellung „agile Entwicklung“ versus „klassische Entwicklung“. Das ist eine Folge davon, dass die agile Bewegung als Gegenbewegung zu einem status quo entstanden ist. Die Überprüfung, ob „agil“ besser ist, als „klassisch“, setzt eine Definition von „agil“ voraus. Der Wesenskern von „agil“ ist jedoch zu wenig fassbar. Eine Definition muss also bei den konkreten, historisch etablierten Vorgehensweisen ansetzen.

Doch ist eine ideologische Frontstellung überhaupt noch wünschenswert oder sinnvoll? Ist es nicht besser, von einer Aufgabenstellung auszugehen und frei von historischem Ballast Lösungen zu ersinnen und einzusetzen, die diese Aufgabe direkt angehen? Dazu benötigt man eine ebenfalls eine Definition, aber keine, die von Methoden ausgeht, sondern eine, die vom Gegenstand ausgeht. Und wenn der Gegenstand die Agilität des Entwicklungsprozesses ist, so liegt es nahe, von einem intuitiven Agilitätsbegriff auszugehen und ihn zu konkretisieren. Dann kann man ganz unideologisch herausfinden, was funktioniert und was nicht. Und sich für die beste (passendste, preiswerteste, nachhaltigste, ...) Lösung entscheiden.

Feedback!


Du siehst das genauso? Oder komplett anders? Super! Ich freue mich auf dein Feedback!

Fußnoten 


[1] Im Folgenden wird der Einfachheit halber auf Projekte abgehoben, doch sollte die Übertragung des Geschriebenen auf nicht-projektbezogene Entwicklungsarbeit (Pflege, Wartung, Weiterentwicklung) problemlos möglich sein.

[2] Nur um ganz sicher zu gehen: Hier ist nicht der Aufwand gemeint, den die Umsetzung der Änderung als solche hervorruft, sondern der Aufwand, der dadurch entsteht, dass diese Änderung zuvor nicht bekannt und eingeplant war und nun in den Projektablauf und die technischen Bedingungen eingepasst werden muss. Das kann zum Beispiel eine Neuplanung des restlichen Projekts nach sich ziehen oder das Verwerfen von bereits geschriebenem Code.

[3] Unbenommen bleibt, dass sie möglicherweise weitere Ziele hat, die über Agilität in diesem Sinne hinausgehen. Nachtrag, 14.10.2015: Zahlreiches Feedback hat mir inzwischen vor Augen geführt, dass ich hier noch nicht klar genug abgegrenzt habe: Dieser Begriff von Agilität (Änderungsfähigkeit) bezieht sich auf eine eindimensionale Eigenschaft von Projekten oder Entwicklungsvorgängen. Er ist kein Wert und kein Prinzip und völlig ideologiefrei und stellt insofern keine alternative Definition der Wertbasis der agilen Bewegung dar. Die Verbindung ist folgende: Die Bewegung will mit ihren Werten und Prinzipien dafür sorgen, dass Projekte wieder stärker diese Eigenschaft der Agilität (Änderungsfähigkeit) besitzen. 

[4] Davon unbenommen bleibt selbstverständlich, dass es wahrscheinlich gute Gründe gibt, weshalb man in Projekt a Iterationen nicht unterbricht. Womöglich hat dies auf einer anderen Dimension sogar seinerseits Vorteile hinsichtlich der Agilität (Stichwort „Wertsicherung“).

[5] Zu Ralf Westphals Definition von Agilität gehören sie jedenfalls nicht.

1 Kommentar:

  1. Der Artikel hat mich zum Nachdenken angeregt. Das Ergebnis in Kürze: Ja, wir brauchen Messgrößen für Agilität. Aber die hier vorgeschlagenen drei scheinen mir zu sehr fokussiert auf nur einen Aspekt dessen, was Agilität will.

    Wer mehr erfahren will, findet meine Ausführungen hier: http://blog.ralfw.de/2015/09/vorschlage-zur-messung-von-agilitat_9.html

    AntwortenLöschen