Die Zerstörung der Agilität

Bevor ich mit dem eigentlichen Thema starte, muss ich kurz etwas abschweifen. Ich bin nämlich begeistert und etwas aufgeregt. Ich habe das folgende Manifest für die leckere Küche unterzeichnet.

Bereits im Jahr 2014 hat sich Meyer kritisch mit der Agilität in der Softwaretechnik auseinandergesetzt [6]. Leider hat sein Werk keine ausreichende Beachtung gefunden. Anders lässt sich die weitere unreflektierte Nutzung des Begriffs agil nicht erklären.

Der Duden sagt, dass der Begriff agil einen lateinischen Ursprung hat und für flink, wendig und beweglich steht. Der Begriff agil ist also durchgängig mit positiven Assoziationen verknüpft (oder möchten Sie lieber als behäbig, schwerfällig oder unbeweglich bezeichnet werden?). Damit ist dieser Begriff kein sonderlich guter Kandidat, um als Basis einer sachlichen/neutralen Definition zu dienen.

Im Umfeld des Begriffs agil findet man viele Bezüge zum Agilen Manifest [10]. Das Manifest wurde im Jahr 2001 von einer Gruppe von Personen formuliert, die sich Gedanken zu Softwareentwicklungsprozessen gemacht haben. Im Folgenden ist das Agile Manifest wiedergegeben, wie man es unter der Onlinequelle findet [10]. Die konzeptionelle Ähnlichkeit des Manifests für die leckere Küche mit dem Agilen Manifest ist natürlich kein Zufall.

Zum agilen Manifest wurden auch Prinzipien vorgeschlagen, die ein agiles Vorgehen unterstützen und wahrscheinlich auch konkretisieren sollen [2]. Von Meyer werden (agile) Prinzipien ebenfalls diskutiert. Meyer hat allerdings eine freundliche Vorauswahl und Strukturierungen der Prinzipien getroffen.

Im Folgenden wird betrachtet, ob mithilfe der Prinzipien ein gegebener Softwareentwicklungsprozess als agil identifiziert werden kann oder ob sich aus den Prinzipien sogar ein agiler Prozess ableiten lässt.

Dabei wurden die deutschen Übersetzungen der Prinzipien aus [7] entnommen. Das erste Prinzip lautet:

Die Formulierungen legen den Schwerpunkt auf ein fiktives Arbeitsergebnis. Wie diese wünschenswerten Arbeitsergebnisse erreicht werden können, wird nicht beschrieben. Eine hohe Priorität zu setzen reicht nicht aus. Hochwertige Software entsteht nicht, nur weil man es will. Es müssen auch entsprechende Maßnahmen ergriffen werden [3, 4, 8].

Dem Autor ist kein Prozessmodell bekannt, welches die Unzufriedenheit des Kunden, oder eine schlechte Qualität fordert. Ist ein Prozess genau dann agil, wenn hochwertige Software erstellt wird und der Kunde zufrieden ist? Diese Definition wäre im besten Fall eine selbsterfüllende Prophezeiung. Der Wunsch nach einer kontinuierlichen Lieferung weist zumindest auf die Nutzung eines inkrementellen Vorgehens hin. Ein inkrementelles bzw. evolutionäres Vorgehen ist aber vom Ursprung nicht mit dem Begriff agil verknüpft [6].

Die nächsten beiden Prinzipien beziehen sich auf funktionierende Arbeitsversionen bzw. funktionierende Software.

Die Regelmäßigkeit der Auslieferung deutet wieder auf einen inkrementellen Entwicklungsprozess hin. In der Praxis spricht viel für die Nutzung von inkrementellen Prozessen [1]. Es bleibt aber wieder offen, wie diese funktionierenden Arbeitsversionen überhaupt erreicht werden können. Eine funktionierende Arbeitsversion wäre auch noch genauer zu definieren. Reicht eine fehlerfreie Übersetzung durch den Compiler aus? Sind gewisse Qualitätskriterien zu erfüllen oder muss sie gar vom Anwender genutzt werden können? Umschließt die Nutzung gar einen produktiven Einsatz? Ist diese Forderung überhaupt immer zu erfüllen? Der Integrationsprozess, welcher der Auslieferung einer funktionierenden Arbeitsversion vorausgeht, hat eine nicht geringe Komplexität und erfordert eine gewisse Planung [9]. Diese für die Praxis wichtigen Aspekte werden in den Prinzipien nicht adressiert. Es soll nur schnell gehen. Ist ein Prozess agil, sobald man schnell ist und funktionierende Arbeitsversionen hat? Dann wäre die Agilität nicht Ursache eines erfolgreichen Prozesses, sondern würde einen solchen Prozess nur bezeichnen.

Software ist mehr als nur das ausführbare Programm. Zur Software gehören z. B. auch Benutzerhandbücher, Installationsanweisungen, Produktbeschreibungen, Betriebskonzepte, Onlinehilfen [1]. Was ist in diesem Kontext unter funktionierender Software zu verstehen? Wahrscheinlich ist gemeint, das ausführbare Programm als primären Maßstab des Fortschrittes zu verwenden. Auch der Prozess und das Projekt erfordern Maßnahmen und die Erstellung von Artefakten. Das Prinzip deutet darauf hin, dass man in der Vielfalt von erforderlichen Arbeitsergebnissen nicht den Fokus verlieren soll. Dies kann ein plausibler Ratschlag sein. Auf der anderen Seite scheint es kein Prozessmodell zu geben, welches den Fortschritt allein auf Grundlage der ausgefüllten Formulare bewertet. Und es gibt Situationen, in denen ein Programm ohne Benutzerhandbuch und Betriebskonzept nicht in Betrieb genommen werden kann. Dieses Prinzip grenzt daher agile Prozesse nicht ausreichend ab.

Die Frage, mit welchen Maßnahmen jegliche denkbare Änderung in einen Wettbewerbsvorteil gewandelt werden können, bleibt unbeantwortet. In dieser Allgemeinheit kann kein Prozess dieses Versprechen einlösen. Die Berücksichtigung von Änderungen deutet auf einen evolutionären Entwicklungsprozess hin. Diese existieren aber auch unabhängig von agilen Bestrebungen. Das obige (agile) Prinzip dient nur dazu, den Begriff agil mit positiven Assoziationen zu verknüpfen. Für eine Definition von agilen Prozessen ist es damit wertlos.

Wahrscheinlich handelt es sich bei den Geschäftsleuten um Vertreter des Auftraggebers. Dies ist ein Prinzip, welches kein positives Arbeitsergebnis vorwegnimmt. Es ist noch ausreichend konkret, es reicht aber wohl nicht aus, um die spezifischen Eigenschaften eines agilen Prozesses zu definieren. In [6] findet noch eine detaillierte Diskussion statt. Diese stellt vor allem heraus, dass es nicht den einen Kunden gibt, sondern eine Reihe von Stakeholdern. Dieser Aspekt wird in der agilen Diskussion nur unzureichend abgebildet.

Das sechste Prinzip gilt sicherlich für die praktische Umsetzung jedes Prozessmodells. Wird jemand dediziert nach schlechten Mitarbeitern mit einer miesen Motivation suchen? Wie man motivierte Mitarbeiter findet und deren Motivation erhält bzw. erhöht, wird nicht beschrieben. Was ist, wenn man nur durchschnittliche Mitarbeiter mit einer eingeschränkten Motivation zur Verfügung hat? Oder reicht es einfach aus, sich agil zu fühlen, um von motivierten Experten umgeben zu sein? Natürlich hat jeder Mitarbeiter auch das Recht auf eine ehrliche und konstruktive Rückmeldung bezüglich seiner Arbeitsergebnisse. Das Vertrauen auf gute Arbeitsergebnisse sollte damit Prüfungen der Arbeitsergebnisse nicht ausschließen. Dieses Prinzip hilft auch nicht bei der Definition von agilen Prozessen.

Die Kommunikation in Projekten ist sehr vielfältig. Wie kann z. B. eine Verbindlichkeit und Nachvollziehbarkeit in der Kommunikation erreicht werden? Wie können Dritte informiert werden? Was ist mit verteilten Teams? Auf diese Aspekte wird nicht eingegangen. Stattdessen wird eine pauschale Behauptung auf Grundlage einer starken Vereinfachung getroffen. Eine Abgrenzung von Entwicklungsprozessen kann dadurch nicht erreicht werden.

Diese Aussage (Vermutung) ist ohne die Definition eines gewissen Kontextes absolut haltlos. Der Autor dieses Artikels sieht sich in der Lage, ein Team zusammenzustellen, welches das achte Prinzip widerlegt.

Auch bei diesem Prinzip ist wieder der Wunsch der Vater des Gedankens. Was ist technisch hervorragende Qualität und gutes Design? Wie kann man beides erreichen? Der Begriff agil wird ohne erkennbaren Bezug mit positiv hinterlegten Eigenschaften in Bezug gesetzt. Wenn man die für die Praxis erforderliche Operationalisierung des Qualitätsbegriffs betrachtet [8], dann erscheint dieses Prinzip von sehr naiver Natur zu sein.

Ein agiler Prozess ist noch gar nicht ausreichend definiert. Er kann aber trotzdem eine kontinuierliche Entwicklung fördern? Mit welchen Mitteln wird dies erreicht? Mit welchen Methoden kann ein beständiges Tempo erreicht werden und das auch noch endlos? Die wesentlichen Fragen bleiben unbeantwortet.

Das elfte Prinzip lässt den Autor ratlos zurück. Es besteht daher nur die Vermutung, dass auch dieses Prinzip nicht bei der Definition von agilen Prozessen weiterhilft. Meyer hat zu diesem Prinzip einen etwas besseren Zugang und kann daher eine ausführlichere Diskussion liefern [6]. Aber auch bei dieser Diskussion kann diesem Prinzip nichts Hilfreiches abgerungen werden.

Es ist nicht ungewöhnlich, dass im Team eine (regelmäßige) Kommunikation stattfindet. Eine Beratung führt aber nicht einfach zu Prozessoptimierungen. Bevor man sein Verhalten anpassen kann, muss zunächst eine Lösung gefunden werden. Können die Anpassungen auch zu einem nicht agilen Prozess führen? Ist ein Prozess bereits agil, sobald sich die Projektmitglieder regelmäßig über ihr Vorgehen austauschen? Dies würde nicht viel zu einer trennscharfen Prozessdefinition beitragen.

Die Prinzipien sind hauptsächlich eine Mischung aus allgemeinen Lebensweisheiten, Behauptungen und Wunschdenken. Es bleiben 3 Punkte, die dabei helfen können, einen agilen Prozess zu definieren.

Die Erstellung von Teilprodukten führt mittelfristig automatisch zu einer ausreichenden Fokussierung auf den Code. Ansonsten könnten keine Teilprodukte ausgeliefert werden. Daher ist der zweite Punkt im Wesentlichen im ersten Punkt enthalten. Die Auslieferung und Erprobung von Teilprodukten führen auch zu einem Kontakt mit dem Kunden, wenn auch nicht zwingend zu einem täglichen Kontakt. Bei EDV-Projekten [5] ist die Integration der Rolle des Fachbereichskoordinators eine nicht unübliche Praxis. Die obigen Punkte gelten damit für viele unterschiedliche Prozessmodelle (dieser Aspekt wird im Folgenden aufgegriffen).

Auch die Prinzipien helfen nicht, den Begriff der Agilität in der Softwareentwicklung ausreichend zu konkretisieren. Es lässt sich aber ein Argumentationsprinzip erkennen. Der Begriff agil wird immer im Zusammenhang mit positiven Zielen, Begriffen und Eigenschaften genannt (hochwertige Software, funktionierende Software, Wettbewerbsvorteil, effizient, effektiv, beste Architektur, hervorragende Qualität). Meyer hat darüber hinaus 7 weitere rhetorische Tricks (Fallen) identifiziert, die genutzt werden, um für die agile Softwareentwicklung zu werben [6]. Dies ist einer sachlichen Diskussion kaum förderlich. Der Begriff agil ist dadurch verbrannt.

Im Umfeld des Extrem Programming werden eine Reihe von Praktiken vorgeschlagen, um das Erreichen der obigen Prinzipien zu unterstützen. Diese sind von unterschiedlicher Nützlichkeit [5, 6]. Eine wichtige Frage bleibt unbeantwortet. Welche der Praktiken sind essenziell für einen agilen Prozess? Muss ein agiler Prozess alle Praktiken umsetzen (auch die von eingeschränkter Nützlichkeit) oder ist bereits eine Teilmenge ausreichend?

Es wird an dieser Stelle nicht ausgeschlossen, dass es viele Softwareentwicklungsprojekte gibt, die sich als agil bezeichnen und die sehr erfolgreich sind. Es wird hier vielmehr die nicht ausreichend reflektierte Verwendung des Begriffs agil kritisiert. Die obigen Diskussionen stützen die Vermutung, dass häufig mit einer impliziten Definition der folgenden Art gearbeitet wird:

Auf Grundlage dieser Definition und der positiven Belegung des Begriffs agil lässt sich natürlich vortrefflich argumentieren. Wissenschaftliche Untersuchungen zum Thema Agilität verbieten sich auf Basis dieser unzureichenden Definitionen. Je nach Geschmack und gewünschtem Ergebnis kann alles oder nichts als agil bezeichnet werden. Dies bringt die Softwaretechnik aber nicht voran.

Aus den obigen Gründen ist der Begriff agil im Zusammenhang mit Softwareentwicklungsprozessen ungeeignet und sollte im professionellen und akademischen Umfeld nicht weiter verwendet werden. Es ist damit nicht ausgeschlossen, dass es evtl. Berufszweige/Branchen gibt, die gerade die Beliebigkeit des Begriffs agil sehr schätzen. Für solche Begriffe scheint es einen gewissen Markt zu geben. Bei Microservice handelt es sich z. B. um einen weiteren (noch) unzureichend definierten Begriff, der sich einer gewissen Beliebtheit erfreut.

In der Arbeitswelt scheint der Begriff agil mit einer gewissen Lebensart verbunden zu sein. Zumindest deuten die Bezüge in vielen Stellenausschreibungen darauf hin. Auch ist in diesem Zusammenhang von agilen Werten die Rede. Nicht selten wird auch der Begriff Kultur verwendet. Dies sind Aspekte, die in diesem Artikel aber nicht weiter behandelt werden. Jeder Mitarbeiter hat seinen individuellen Wertekanon. Es ist fraglich, ob ein Softwareentwicklungsprozess darauf Einfluss nehmen soll/muss. Die normative Nutzung des (agilen) Kulturbegriffs scheint eher der Überhöhung des eigenen Tuns zu dienen (die Agilen machen alles richtig, die anderen machen alles falsch).

Trotz aller Kritik scheint ein Bedarf für den Begriff agil vorhanden zu sein (unabhängig von dem Lebensgefühl). Um konkreter zu werden, ist es wichtig, sich vom Agilen Manifest zu lösen. Basis der weiteren Diskussion ist die Unterscheidung zwischen Vorgehens- und Prozessmodellen, wie sie von Ludewig und Lichter vorgeschlagen wird [5].

Im Wesentlichen werden sequenzielle, inkrementelle und evolutionäre Vorgehensmodelle unterschieden [1]. Ein konkreter Prozess basiert immer auf einem Vorgehensmodell und stellt damit eine konkrete und anwendbare Ausprägung eines Vorgehensmodells dar. Die Prozessmodelle Extreme Programming (XP) und Scrum werden häufig als agil bezeichnet. Scrum nimmt dabei eigentlich eine Zwischenstellung ein. Für ein Vorgehensmodell werden bereits zu konkrete Aussagen über Rollen und Artefakte gemacht. Es handelt sich aber auch nicht um ein Prozessmodell, da keine direkten Aussagen zu Softwareentwicklungsprozessen gemacht werden. Das heißt, die eigentlich wichtige Ausgestaltung der Sprints bleibt offen. Beide Prozesse basieren auf einem evolutionären Vorgehensmodell. Das heißt, das Produkt wird schrittweise in einzelnen Inkrementen entwickelt und die Anforderungen müssen nicht vollständig erhoben werden, sondern lassen sich über die einzelnen Iterationen ergänzen. Dies ermöglicht eine gewisse Flexibilität und Beweglichkeit, die mit dem Begriff agil häufig assoziiert werden. Bei der Analyse der Prinzipien hat es mehrfach Hinweise auf ein evolutionäres Vorgehen gegeben.

Im Kern scheinen sich viele Vorteile von agilen Prozessen auf die grundlegenden Eigenschaften von evolutionären Vorgehensmodellen zurückführen zu lassen. Ich plädiere daher dafür, den Begriff der agilen Prozesse durch die evolutionären Vorgehensmodelle zu ersetzen. Evolutionäre Vorgehensmodelle sind ausreichend scharf definiert [1]. Auf der Basis eines Vorgehensmodells lassen sich unterschiedliche Prozesse definieren, die den spezifischen Anforderungen gerecht werden.

Die Angemessenheit von Prozessmodellen ist von vielen Faktoren abhängig und kann nicht pauschal bestimmt werden. Zu diesen Faktoren gehören z. B.:

In der Folge können Prozesse z. B. unterschiedlich formal sein und einen sehr unterschiedlichen Grad an Dokumentation erfordern. Dabei sind formalere Prozesse aber nicht mehr per se schlechter als unbürokratische Prozesse. Sicherlich geht das Agile Manifest nicht differenziert auf diese Punkte ein. Der Begriff agil kann eine solche ausdifferenzierte Betrachtungsweise erst recht nicht leisten.

Man kann vermuten, dass sich der Einfluss des Agilen Manifests auf die Softwarequalität nicht positiv ausgewirkt hat, gerade von den extremen Interpretationen, wie z. B. XP. Zunächst ist festzuhalten, dass die Auslieferung von Inkrementen (siehe evolutionäres Vorgehensmodell) kein Mittel der Qualitätssicherung ist, sondern dem Risikomanagement zuzuordnen ist. Warum der Verzicht auf ein explizites Qualitätsmanagement und einen angemessenen Qualitätssicherungsplan (beides erfordert Dokumentation und Prozesse) die Qualität steigern soll, ist ebenfalls nicht direkt ersichtlich. Unit-Tests und Pair-Programming bilden nur einen vergleichsweise kleinen Teil der Softwarequalitätssicherung ab [3, 4].

Die Softwaretechnik soll und muss sich weiterentwickeln. Allerdings sollte nicht jegliche Diskussion mithilfe eines unzureichend definierten Begriffs abgewürgt werden. Der Begriff agil sollte vermieden werden, um eine sachliche Diskussion zu ermöglichen und begründete Lösungen zu finden. Dabei ist es natürlich nicht ausgeschlossen, dass man nach einer sorgfältigen Analyse auch Praktiken, Methoden, Rollen und Artefakte nutzt, die lange Zeit mit dem Begriff agil verknüpft waren. An dieser Stelle sei erneut auf [6] verwiesen.