Das Agile Manifest

Kurzfassung

Das Agile Manifest (Manifesto for Agile Software Development) ist eine einseitige Erklärung von vier Werten und zwölf Prinzipien, die 17 Softwareentwickler im Februar 2001 in Snowbird, Utah, verfassten. Es beschreibt keine Methode, sondern was die Autoren aus ihrer Arbeit mit verschiedenen leichtgewichtigen Vorgehensweisen gelernt hatten: Zusammenarbeit, lauffähige Ergebnisse und Anpassung an Veränderung gehen vor Prozessen, Dokumenten, Verträgen und Plänen, ohne diese abzuschaffen.

Das Manifest ist ein Bekenntnistext, keine überprüfbare Theorie. Belege gibt es nur für einzelne Praktiken, die sich auf das Manifest berufen, etwa für kurze Lieferzyklen in Softwareprojekten. Ob die Werte selbst etwas bewirken, lässt sich kaum prüfen.

Gestritten wird darüber, wie weit sich ein Text über Software auf andere Arbeit übertragen lässt und ob „agil“ durch Beratung, Zertifikate und große Rahmenwerke seine Bedeutung verloren hat. Diese Kritik kommt auch von Mitautoren.

Was das Manifest sagt

Der Text besteht aus einer Präambel, vier Wertpaaren und einem Schlusssatz. Die Präambel sagt sinngemäß, die Autoren hätten bessere Wege der Softwareentwicklung gefunden, indem sie es selbst taten und anderen dabei halfen. Die Werte sind als Vorzug formuliert: das eine mehr als das andere.

Der Schlusssatz lautet in der offiziellen Übersetzung: „Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.“ Wer daraus „keine Pläne“ oder „keine Dokumentation“ liest, streicht die rechte Seite, statt sie nachzuordnen.

Die zwölf Prinzipien sind konkreter. Sie lassen sich in fünf Gruppen ordnen; die Wiedergabe ist eine Paraphrase.

Zwei Dinge fallen auf. Erstens spricht der Text durchgehend von Software, Entwicklern und Kunden. Zweitens nennt er keine Rollen, Termine oder Artefakte. Was ein Team konkret tut, überlässt er Methoden wie Scrum oder Extreme Programming. Wie diese Methoden arbeiten, beschreibt der Artikel zum agilen Arbeiten.

Nutzen und Beleglage

Ein Wertebekenntnis lässt sich nicht im Experiment prüfen. Belege gibt es nur mittelbar, und sie sind unterschiedlich stark.

Iteratives Vorgehen ist älter und besser dokumentiert als das Manifest. Craig Larman und Victor Basili, ein Berater und ein Softwaretechnik-Forscher der University of Maryland, zeigten 2003, dass iterative und schrittweise Entwicklung bis in die Mitte der 1950er-Jahre zurückreicht und in vielen großen Projekten eingesetzt wurde. Das Manifest fasste also eine bestehende Praxis zusammen, statt eine neue zu erfinden.

Agile Praktiken in Softwareprojekten. Studien zu einzelnen Praktiken und Befragungen zum Projekterfolg finden überwiegend positive Zusammenhänge. Sie messen Methoden, nicht die Werte des Manifests, und sie beruhen oft auf Selbstauskünften. Die Einzelheiten stehen im Artikel zum agilen Arbeiten.

Verbreitung. Dass sich Organisationen weit über die Softwareentwicklung hinaus auf das Manifest berufen, zeigt seinen Einfluss. Ein Beleg für seine Wirkung ist es nicht.

Worauf das Manifest beruht

Das Manifest setzt eine bestimmte Lage voraus. Seine Werte passen umso schlechter, je weniger davon zutrifft.

1. Anforderungen sind unsicher und ändern sich. Wo sich vorab genau festlegen lässt, was gebraucht wird, verliert „Reagieren auf Veränderung“ seinen Vorteil gegenüber einem Plan. Im Cynefin-Modell entspricht die Lage des Manifests eher komplexen als komplizierten Problemen.
2. Teilergebnisse lassen sich früh nutzen und prüfen. Bei Software ist das meist möglich. Bei einer Brücke oder einer Rechtsnorm gibt es kein nutzbares Viertel.
3. Ein Kunde ist erreichbar und will mitarbeiten. Das Prinzip täglicher Zusammenarbeit setzt voraus, dass jemand mit Fachwissen und Entscheidungsbefugnis Zeit hat.
4. Das Team darf sich selbst organisieren. Vertrauen und Selbstorganisation brauchen eine Umgebung, die Entscheidungen im Team zulässt und Fehler nicht bestraft (siehe psychologische Sicherheit).
5. Verträge und Haftung lassen Spielraum. In regulierten Bereichen oder bei öffentlichen Ausschreibungen sind Dokumentation und Vertragsverhandlung oft vorgeschrieben, nicht nur Gewohnheit.

Herkunft, Lesarten und Streitfragen

Nach dem Bericht von Jim Highsmith, einem der Teilnehmer, trafen sich die 17 Autoren vom 11. bis 13. Februar 2001 in der Lodge des Skigebiets Snowbird. Sie vertraten unter anderem Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development und Pragmatic Programming. Gemeinsam war ihnen die Ablehnung schwergewichtiger, dokumentengetriebener Vorgehensmodelle. Solche Ansätze hießen damals „leichtgewichtig“ (lightweight); das Wort mochte niemand, und in Snowbird fiel die Wahl auf „agil“.

Unterzeichnet haben unter anderem Kent Beck, Ward Cunningham, Martin Fowler, Ron Jeffries, Ken Schwaber und Jeff Sutherland. Unter den 17 Autoren war keine Frau; der Text gibt die Erfahrung einer kleinen Gruppe aus Softwareentwicklung und -beratung wieder.

Aus der Rezeption ergeben sich drei Streitfragen.

Haltung oder Methode? Eine Lesart versteht das Manifest als Haltung, die sich in vielen Methoden ausdrücken kann. Die andere misst Agilität an Praktiken wie kurzen Iterationen, Retrospektiven und automatisierten Tests. Die erste Lesart ist offen für Übertragungen, aber schwer zu prüfen. Die zweite ist prüfbar, gerät aber leicht zum Ritual.

Software oder Arbeit überhaupt? Der Text spricht nur von Software. Seine Übertragung auf Personalarbeit, Marketing oder Verwaltung ist eine spätere Interpretation, kein Bestandteil des Manifests. Ob die Annahmen oben dort zutreffen, muss jeweils geprüft werden.

Was ist aus dem Wort geworden? Dave Thomas, einer der Mitautoren, schrieb 2014, das Wort „agil“ sei so weit vereinnahmt, dass es praktisch bedeutungslos geworden sei. Er schlug vor, statt von „Agile“ als Ware von agility als Eigenschaft der Arbeit zu sprechen. Ron Jeffries, Mitbegründer von Extreme Programming, riet Entwicklern 2018, sich von „Faux Agile“ abzuwenden, also von Einführungen, die von oben verordnet werden, mehr Kontrolle und Druck bringen und mit den Werten des Manifests wenig gemein haben. Beide kritisieren nicht das Manifest, sondern was in seinem Namen geschieht.

Grenzen und Kritik

• Unbestimmtheit. Wertpaare mit „mehr als“ sagen nicht, wie viel Dokumentation oder Planung angemessen ist. Fast jedes Vorgehen kann sich auf das Manifest berufen, und fast jede Abweichung lässt sich als Missverständnis abtun. Das macht den Text schwer widerlegbar.
• Einseitige Gegenüberstellung. Die rechte Seite steht für ein Zerrbild schwerfälliger Planung. Der Informatiker Bertrand Meyer trennt in seiner kritischen Bilanz von 2014 brauchbare von überschätzten und schädlichen agilen Ideen; zu den schädlichen zählt er die Geringschätzung von Anforderungsarbeit und Entwurf vor Beginn der Entwicklung.
• Enge Herkunft. Der Text verallgemeinert die Erfahrung einer kleinen, homogenen Gruppe aus der Softwareberatung.
• Abstand zwischen Text und Praxis. Zertifikate, Rahmenwerke für viele Teams und Beratungsangebote haben aus einer Erklärung über Zusammenarbeit ein Produkt gemacht. Die Kritik der Mitautoren Thomas und Jeffries richtet sich genau darauf.

Das Manifest ist damit ein historisches Dokument, das eine verbreitete Unzufriedenheit mit dokumentengetriebener Softwareentwicklung in vier Sätze fasste. Was es für eine bestimmte Arbeit bedeutet, sagt es nicht. Das muss jede Methode und jedes Team selbst klären.

Quellen

• Beck, K. et al. (2001): Manifest für Agile Softwareentwicklung (offizielle deutsche Übersetzung) und Prinzipien. Autorenliste: agilemanifesto.org/authors.html.
• Highsmith, J. (2001): History: The Agile Manifesto.
• Larman, C. & Basili, V. R. (2003): Iterative and Incremental Development: A Brief History. Computer 36(6), 47–56.
• Takeuchi, H. & Nonaka, I. (1986): The New New Product Development Game. Harvard Business Review 64(1).
• Beck, K. (1999): Extreme Programming Explained: Embrace Change. Addison-Wesley.
• Schwaber, K. & Sutherland, J.: The Scrum Guide (2020).
• Thomas, D. (2014): Agile is Dead (Long Live Agility).
• Jeffries, R. (2018): Developers Should Abandon Agile. Zusammenfassung bei InfoQ.
• Meyer, B. (2014): Agile! The Good, the Hype and the Ugly. Springer.