Deutsch

Agile Manifesto: Die 4 Werte und 12 Prinzipien erklärt

Überblick über die 4 Werte und 12 Prinzipien des Agile Manifesto

Das Agile Manifesto ist eines der meistgelesenen Dokumente in der Geschichte der Softwareentwicklung, und es umfasst gerade einmal 68 Wörter. Siebzehn Praktiker verfassten es im Februar 2001 in einem Skiresort in Snowbird, Utah, frustriert von jahrelangen aufgeblähten Prozessen, die Software lieferten, die niemand wollte und die zu spät fertig wurde.

Doch der Einfluss des Dokuments reichte weit über die Softwareentwicklung hinaus. Heute führen Marketingteams Sprints durch. HR-Abteilungen halten Retrospektiven ab. Betriebsteams nutzen Kanban-Boards. Die vier Werte und zwölf Prinzipien des Agile Manifesto bilden das Fundament all dieser Praktiken.

Dieser Leitfaden erläutert genau, was diese Werte und Prinzipien aussagen, was sie in der Praxis bedeuten und wie Sie sie in jedem Team anwenden können.

Was ist das Agile Manifesto?

Das Agile Manifesto ist ein kurzes Gründungsdokument, das im Februar 2001 von 17 Softwarepraktikern im Skiresort Snowbird in Utah verfasst wurde. Es definiert vier Kernwerte und zwölf Prinzipien, die Menschen, funktionierende Ergebnisse und Anpassungsfähigkeit über starre Prozesse und aufwändige Vorabplanung stellen.

Unter den 17 Unterzeichnern befanden sich einige der einflussreichsten Persönlichkeiten der Softwareentwicklung: Kent Beck (Begründer von Extreme Programming), Jeff Sutherland und Ken Schwaber (Mitbegründer von Scrum), Martin Fowler, Jim Highsmith, Alistair Cockburn und elf weitere. Ihre Frustration war geteilt: Schwergewichtige, planorientierte Prozesse erzeugten kontinuierlich Software, die zu spät fertig, über Budget und zum Auslieferungstermin bereits veraltet war.

Das Dokument ist auf agilemanifesto.org veröffentlicht und wurde seitdem nie überarbeitet. Es ist noch genau so wie im Jahr 2001 verfasst.

Wichtige Fakten

  • Das Agile Manifesto wurde im Februar 2001 auf agilemanifesto.org veröffentlicht und von 17 Softwarepraktikern unterzeichnet. Seine vier Werte umfassen 68 Wörter, unverändert seit der Veröffentlichung.
  • Der 18th Annual State of Agile Report (Digital.ai, 2024) ergab, dass 71 % der Organisationen Agile-Ansätze einsetzen, gegenüber 37 % im Jahr 2011.
  • Eine Analyse des Standish Group CHAOS Report ergab, dass Agile-Projekte deutlich höhere Erfolgsquoten erzielen als Waterfall-Projekte: 42 % Erfolgsquote gegenüber 13 % bei Waterfall, kontrolliert nach Projektgröße (Ausgabe 2020).

Das Verständnis des Manifesto ist auch für die agile Methodik als Ganzes grundlegend, da jedes größere Framework (Scrum, Kanban, XP) seinen Ursprung in diesem Dokument hat.

Die 4 Werte des Agile Manifesto

Die vier Werte des Agile Manifesto

Das Manifesto formuliert es klar: „Wir entdecken bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte schätzen gelernt..."

Dann folgen vier Wertepaare. Jedes ist nach dem Muster „X über Y" formuliert. Die entscheidende Klarstellung, die folgt, ist ebenso wichtig: „Obwohl wir die Dinge jeweils rechts wertschätzen, schätzen wir die Dinge links mehr."

Diese Nuance ist wichtig. Das Manifesto sagt nicht, dass Verträge wertlos sind. Es sagt, dass die Zusammenarbeit mit dem Kunden wichtiger ist. Es sagt nicht, dass Dokumentation nutzlos ist. Es sagt, dass funktionierende Software Vorrang hat.

Wert Was er bevorzugt Was er nicht ablehnt
Individuen und Interaktionen über Prozesse und Werkzeuge Direkte Kommunikation, menschliches Urteilsvermögen, Teambeziehungen Prozesse und Werkzeuge (sie sind nur nicht das Wichtigste)
Funktionierende Software über umfassende Dokumentation Das Ausliefern von etwas Funktionierendem, auf das Nutzer reagieren können Dokumentation (schreiben Sie sie, aber lassen Sie sie nicht die Auslieferung ersetzen)
Zusammenarbeit mit dem Kunden über Vertragsverhandlung Kontinuierlicher Dialog mit den Menschen, die das Produkt nutzen Verträge (sie sind notwendig, aber nicht der Nordstern)
Reagieren auf Veränderung über das Befolgen eines Plans Anpassung basierend auf dem, was Sie während der Auslieferung lernen Pläne (beginnen Sie mit einem, beten Sie ihn nur nicht an)

Wert 1: Individuen und Interaktionen über Prozesse und Werkzeuge

Ein Stand-up-Meeting, in dem Menschen tatsächlich Blocker benennen, ist wertvoller als ein gepflegtes Projekttracking-Tool, das niemand liest. Dieser Wert ist eine Erinnerung daran, dass Prozesse ein Mittel zum Zweck sind, kein Selbstzweck.

In der Praxis: Wenn Ihr Team mehr Zeit damit verbringt, das System zu pflegen als über die eigentliche Arbeit zu sprechen, läuft etwas falsch.

Wert 2: Funktionierende Software über umfassende Dokumentation

Dies ist der am häufigsten missverstandene Wert. Teams lesen ihn manchmal als „keine Dokumentation schreiben". Das ist nicht gemeint. Es geht darum, dass ein funktionierendes Produkt in den Händen eines Nutzers mehr Erkenntnisse liefert als ein Spezifikationsdokument. Ein Prototyp, der in Woche zwei ausgeliefert wird, sagt mehr aus als ein 40-seitiges Anforderungsdokument aus dem ersten Monat.

Wert 3: Zusammenarbeit mit dem Kunden über Vertragsverhandlung

Verträge definieren, was zu Beginn vereinbart wurde. Kunden wissen, was sie wirklich brauchen, nachdem sie die ersten Iterationen gesehen haben. Regelmäßige Zusammenarbeit, Demos und Feedback-Schleifen lassen das Produkt in Richtung dessen weiterentwickeln, was der Kunde tatsächlich möchte, nicht nur was er ursprünglich aufgeschrieben hat.

Wert 4: Reagieren auf Veränderung über das Befolgen eines Plans

Märkte verändern sich. Wettbewerber liefern. Nutzerfeedback überrascht. Ein Plan, der vor Beginn der Arbeit geschrieben wurde, spiegelt Annahmen wider, keine Realität. Agile Teams aktualisieren ihren Plan, wenn sie dazulernen. Die Sprint-Planung ist der Ort, an dem dieser Wert operationalisiert wird: Teams planen einen Sprint nach dem anderen, nicht sechs Monate auf einmal.

Die 12 Prinzipien von Agile

Die 12 Prinzipien von Agile

Die zwölf Prinzipien erweitern jeden Wert zu umsetzbarer Orientierung. Sie wurden zusammen mit den vier Werten verfasst und sind als Begleitseite auf agilemanifesto.org/principles.html veröffentlicht.

# Prinzip Bedeutung in einfacher Sprache
1 Höchste Priorität hat die Befriedigung des Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software. Liefern Sie frühzeitig etwas Nützliches. Warten Sie nicht, bis alles perfekt ist.
2 Heißen Sie Anforderungsänderungen willkommen, selbst spät in der Entwicklung. Späte Änderungen sind kein Versagen. Sie sind Information. Bauen Sie Prozesse, die das aufnehmen können.
3 Liefern Sie regelmäßig funktionierende Software, bevorzugt in kürzeren Zeitspannen von einigen Wochen. Kurze Zyklen schlagen lange. Je öfter Sie liefern, desto schneller lernen Sie.
4 Fachleute und Entwickler müssen während des Projekts täglich zusammenarbeiten. Die Menschen, die das Fachgebiet verstehen, und die Menschen, die das Produkt bauen, dürfen nicht in Silos arbeiten.
5 Errichten Sie Projekte rund um motivierte Personen. Geben Sie ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertrauen Sie darauf, dass sie die Aufgabe erledigen. Eigenverantwortung und Vertrauen liefern bessere Ergebnisse als Kontrolle und Mikromanagement.
6 Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist das Gespräch von Angesicht zu Angesicht. Direkte Gespräche schlagen Dokumentationsketten. (Videoanrufe zählen.)
7 Funktionierende Software ist das wichtigste Fortschrittsmaß. Velocity-Punkte, geschlossene Tickets und begonnene Features sind allesamt Näherungswerte. Das einzige echte Maß ist etwas, das funktioniert.
8 Agile Prozesse fördern nachhaltige Entwicklung. Alle Beteiligten sollten ein dauerhaft gleichmäßiges Tempo halten können. Überlastung ist keine Strategie. Teams, die monatelang auf Hochtouren arbeiten, brennen aus und produzieren fehlerhafte Arbeit.
9 Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. Schlechter Code macht Sie mit der Zeit langsamer. Abkürzungen jetzt zu nehmen, macht Sie später langsamer.
10 Einfachheit, die Kunst, die Menge nicht getaner Arbeit zu maximieren, ist essenziell. Tun Sie weniger. Das beste Feature ist eines, das Sie nicht bauen müssen. Der beste Prozessschritt ist einer, den Sie eliminieren können.
11 Die besten Architekturen, Anforderungen und Designs entstehen durch selbstorganisierte Teams. Top-down-Mandate erzeugen Konformität. Selbstorganisierte Teams erzeugen Eigenverantwortung und Kreativität.
12 In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an. Sprint-Retrospektiven sind nicht optional. Kontinuierliche Verbesserung ist in den Rhythmus eingebaut.

Drei Prinzipien sind besonders wichtig für Nicht-Softwareteams: Prinzip 2 (Änderungen willkommen heißen), Prinzip 10 (nicht getane Arbeit maximieren) und Prinzip 12 (regelmäßige Retrospektiven). Diese gelten gleichermaßen für Marketingkampagnen, HR-Prozesse und betriebliche Abläufe.

Warum das Agile Manifesto weiterhin relevant ist

Das Manifesto entstand als Reaktion auf ein konkretes Problem: Softwareprojekte, die scheiterten, weil sie versuchten, alles im Voraus zu planen und zu spezifizieren. Dieses Problem ist nicht verschwunden. Wenn überhaupt, hat es sich verschärft.

Hier ist, warum die Relevanz des Manifesto zugenommen hat:

Arbeit ist komplexer geworden. Die Probleme, die Teams im Jahr 2026 angehen (KI-Integration, verteiltes Arbeiten, Markteinführungen in mehreren Regionen), sind schwieriger vorab zu spezifizieren als die Enterprise-Softwareprojekte des Jahres 2001. Iterative Auslieferung und schnelle Lernschleifen sind noch wichtiger geworden.

Feedback-Schleifen sind schneller und günstiger. Im Jahr 2001 bedeutete die Auslieferung physische Releases oder nächtliche Deployments. Heute kann ein Team ein Feature in Minuten an 10 % der Nutzer ausliefern und die Ergebnisse in Stunden messen. Die Wette des Manifesto auf schnelles Feedback zahlt sich noch mehr aus.

Agile hat Software hinter sich gelassen. Marketing-, HR-, Finanz- und Betriebsteams führen Sprints durch. Die 12 Prinzipien sind domänenunabhängig. Prinzip 8 (nachhaltiges Tempo) gilt für jedes Team. Prinzip 10 (nicht getane Arbeit maximieren) gilt für jeden Prozess. Prinzip 12 (regelmäßige Retrospektiven) gilt für jede Gruppe, die sich verbessern möchte.

Die Entscheidung zwischen Agile und Waterfall ist nach wie vor die häufigste strategische Wahl, die Teams beim Start eines neuen Projekts treffen, und das Manifesto ist die klarste Formulierung dessen, was Agile auszeichnet.

Häufige Missverständnisse über Agile

Das Manifesto wird ständig falsch gelesen. Hier sind die häufigsten Fehler und was das Dokument tatsächlich sagt.

Missverständnis 1: „Agile bedeutet keine Planung."

Das stimmt nicht. Das Manifesto sagt „Reagieren auf Veränderung über das Befolgen eines Plans", nicht „plant niemals". Jeder Sprint beginnt mit einer Sprint-Planung. Jedes Quartal beginnt mit der Zielsetzung. Der Unterschied besteht darin, dass Agile-Pläne aktualisiert werden, wenn neue Informationen eintreffen, statt starr befolgt zu werden, unabhängig davon, was man lernt.

Missverständnis 2: „Agile bedeutet keine Dokumentation."

Das Manifesto bewertet funktionierende Software über umfassende Dokumentation. „Umfassend" ist das Schlüsselwort. Schreiben Sie Dokumentation, die nützlich ist. Schreiben Sie keine Dokumentation als Ersatz für die Auslieferung von etwas.

Missverständnis 3: „Agile ist nur für Softwareteams."

Das Manifesto wurde von Softwarepraktikern geschrieben, aber die Werte sind nicht softwarespezifisch. Prinzip 1 (frühzeitige Wertlieferung), Prinzip 2 (Änderungen willkommen heißen) und Prinzip 12 (regelmäßige Retrospektiven) gelten für jedes Team, das komplexe Arbeit erledigt.

Missverständnis 4: „Agile bedeutet keine Fristen."

Agile Teams haben Fristen. Sprint Reviews finden zu fixen Terminen statt. Produktveröffentlichungen haben Startfenster. Der Unterschied besteht darin, dass Agile Teams den Umfang anpassen, um den Termin einzuhalten, statt den Termin anzupassen, um den Umfang unterzubringen.

Missverständnis 5: „Scrum ist Agile."

Scrum ist eine Umsetzung agiler Werte. Genauso wie Kanban und Extreme Programming. Agile ist die Philosophie; Scrum ist ein Rezept, das ihr folgt. Man kann agil sein, ohne Scrum zu praktizieren. Man kann Scrum-Zeremonien durchführen, ohne wirklich agil zu sein (das nennt sich „Cargo-Kult-Agile" und ist in Organisationen weiter verbreitet, als die meisten zugeben wollen).

So wenden Sie das Agile Manifesto in Ihrem Team an

Sie müssen kein formelles Framework einführen, um mit der Anwendung agiler Werte zu beginnen. Hier erfahren Sie, wie Sie von den Prinzipien des Manifesto zu konkreter Praxis gelangen.

Schritt 1: Identifizieren Sie Ihre aktuellen Verschwendungen

Schauen Sie, wo Ihr Team Zeit auf Dinge verwendet, die keinen direkten Wert erzeugen. Lange Freigabeprozesse, Statusberichte, die niemand liest, Meetings, die eine Nachricht hätten sein können. Prinzip 10 (nicht getane Arbeit maximieren) beginnt hier.

Schritt 2: Verkürzen Sie Ihren Auslieferungszyklus

Was ist das Kleinste, das Ihr Team ausliefern könnte, auf das ein echter Nutzer reagieren kann? Wenn Ihr aktueller Zyklus quartalsweise ist, setzen Sie sich das Ziel, monatlich zu liefern. Wenn es monatlich ist, streben Sie zweiwöchentlich an. Burndown-Charts können Ihnen helfen, zu visualisieren, ob die pro Zyklus gelieferte Arbeit tatsächlich abgeschlossen wird.

Schritt 3: Holen Sie den Kunden früher ins Boot

Ihr „Kunde" kann ein externer Auftraggeber, ein interner Stakeholder oder ein Endnutzer sein. Wie auch immer, finden Sie einen Weg, diesem laufende Arbeit zu zeigen statt fertiggestellter Arbeit. Frühes Feedback ist günstig. Spätes Feedback ist teuer.

Schritt 4: Etablieren Sie eine Retrospektiven-Gewohnheit

Blockieren Sie 30 bis 60 Minuten am Ende jedes Arbeitszyklus, um drei Fragen zu stellen: Was lief gut? Was lief nicht gut? Was werden wir ändern? Prinzip 12 ist der Zinseszins von Agile. Teams, die regelmäßig Retrospektiven abhalten, verbessern sich schneller als Teams, die es nicht tun. Die formelle Variante ist eine Sprint-Retrospektive, aber selbst ein einfaches gemeinsames Dokument reicht für den Anfang.

Schritt 5: Experimentieren Sie mit WIP-Limits

Wählen Sie eine Phase Ihres Workflows (In Bearbeitung, In Überprüfung oder ähnliches) und begrenzen Sie die Anzahl der Elemente, die dort gleichzeitig liegen dürfen. Sowohl Scrum als auch Kanban stimmen in einem Punkt überein: laufende Arbeit abschließen schlägt neue Arbeit beginnen. WIP-Limits erzwingen dieses Verhalten.

Schritt 6: Geben Sie Ihrem Team mehr Eigenverantwortung

Prinzip 11 besagt, dass die besten Ergebnisse aus selbstorganisierten Teams entstehen. Das bedeutet, dass die Menschen, die die Arbeit tun, Einfluss darauf haben sollten, wie die Arbeit erledigt wird. Beginnen Sie im Kleinen: Lassen Sie das Team entscheiden, wie es seine Stand-ups gestaltet, oder lassen Sie es seine eigene Kapazität je Sprint schätzen, anstatt dass ein Manager Ziele vorgibt.

Agile Manifesto in der Praxis nach Funktion und Rolle

Die vier Werte sehen unterschiedlich aus, je nachdem, wer die Arbeit erledigt.

Funktion Wert in der Praxis Praxisbeispiel
Engineering Funktionierende Software über Dokumentation Einen funktionierenden Prototypen in Woche 2 an Beta-Nutzer ausliefern, statt einen Monat lang eine 30-seitige Spezifikation für einen langen Review-Zyklus zu schreiben.
Marketing Reagieren auf Veränderung über das Befolgen eines Plans Eine Kampagne in zweiwöchigen Sprints starten. Wenn das erste Anzeigenset unterdurchschnittlich abschneidet, die Botschaft anpassen, bevor das gesamte Budget ausgegeben ist.
Produkt Zusammenarbeit mit dem Kunden über Vertragsverhandlung Zweiwöchentliche Nutzerinterviews während der gesamten Entwicklung durchführen, anstatt zu Beginn nur eine einzige Runde der Anforderungserhebung zu machen.
HR / People Ops Individuen und Interaktionen über Prozesse und Werkzeuge 1:1-Gespräche und direktes Feedback nutzen, um Leistungsprobleme frühzeitig zu erkennen, statt sich ausschließlich auf das jährliche Bewertungssystem zu verlassen.
Betrieb Reagieren auf Veränderung über das Befolgen eines Plans Ein MoSCoW-Priorisierungsboard für eingehende Anfragen führen, damit dringende Probleme gelöst werden, ohne die geplante Arbeit zu gefährden.
Design Zusammenarbeit mit dem Kunden über Vertragsverhandlung Grobe Wireframes jeden Sprint mit Endnutzern teilen. Deren Reaktionen nutzen, um zu überarbeiten, bevor man sich auf einen vollständigen Aufbau festlegt.

User Stories sind eines der praktischsten Werkzeuge, um die Lücke zwischen Kundenbedürfnissen und Teamaufgaben zu überbrücken. Sie sind das Agile-Artefakt, das Wert 3 (Zusammenarbeit mit dem Kunden) greifbar macht.

Häufig gestellte Fragen

Wer hat das Agile Manifesto geschrieben?

Das Agile Manifesto wurde von 17 Softwarepraktikern verfasst, die sich im Februar 2001 im Skiresort Snowbird in Utah trafen. Zur Gruppe gehörten Kent Beck, Jeff Sutherland, Ken Schwaber, Martin Fowler, Jim Highsmith, Alistair Cockburn, Ward Cunningham und neun weitere. Sie unterzeichneten das Dokument gemeinsam als Autoren, obwohl der Begriff „agile" erst während des Treffens selbst vorgeschlagen wurde.

Wann wurde das Agile Manifesto veröffentlicht?

Das Agile Manifesto wurde im Februar 2001 veröffentlicht, genauer gesagt vom 11. bis 13. Februar 2001, während eines dreitägigen Retreats im Resort Snowbird in Utah. Das Dokument wurde online auf agilemanifesto.org veröffentlicht und seitdem nicht überarbeitet.

Was sind die 4 Werte des Agile Manifesto?

Die vier Werte sind: (1) Individuen und Interaktionen über Prozesse und Werkzeuge, (2) Funktionierende Software über umfassende Dokumentation, (3) Zusammenarbeit mit dem Kunden über Vertragsverhandlung und (4) Reagieren auf Veränderung über das Befolgen eines Plans. Jedes Wertepaar bedeutet, dass die linke Seite Vorrang hat, die rechte Seite aber ebenfalls Wert besitzt.

Was ist der Unterschied zwischen den 4 Werten und den 12 Prinzipien?

Die 4 Werte sind das philosophische Fundament: Sie beschreiben, was Agile Teams priorisieren. Die 12 Prinzipien sind die operative Erweiterung: Sie erklären, wie man auf Basis dieser Werte in der Praxis handelt. Zum Beispiel sagt Wert 4 „auf Veränderung reagieren". Prinzip 2 sagt „heißen Sie Anforderungsänderungen willkommen, selbst spät in der Entwicklung". Prinzip 3 sagt „liefern Sie regelmäßig funktionierende Software". Beide unterstützen denselben Wert, aber auf unterschiedlichen Konkretisierungsstufen.

Ist das Agile Manifesto im Jahr 2026 noch relevant?

Ja. Die vier Werte wurden als Reaktion auf überdetaillierte, plangetriebene Prozesse geschrieben. Im Jahr 2026 tauchen dieselben Dynamiken bei KI-gestützter Entwicklung, großangelegter digitaler Transformation und verteilten Teams auf. Das Manifesto beschreibt keine Werkzeuge oder Technologien. Es beschreibt Prioritäten. Und diese Prioritäten, Menschen über Prozesse, funktionierende Ergebnisse über Dokumentation und Lernen über Vorhersage zu stellen, sind heute genauso anwendbar wie 2001. Der 18th Annual State of Agile Report (Digital.ai, 2024) ergab, dass 71 % der Organisationen nun Agile-Ansätze einsetzen.

Das Agile Manifesto ist kein historisches Artefakt. Es ist ein Entscheidungsrahmen. Jedes Mal, wenn Ihr Team vor der Wahl steht zwischen dem Fertigstellen der Dokumentation und dem Ausliefern des Prototyps, zwischen dem Befolgen des ursprünglichen Plans und dem Anpassen auf Basis neuer Daten, zwischen einem Prozess und einem Gespräch, sagt das Manifesto, in welche Richtung man sich neigen sollte. Diese Orientierung verfällt nicht.