Das Agile Manifest unter der Lupe

Dass Softwareprojekte und Produktteams nicht so vorankommen, wie sie möchten, treibt mich immer wieder um. Woran liegt das? Sogar dort, wo man versucht, Agilität zu leben, ist der Frust nicht klein. Dort gesellt sich sogar noch eine Überraschung dazu: „Nun versuchen wir es mit Agilität und trotzdem hakt es noch gewaltig.“ Ja, wie kann das denn sein?

Die Gründe sind sicherlich vielfältig. Vor allem glaube ich aber, dass Cargo-Kult der einen oder anderen Art ein Problem darstellt. Ja, selbst wenn alle Rollen von Scrum ordentlich besetzt sind und alle Scrum Organe „nach dem Buch“ arbeiten, kann es sich noch um Cargo-Kult handeln.

Cargo-Kult liegt ja immer dann vor, wenn man etwas unvollständig kopiert, was anderen Erfolg beschert hat. Ein Daily Standup kann genauso lächerlich sein wie ein geschnitzter Kopfhörer. Ein Sprint Backlog kann am Ende einer Iteration genauso zu Frust führen wie ein Tower im Dschungel.

Jedes Mittel braucht einfach einen Kontext und eine Qualität und eine Kompetenz, damit es zu einem erwünschten Ergebnis führt. Das macht es so schwer, Rezepte zu formulieren, die jenseits des ursprünglichen Erfolges funktionieren.

„Gelingt garantiert!“ gibt es nur bei Tütensuppen. Wenn es um die Softwareentwicklung oder Organisationsentwicklung geht, dann sollte man dieses Versprechen aus keinem Ansatz herauslesen.

Umso geringer muss das Gelingensversprechen auch sein, je konkreter das Mittel ist, um das es geht.

Scrum ist da schon ein sehr konkretes „Rezeptbuch“. Es werden sehr detaillierte Mittel beschrieben, die man einsetzen soll, damit die Softwareentwicklung gelingt.

Und auch das Agile Manifest enthält vor allem Mittel, um eine bessere Softwareentwicklung zu erreichen. Der Zweck hinter der Agilität wird lediglich so beschrieben:

Our highest priority is to satisfy the customer [with] valuable software.

Dass sich Agilität dadurch schon von anderen Ansätzen unterscheidet, kann man nicht sagen, oder? Zwischen Mitteln und Zweck klafft also eine Begründungslücke. Warum die empfohlenen Mittel für diesen Zweck? Was macht den Unterschied zwischen Agilität und anderen Ansätzen aus?

Angesichts des Frustes, den ich weithin auch in agilem Vorgehen sehe, glaube ich, dass es sich immer noch und wieder lohnt nachzubohren und zu hinterfragen. Seien wir nicht zufrieden mit vier hübschen Werten und einer populären Methode wie Scrum. Agilität ist trotz oder wegen ihrer Popularität nicht das Ende. Auch Agilität unterliegt einem Lebenszyklus und darf, nein, muss auf den Prüfstand.

Also: Was soll das Ganze? Und wie kann Softwareentwicklung noch besser werden?

Der Anspruch der Agilität

In einem früheren Blogartikel habe ich aus dem Agilen Manifest einen Anspruch herausdestilliert, den die Agilität aus meiner Sicht formuliert. Für mich lautet er ganz bewusst ohne Komma geschrieben so:

Agile Softwareentwicklung ist nachhaltig reaktionsfreudig qualitätsorientiert.

Damit hebt die Agilität sich von dem, was vorher war und sonst ist, in zweierlei Hinsicht ab:

• Agile Softwareentwicklung versteht, dass Veränderungen in Aspekten des Problems wie auch der Mittel und Ressourcen zu seiner Lösung die Norm sind.
• Agile Softwareentwicklung versteht, dass die Fähigkeit zur Reaktion auf Veränderungen nicht selbstverständlich ist, sondern bewusst hergestellt und erhalten werden muss.

Auch ohne Agilität ist Softwareentwicklung sicher qualitätsorientiert in dem Rahmen, was man als Qualität ansieht. Die Agilität erweitert diesen Rahmen jedoch. Sie fügt ihm die Dimension der dauerhaften Reaktionsfreudigkeit hinzu. Sie behauptet: Softwareentwicklung produziert nicht nur hohe Qualität, wenn sie Software herstellt, die gewünschte Funktionalität und Effizienz aufweist, sondern sie muss darüber hinaus dafür sorgen, ihre eigene Produktivität auch im Angesicht von Unvorhergesehenem stets hoch zu halten.

Das macht Agilität so anders. Das macht Agilität auch so schwierig in der Implementation. Denn erstens ist Veränderungsbereitschaft und Veränderungsfähigkeit nicht das, was Unternehmen im Allgemeinen auszeichnet. Und zweitens ist es schwer, dafür ein „Gelingt garantiert!“-Rezept zu formulieren.

Um Agilität zu implementieren, muss nicht einfach nur in einer Organisation etwas anders gemacht werden, sondern an einer Organisation. Das ist umso mehr ein Problem, je mehr Unternehmen auf Effizienz in der Produktion gepolt sind.

Gut gemeinte Rezeptvorschläge sind angesichts dessen nicht falsch - nur darf man sie nicht falsch verstehen. Je konkreter sie sind, desto weniger Allgemeingültigkeit haben sie tendenziell. Und je weniger Kontextbewusstheit sie zeigen, desto vorsichtiger muss man sie genießen. Insofern: Rezeptvorschläge als Ausgangspunkte für Experimente sind eine gute Sache. Wer jedoch erwartet, sich durch ihr Ausrollen geradlinig in die Agilität zu bewegen, hat die Agilität im Kern missverstanden.

Die Unvorhersehbarkeit lauert überall, nicht nur in der Softwareentwicklung für einen Kunden, sondern auch in der Veränderung hin zu einer anderen Art der Softwareentwicklung. Insofern ist Agilität im Grunde eine Meta-Kompetenz und es mutet wie ein Paradoxon an: Um agil zu werden, muss man schon agil sein ;-)

Aber vielleicht lässt sich aus dem Agilen Manifest doch noch etwas Hilfreiches herausziehen, um den Übergang zu erleichtern. Scrum ist eine Interpretation der Werte und Prinzipien. Ist es jedoch die einzig mögliche Interpretation? Manchmal scheint es mir so, als würde die Softwarebranche das denken.

Ich erlaube mir allerdings, anderer Meinung zu sein. Ich lese aus dem Agilen Manifest kein Daily Standup und kein Sprint Planning und auch keinen Sprint heraus. Nur in drei Prinzipien wird das Agile Manifest konkret und spricht organisatorische Empfehlungen aus:

• Teams sollen selbstorganisiert sein,
• es soll periodisch im Team reflektiert werden und
• es soll möglichst weitgehend face-to-face kommuniziert werden.

Genau genommen sind Selbstorganisation und face-to-face Kommunikation zwar mit keinem „soll“ versehen, doch die Argumente dafür sind so deutlich beigeordnet, dass ich mich dem Gefühl einer Vorgabe nicht entziehen kann.

Ist es aber gut so, dass das Agile Manifest in dieser Weise konkret ist? Ich glaube, nicht. Lediglich die Reflexion passt zum Anspruch. Sie ist für die Nachhaltigkeit Voraussetzung. Ohne Reflexion keine Anpassung an Veränderungen, keine Optimierung.

Face-to-face Kommunikation jedoch und sogar Selbstorganisation empfinde ich als zu viel. Ich kann nachvollziehen, warum das Agile Manifest das nahelegt, doch für meinen Geschmack schießt es damit über sein Ziel hinaus.

Damit will ich nicht sagen, ich würde Selbstorganisation oder face-to-face Kommunikation nicht schätzen. Beides ist wundervoll am rechten Ort und zur rechten Zeit - nur ist es eben doch auch nur ein Mittel und nicht an sich wertvoll.

Das Konkrete finde ich also im Agilen Manifest noch nicht so hilfreich. Die Hilfe liegt für mich eher „in der Tiefe“. Dafür ist mehr Hinterfragen nötig.

So will ich denn das Offensichtliche näher betrachten. Es scheint so klar, was das Agile Manifest meint - aber ist es das wirklich? Vielleicht liegt darin die größte Gefahr, in einen Cargo-Kult zu rutschen, dass wir glauben, es läge auf der Hand, was gemeint war und was das heute bedeutet.

Hinter dem Offensichtlichen

Das Offensichtliche sind für mich die vier Werte:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Außerdem hervorgehoben in den Werten sind zwei Begriffe, die durch ihre wiederholte Nennung in den Prinzipien aus meiner Sicht besonderes Gewicht bekommen.

Wenn ich dieses Offensichtliche nun auf mich wirken lasse, dann sehe ich zwei Spannungsfelder. In denen hat sich zu Zeiten der Unterzeichnung des Manifests die Softwareentwicklung befunden, in denen befindet sie sich heute noch. Zu diesen Spannungsfeldern hat sich die Agilität positionieren wollen.

Das erste Spannungsfeld ist das zwischen Kunde und softwareentwickelnder Organisation. Das zweite Spannungsfeld ist das zwischen Realität und Wunsch.

Die Organisation möchte mit Software möglichst viel Geld verdienen, der Kunde möchte wenig ausgeben. Bei schließlich gegebenem Preis, der von Scope und Markt abhängt, versucht die Organisation selbstredend, intern möglichst effizient zu sein. Das soll erreicht werden durch Minimierung von Flexibilität, denn die kostet Geld. Als Mittel zur Effizienzsteigerung dienen „processes and tools“, „contracts“ und „plans“.

Je stärker die Organisation sich nun um Effizienz bemüht, desto größer wird die Distanz zwischen Wunsch und Realität. Der Wunsch, der nämlich aus dem Effizienzbemühen resultiert, ist der nach Klarheit und Unveränderlichkeit der Anforderungen. Die Organisation will effizient auf ein abgezirkeltes Scope-Ziel hin arbeiten. Der Kunde will das auch, denn nur so bekommt er einen geringen und fixen Preis. Doch die Realität ist schlicht eine andere:

• die Anforderungen sind selbst dem Kunden nur unvollständig bekannt
• der Kunde kann die ihm bekannten Anforderungen nur unvollständig formulieren
• die Organisation versteht die formulierten Anforderungen nur unvollständig
• die verstandenen Anforderungen werden nur unvollständig umgesetzt
• die umgesetzten Anforderungen entsprechen nur unvollständig den tatsächlichen Anforderungen zum Lieferzeitpunkt

Anforderungen sind unklar und entwickeln sich während der Umsetzungszeit. Anforderungen und Software stehen in einem co-evolutionären Verhältnis. Dass es also Anforderungen gäbe, auf die hin man Prozess, Werkzeug, Vertrag, Plan optimieren könnte, ist in der Softwareentwicklung eine sehr teure und frustrierende Illusion.

Deshalb favorisieren die Werte des agilen Manifests etwas anderes. Der Fokus soll von einer Optimierung für einen fixen Scope auf die Optimierung für einen sich wandelnden Scope verschoben werden. Softwareentwicklung findet nicht auf einem Betonfundament statt, sondern auf hoher See.

Das zum Schlagwort „change“. Die Organisation muss unter ständigen Veränderungen liefern. Und was soll sie liefern? „Working software“ sagt das Agile Manifest.

Doch was ist working Software? Reicht es, das mit laufender Software zu übersetzen? Reicht es, Funktionalität und Effizienz (z.B. Performance, Usability, Security) zu liefern?

Ich glaube, hier ist die Agilität missverstanden worden und/oder hat es selbst nicht besser gewusst.

Zu einem „laufenden“ Auto gehört, dass das Auto gelenkt und beschleunigt werden kann und der Fahrerin Schutz bietet. Doch wenn das Auto einen bei Lieferung gefüllten Tank besitzt, den man jedoch nicht nachfüllen kann, dann fehlt etwas. Es braucht also selbst beim Auto eine Möglichkeit, Veränderungen vornehmen zu können, um es bei grundsätzlich vorhandener „Lauffähigkeit“ nützlich zu halten. Ein Kunde würde ein Auto ohne Tankstutzen nicht working car nennen.

Bei der Software ist es genauso. Eine Software, die rechnet und performant ist, reicht nicht aus. Wenn die Software keine Veränderungen z.B. in der gespeicherten Datenmenge oder der Last ausgleichen kann, wird ein Kunde sie kaum als working software erachten.

Doch nicht nur das! Entscheidend und besonders ist, dass Software über diese Laufzeiteigenschaften hinaus noch etwas braucht. Software braucht die Offenheit für Veränderungen an sich selbst. Wandelbarkeit ist eine zentrale Anforderungen, wenn Softwareentwicklung nachhaltig sein soll. Ohne Wandelbarkeit keine dauerhaft hohe Produktivität der entwickelnden Organisation.

Working software im Sinne der Agilität muss also über Laufzeiteigenschaften hinaus Bedeutung haben. Working software ist gekoppelt an die Fähigkeit zu responding to change. Und diese Fähigkeit wiederum hat nicht nur mit der Organisation zu tun, sondern auch ganz wesentlich mit den Artefakten der Softwareentwicklung.

Working software wird deshalb aus meiner Sicht üblicherweise viel zu eng ausgelegt. Der Fokus liegt selbst in so genannten agilen Teams meistens zu sehr auf dem Laufzeitverhalten von Software; daran zieht in Scrum ja sogar eine eigene Rolle, der Product Owner. Hauptsache Funktionalität und Effizienz sind am Ende einer Iteration nah am Wunsch des Kunden. Alles andere hat keinen direkt und unmittelbar fühlbaren Wert - und ist deshalb optional.

Das Ergebnis sind Codebasen, die selbst in vielen agilen Teams alsbald als legacy code oder brownfield bezeichnet werden müssen. Nicht umsonst hat sich auch Robert C. Martin sieben Jahre nach dem Agilen Manifest bemüßigt gefühlt, sein Buch „Clean Code“ zu schreiben. Sogar ihm als Unterzeichner des Manifests hat etwas gefehlt; etwas war durch das Manifest noch nicht klar genug geworden, obwohl XP und Scrum als übersetzende Methoden schon im Schwange waren.

Dass die Agilität sich auf working software unter ständiger Änderung der Anforderungen konzentriert, ist sinnig. Mit working software jedoch vor allem lauffähige, deploybare Software gleichzusetzen, ist unsinnig.

Ich denke daher, der Begriff sollte ersetzt werden z.B. durch valuable software. Denn wofür sollte der Kunde zahlen wollen, wenn es nicht Wert für ihn in irgendeiner Weise hat? Nur ist eben mehr und anderes wertvoll, als üblicherweise gedacht.

Ich versuche es also nochmal mit einer kleinen Definition von Agilität:

Agile Softwareentwicklung ist darauf bedacht, wertvolle Software in nachhaltiger Weise zu liefern.

Wertfülle bezieht sich hier nicht nur auf den Anteil von Software, der Funktionalität und Effizienz herstellt. Software ist umfassender zu sehen als die Summe aller Artefakte, zu denen z.B. auch CI-Skripte oder Entwurfsdokumente oder Kommentare zählen.

Nachhaltigkeit bezieht sich darauf, dass Fortschritte bei der Herstellung von Wert heute nicht fahrlässig auf Kosten von Fortschritten morgen erzielt werden dürfen - vor allem eingedenk der Tatsache, dass das, was morgen Anforderung ist, heute noch gar nicht (vollständig) bekannt ist.

Agil kann sich Softwareentwicklung deshalb nur nennen, wenn sie darauf bedacht ist, ihre zukünftige Produktivität nicht durch gegenwärtiges Handeln zu kompromittieren.

Es folgt für mich daraus, dass working software deutlich mehr ist als lauffähige Software. Es geht umfassend um valuable software.

Außerdem folgt für mich daraus, dass in Bezug auf die Wertherstellung jeder Versuch der Kontrolle fehl am Platze ist. Damit meine ich, dass nicht kontrolliert werden sollte oder auch nur kann, wie viel Wert hergestellt wird, sondern nur, dass kontinuierlich mehr Wert hergestellt wird, dass also stets Fortschritt gemacht wird.

Agilität bedeutet Loslassen

Ich kann es auch noch radikaler und provokanter formulieren: Die bisherigen Versuche, Software agil zu entwickeln, greifen nach meinem Empfinden viel zu kurz. Sie stellen lediglich eine Fortführung des Vorherigen mit veränderten Mitteln dar.

Das mache ich nicht nur am primären oder gar einzigen Maßstab Softwareverhalten (bestehend aus Funktionalität+Effizienz) fest. Viel deutlicher ist es abzulesen an dem immer noch regierenden Lieferversprechen: Es wird ein vorher festgelegter Umfang an Wert mit einem vorher festgelegten Budget hergestellt.

Ob der Wert groß oder klein ist oder das Budget groß oder klein, das ist egal. Ob man verspricht, eine komplette Software in 3 Jahren mit 10 Personen zu realisieren, oder nur verspricht, 5 User Stories in 5 Tagen mit 4 Personen zu realisieren, das ist egal. Selbst meine Idee vom Spinning ist noch diesem Denken verhaftet: ob man verspricht, nur ein kleines Inkrement im Pair „bis morgen“ zu realisieren, ist auch egal. Das uralte Muster ist in der agilen Praxis nicht konsequent durchbrochen. Es wird immer noch versucht, auf ein fixes Ziel hin effizient zu leisten.

Das halte ich für hochgradig unagil. Es widerspricht der zentralen Erkenntnis, die am Anfang der Agilitätsbewegung stand. Dass nämlich die auf Effizienz getrimmten Organisationsstrukturen und Verhaltensmuster nicht zur Natur der Sache passen, mit der sie sich befassen. Die ist geprägt von Volatilität, Unklarheit und Komplexität. Das, was in der Softwareentwicklung hergestellt werden soll, hat wenig gemein mit dem, was bis dahin von Menschen hergestellt wurde.

Software ist keine Maschine. Sie ist eine Technologie, ein Hilfsmittel, aber keine Maschine, wie ein Wasserkocher, ein Auto oder sogar ein Atomkraftwerk Maschinen sind. Deshalb kann es nur zu schmerzhaften Konflikten kommen, solange man versucht, Software wie Maschinen herzustellen. Die Konflikte entstehen zwischen der Softwareentwicklung und dem Kunden, wenn man wieder knapp daneben liefert, also das Budget nicht eingehalten wird und/oder der Wert nicht so hoch ist, wie erwartet. Die entstehen zwischen den Softwareentwicklern und dem Code, wenn der sich nicht so leicht an neue Vorstellungen von Wert im Rahmen des dafür vereinbarten Budgets anpassen lässt.

Im Agilen Manifest ist nirgendwo zu finden, dass ein festgelegter Wert mit einem festgelegten Budget produziert werden muss. Zwar glaube ich eher, dass das eine unausgesprochene Prämisse war, die der Erwähnung nicht lohnte. Doch ein bisschen Hoffnung habe ich andererseits auch, dass man geahnt hat, dass darin ein fundamentales Problem liegt und intuitiv davon abstand genommen hat, sich in der Hinsicht festzulegen - um offen zu bleibe für einen anderen Ansatz.

Leider wurde dieser Freiheitsgrad bisher jedoch nicht wirklich genutzt. Auch hinter Kanban steckt noch der Gedanke, man müsse zuerst wissen, wie viel Aufwand eine User Story erfordert, bevor man sie ans Brett hängt. Denn Fluss entsteht nach Kanban vor allem, wenn die Variation in den Aufwänden für User Stories gering ist. Diese Beurteilung erfordert jedoch eine Abschätzung des nötigen Zeitbudgets, um User-Story-Wert herzustellen.

„Wert gegen Budget“ wird vom Agilen Manifest nicht gefordert und widerspricht aus meiner Sicht dem Dreh- und Angelpunkt der Agilität.

Kontinuierliche Wertsteigerung hingegen ist von einem Budget völlig unabhängig. Working software – oder besser: valuable software – lässt sich im Angesicht unvorhersehbarer Entwicklung von Anforderungen stets liefern.

Wenn ich das Agile Manifest unter die Lupe nehmen, finde ich darin also eine unausgesprochene, deshalb jedoch nicht weniger wichtige und radikale Botschaft: Es geht ums Loslassen.

Die Softwareentwicklung, der gegenüber die Agilität einen Kontrast beschreiben wollte, war (und ist) geprägt vom Festhalten. Standards halten fest, Dokumentationen, Verträge und ausgefeilte Pläne halten fest. Die Welt soll so sein bzw. werden, wie man es sich einmal gedacht hat. Festzurren, angurten, aufgleisen. Dann wird das fixierte Ziel geradlinig erreicht.

Doch darüber lacht das Schicksal! Die Realität auch der simpelsten Softwareentwicklung sieht anders aus.

In anderen Lebensbereichen haben wir damit umgehen gelernt. Nur die Softwareentwicklung widersetzt sich dem. Immer noch. Und das obwohl die Erkenntnis eigentlich da ist, dass es so nicht geht bzw. nur mit viel, viel Verschwendung.

Wir können uns viele Gedanken über Mittel machen, die uns helfen, agil zu sein. Eine aktuelle Liste habe ich im neuen Buch „Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy“ von Jutta Eckstein gefunden:

• self-organization
• transparency
• constant customer focus
• continuous learning

Damit kann ich etwas anfangen. Vielleicht stimme ich sogar damit überein. Doch ist das wichtig?

Wichtig ist, erstens klar zu haben, was mit Agilität erreicht werden soll in der Softwareentwicklung. Ich wiederhole es noch einmal aus meinem Blickwinkel:

Wertvolle Software in nachhaltiger Weise liefern.

Und zweitens muss der fundamentale Modus klar sein, in dem solche Lieferung nur stattfinden kann. Für mich ist das dieser:

Produktion eines stetigen Stroms von zielführenden Artefaktänderungen ohne Budgetvorgabe.

Wenn das besser mit einem Daily Standup oder in Selbstorganisation machbar ist, kein Problem. Nur muss letztlich jedes gewählte Mittel belegen, dass und inwiefern es dem dient. Sonst entsteht (wieder) Cargo-Kult.

Aber ich ahne schon, dass meine Formulierung des agilen Modus geeignet ist, Missverständnisse und Widerstand hervorzurufen. Deshalb werde ich in einem weiteren Artikel „zielführende Artefaktänderung“ und „ohne Budgetvorgabe“ erklären müssen.

Einstweilen aber fände ich es andererseits gar nicht schlecht, sollte die Formulierung als Provokation das Denken anregen. Das brauchen wir: mehr Mut zum selber denken, zum Hinterfragen. Das habe ich hier versucht. Ich habe das Offensichtliche unter die Lupe genommen, um dahinter zu schauen. Um was geht es wirklich? Denn: Das hohle Ritual mit frustrierendem Ergebnis ist eine ständige, verschwenderische Bedrohung. Dagegen hilft nur besseres Verständnis dessen, was vorgedacht und empfohlen wurde. Und dann darüber hinaus gehen.