Agile Manifesto: 4 Werte, 12 Prinzipien & Praxis für moderne Teams [2026]

Aktualisiert: 19. Mai 2026

Das Agile Manifest gehört zu den wenigen Texten, die in der Software-Welt fast überall hängen, aber selten wirklich gelesen werden. Vier Wertepaare und zwölf Prinzipien auf einer halben Seite, formuliert im Februar 2001 von siebzehn Entwicklern in Snowbird, Utah. Ich finde diese Kürze beeindruckend, vor allem im Kontrast zu den hunderten Seiten Methodik-Frameworks, die seither entstanden sind.

In Projekten höre ich oft Sätze wie „wir sind agil, wir machen Scrum". Das ist ungefähr so, als würde man sagen „wir sind sportlich, wir kaufen Sneaker". Methoden sind Werkzeuge, das Manifest beschreibt die Haltung dahinter. Wer agile Prinzipien nicht kennt oder schon lange nicht mehr nachgelesen hat, übersieht oft, dass viele scheinbar moderne Praktiken wie DevTestOps, Shift-Left oder kontinuierliches Lernen längst dort verankert sind.

Dieser Beitrag erklärt die vier Werte und zwölf Prinzipien des Manifests, übersetzt sie in heutige Tester-Praxis, deckt häufige Missverständnisse auf und ordnet ein, warum die Werte auch in der KI-Ära tragen.

Inhaltsverzeichnis

Was ist das Agile Manifest?

Das Agile Manifest ist ein knapper Text mit vier Wertepaaren und zwölf Prinzipien, der eine Haltung zur Softwareentwicklung beschreibt. Es ist kein Framework, keine Methode und kein Prozess. Es ist eine Sammlung von Überzeugungen, die als Gegenentwurf zu den damals dominanten Wasserfall- und V-Modellen entstanden ist.

Geschrieben wurde es im Februar 2001 in Snowbird, Utah, von siebzehn Entwicklern und Beratern. Darunter Kent Beck (XP), Ken Schwaber und Jeff Sutherland (Scrum), Alistair Cockburn (Crystal), Martin Fowler, Dave Thomas und andere. Der Originaltext ist auf agilemanifesto.org in 73 Sprachen abrufbar und seit der Veröffentlichung unverändert.

Die zentrale Aussage: Es geht nicht um neue Werkzeuge oder Zeremonien, sondern um eine Haltung. Wer das vergisst, baut Scrum-Theater mit Stand-ups, Reviews und Retros, ohne dass am Ende eine andere Kultur entsteht. Mehr zur Framework-Übersicht im Agiles Testing Guide.

Agile Softwareentwicklung mit dem Agilen Manifest als Grundlage
Abbildung 1: Das Agile Manifest als Grundlage moderner Softwareentwicklung (Quelle: Qytera)

Die vier Werte im Klartext

Das Manifest stellt vier Wertepaare auf. Der Trick: Es geht nicht um ein Entweder-oder, sondern um Gewichtung. Die linke Seite hat Vorrang, ohne dass die rechte unwichtig wird. Die folgende Tabelle übersetzt jeden Wert in eine konkrete Praxis-Frage:

WertBedeutungPraxis-Frage
Individuen und Interaktionen über Prozesse und WerkzeugeMenschen lösen Probleme, nicht ToolsWann hast du das letzte Mal mit dem Entwickler gesprochen statt ein Ticket geöffnet?
Funktionierende Software über umfassende DokumentationWert entsteht durch Ergebnisse, nicht durch BeschreibungWäre dein Stakeholder froh über Doku, wenn das Feature nicht läuft?
Zusammenarbeit mit dem Kunden über VertragsverhandlungLernen während der Arbeit schlägt vorab festgelegte PflichtenhefteWann wurde der letzte Akzeptanzkriterien-Workshop mit Fachbereich durchgeführt?
Reagieren auf Veränderung über das Befolgen eines PlansPläne sind Werkzeuge, kein SelbstzweckWie oft passt du deinen Sprint-Plan basierend auf neuen Erkenntnissen an?

Wichtig ist der zweite Halbsatz: „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 das übersieht, kommt zu absurden Schlüssen wie „keine Dokumentation" oder „kein Plan", die das Manifest nie behauptet.

Die zwölf Prinzipien im Überblick

Die Werte allein sind abstrakt. Die zwölf Prinzipien machen sie operationalisierbar. Sie beschreiben, wie agile Teams arbeiten, liefern und lernen:

  1. Frühe und kontinuierliche Auslieferung wertvoller Software ist die höchste Priorität.
  2. Anforderungsänderungen sind willkommen, auch spät im Projekt, zum Wettbewerbsvorteil des Kunden.
  3. Liefere funktionierende Software regelmäßig in Wochen bis Monaten, kürzere Zyklen bevorzugt.
  4. Fachexperten und Entwickler arbeiten täglich zusammen während des Projekts.
  5. Errichte Projekte um motivierte Individuen, gib ihnen Umgebung und Unterstützung, vertraue ihnen.
  6. Direkte Kommunikation ist die effizienteste Informationsübertragung im Team.
  7. Funktionierende Software ist das wichtigste Fortschrittsmaß.
  8. Nachhaltiges Tempo: Sponsoren, Entwickler und Anwender sollten auf Dauer ein gleichmäßiges Tempo halten können.
  9. Ständige Aufmerksamkeit für technische Exzellenz und gutes Design erhöht die Agilität.
  10. Einfachheit ist essenziell: Die Kunst, möglichst viel Arbeit wegzulassen.
  11. Die besten Architekturen, Anforderungen und Entwürfe entstehen in selbstorganisierten Teams.
  12. Regelmäßige Reflexion und Anpassung: Das Team überprüft, wie es effektiver werden kann, und passt sein Verhalten an.

Wenn dich diese Liste an deine Retrospektiven oder Sprint-Reviews erinnert, ist das kein Zufall: Scrum, Kanban und andere Frameworks sind Antworten auf diese zwölf Punkte, nicht ihre Erfinder.

Agile Praxis im modernen Software-Testing
Abbildung 2: Die zwölf Prinzipien sind die operative Grundlage moderner Test-Praxis (Quelle: Qytera)

Was die Prinzipien für Tester bedeuten

Das Manifest ist von Entwicklern für Entwickler geschrieben. Tester werden nicht explizit erwähnt, was lange als Lücke wahrgenommen wurde. Inzwischen ist klar: Mindestens fünf der zwölf Prinzipien sind direkt auf Test-Praxis übertragbar.

  • Prinzip 1 + 3 (frühe und regelmäßige Auslieferung): Continuous Testing und automatisierte Pipelines sind die Tester-Antwort. Tests laufen bei jedem Commit, nicht erst vor dem Release. Mehr dazu im Beitrag Agiles Testmanagement in CI/CD.
  • Prinzip 2 (späte Änderungen willkommen): Test-Suite muss wartbar und gut strukturiert sein, sonst kostet jede Anforderungsänderung mehr als sie bringt. Hier setzt das Testkonzept an.
  • Prinzip 4 (tägliche Zusammenarbeit): Tester gehört in jedes Refinement, jeden Standup, jede Story-Verfeinerung. Drei-Amigos-Praxis ist die direkte Konsequenz.
  • Prinzip 7 (funktionierende Software als Fortschrittsmaß): Test-Berichte ohne Aussage zur Auslieferbarkeit sind wertlos. Test-Reports sollten Release-Entscheidungen unterstützen, nicht nur Bug-Counts liefern.
  • Prinzip 9 (technische Exzellenz): Test-Pyramide, Built-In Quality, Test-Code als First-Class-Citizen. Wer Tests als „später"-Aufgabe betrachtet, hat das Prinzip nicht verstanden. Siehe auch Shift Left vs. Shift Right Testing.

In Tester-Coachings führe ich oft eine Übung durch: Jeder im Team erklärt, an welchem Prinzip er in der letzten Iteration konkret gearbeitet hat. Wer kein Beispiel hat, hat einen blinden Fleck. Die Übung ist ein guter Realitäts-Check.

Bleiben die Werte in der KI-Ära aktuell?

Mit dem Aufkommen leistungsfähiger Sprachmodelle stellen viele die Frage: Sind die Prinzipien noch relevant, wenn KI-Agents Code schreiben, Tests generieren und Anforderungen analysieren? Meine klare Antwort: Ja, sogar noch wichtiger.

Drei Beobachtungen aus Projekten, in denen wir KI-Werkzeuge integrieren:

  • Prinzip 12 (regelmäßige Reflexion) wird zentraler: KI-Tools verändern sich monatlich. Teams brauchen kürzere Reflexionszyklen, um KI-Werkzeuge sinnvoll einzubinden, nicht nur einzuführen.
  • Prinzip 5 (motivierte Individuen) wird verteidigungswert: Wenn KI Standard-Aufgaben übernimmt, verschiebt sich der Wert eines Teams auf Urteilsvermögen, Kreativität und Verantwortung. Das sind menschliche Eigenschaften, keine Tool-Features.
  • Prinzip 7 (funktionierende Software als Fortschrittsmaß) hilft gegen KI-Hype: Eine generierte Testsuite ist keine bestandene Testsuite. Ein KI-Entwurf einer User Story ist kein abgenommenes Akzeptanzkriterium. Das Manifest gibt Teams einen anker, der sie davor schützt, Hype mit Wert zu verwechseln.

Mehr zu KI im Testen findest du im ISTQB-AI-Testing-Beitrag und zum Agentic AI Testing.

Sieben häufige Missverständnisse

Das Manifest ist kurz, deshalb wird es gerne fehlinterpretiert. Sieben Aussagen, die ich regelmäßig höre und die das Manifest nicht stützt:

  1. „Wir brauchen keine Dokumentation." Falsch. Das Manifest priorisiert funktionierende Software, ohne Doku abzulehnen. Wer ohne Architektur-Diagramm baut, hat das Manifest missverstanden.
  2. „Wir brauchen keinen Plan." Falsch. „Reagieren auf Veränderung über das Befolgen eines Plans" heißt nicht „kein Plan", sondern „lebendiger Plan". Sprint-Planung, PI-Planning, Roadmaps sind alle vereinbar.
  3. „Agile bedeutet schneller." Teilweise falsch. Agile zielt auf Wertfokus, frühere Auslieferung und Lernen. Schneller ist oft ein Nebenprodukt, kein Ziel.
  4. „Stand-ups sind das Manifest." Falsch. Stand-ups sind eine Praktik aus Scrum. Das Manifest ist viel grundsätzlicher.
  5. „Tester werden überflüssig." Falsch. Tester werden nicht überflüssig, sondern verschieben sich vom End-of-Sprint-Prüfer zum Qualitäts-Coach. Mehr im Beitrag Rolle des Testers in Scrum und SAFe.
  6. „Agile geht nur in kleinen Teams." Falsch. Skalierungs-Frameworks wie SAFe oder LeSS bringen die Werte in Großorganisationen. Siehe SAFe-Zertifizierungen.
  7. „Wir machen Scrum, also sind wir agil." Falsch. Scrum-Ritualisierung ohne Haltung ist Theater. Das Manifest fragt nach Werten, nicht nach Zeremonien.

Praxis-Check: Manifesto im Daily Standup

Ein Test, den ich Teams mitgebe: Druck die zwölf Prinzipien auf eine Karte und leg sie neben dein Standup-Board. Frag dich einmal pro Woche, ob du in den letzten fünf Tagen mindestens drei Prinzipien aktiv gelebt hast. Wenn nicht, hast du eine Hypothese, was im Team verbessert werden könnte.

Drei Beispiel-Fragen aus der Praxis:

  • Prinzip 4 (tägliche Zusammenarbeit): Hat der Fachbereich diese Woche aktiv mitgearbeitet, oder hatte er nur das Sprint-Review gesehen?
  • Prinzip 8 (nachhaltiges Tempo): Macht jemand seit zwei Wochen Überstunden? Wenn ja, ist das ein Symptom, kein Lob.
  • Prinzip 12 (regelmäßige Reflexion): Was hat dein Team in der letzten Retro konkret geändert? Wenn nichts, ist es nur Status-Reporting.

Diese Übung kostet zwei Minuten und liefert mehr Erkenntnis als die meisten Maturity-Modelle.

Vom Manifest zu Frameworks: Scrum, Kanban, SAFe

Frameworks sind die operative Umsetzung der Manifest-Werte für unterschiedliche Kontexte. Jedes hat eigene Schwerpunkte, alle berufen sich auf das Manifest:

FrameworkSchwerpunktTeam-GrößeManifest-Bezug stark in
ScrumIterative Auslieferung, klare Rollen5 bis 9 PersonenPrinzip 1, 3, 12 (Reflexion)
KanbanFlow, Limitierung der WIP, kontinuierliche LieferungBeliebigPrinzip 1, 8, 10 (Einfachheit)
Extreme Programming (XP)Technische Praktiken, Pair Programming, TDD5 bis 12 PersonenPrinzip 9 (technische Exzellenz)
SAFeSkalierung in Konzernen, Programm-Inkremente50 bis 1000+Alle, mit Programm-Linse
LeSSSkalierung mit minimalem Overhead50 bis 500Prinzip 10, 11 (Einfachheit, Selbstorganisation)
Spotify-ModellKultur, Tribes/SquadsBeliebigPrinzip 5, 11 (Vertrauen, Selbstorganisation)

Mein Rat: Wähle das Framework, das zu deinem Kontext passt, nicht das, das gerade hip ist. Wer im Konzern arbeitet, kommt um SAFe selten herum. Wer in einem 30-Personen-Tech-Unternehmen ist, ist mit Scrum oder Kanban besser dran. Tiefer eingeordnet im Framework-Guide.

Fazit

Das Agile Manifest ist auch in der KI-Ära ein lebendiger Text, kein historisches Dokument. Vier Werte und zwölf Prinzipien geben Teams eine Haltung, die unabhängig vom konkreten Framework trägt. Wer als Tester, Scrum Master oder Entwickler über die Jahre das Gefühl hat, in Ritualen festzustecken, findet im Manifest die Frage, die hilft: Welchen der zwölf Punkte habe ich heute aktiv gelebt?

Drei Empfehlungen: Erstens, lies das Manifest mindestens einmal im Jahr neu, am besten zum Sprint-Wechsel. Zweitens, frag dich vor jeder Methoden-Diskussion, welchen Wert sie konkret stärkt. Drittens, halte die zwölf Prinzipien greifbar, etwa als Karte am Arbeitsplatz oder als Checkliste in der Retro. Wenn du Unterstützung beim Aufbau einer agilen Test-Strategie brauchst, sprich uns gerne an.

FAQ: Häufige Fragen zum Agilen Manifest

Was ist das Agile Manifest?

Das Agile Manifest ist ein Text mit vier Wertepaaren und zwölf Prinzipien, der eine Haltung zur Softwareentwicklung beschreibt. Es ist kein Framework und kein Prozess. Geschrieben wurde es im Februar 2001 von siebzehn Entwicklern in Snowbird, Utah, der Originaltext ist auf agilemanifesto.org abrufbar.

Welche vier Werte hat das Manifest?

Individuen und Interaktionen über Prozesse und Werkzeuge. Funktionierende Software über umfassende Dokumentation. Zusammenarbeit mit dem Kunden über Vertragsverhandlung. Reagieren auf Veränderung über das Befolgen eines Plans. Die linke Seite hat Vorrang, die rechte bleibt aber wichtig.

Wo finde ich die zwölf Prinzipien?

Die zwölf Prinzipien sind auf agilemanifesto.org in 73 Sprachen verfügbar. Sie operationalisieren die vier Werte und beschreiben, wie agile Teams arbeiten, liefern und lernen. Eine deutsche Zusammenfassung mit Praxis-Bezug findest du im Abschnitt oben.

Was bedeutet das Manifest für Tester?

Mindestens fünf der zwölf Prinzipien sind direkt auf Test-Praxis übertragbar: frühe Auslieferung (Continuous Testing), Änderungen willkommen (wartbare Test-Suite), tägliche Zusammenarbeit (Three Amigos), funktionierende Software als Maß (Release-relevante Reports) und technische Exzellenz (Test-Pyramide). Tiefer im Beitrag Rolle des Testers.

Bedeutet das Manifest „keine Dokumentation"?

Nein. Das Manifest priorisiert funktionierende Software über umfassende Dokumentation, lehnt Doku aber nicht ab. Architektur-Diagramme, Test-Konzepte und Akzeptanzkriterien sind weiterhin sinnvoll. Wer ohne Dokumentation baut, hat das Manifest missverstanden.

Sind die Werte in der KI-Ära noch aktuell?

Ja, sogar noch wichtiger. KI-Tools verändern sich monatlich, was Prinzip 12 (regelmäßige Reflexion) zentraler macht. Prinzip 7 (funktionierende Software als Fortschrittsmaß) schützt vor Hype: eine generierte Testsuite ist keine bestandene Testsuite. Mehr im Agentic AI Testing.

Wie verhält sich das Manifest zu Scrum, Kanban oder SAFe?

Frameworks sind operative Umsetzungen der Manifest-Werte für unterschiedliche Kontexte. Scrum betont Iterationen und Reflexion, Kanban Flow und WIP-Limit, SAFe Skalierung in Konzernen. Alle berufen sich auf das Manifest, keines ist mit ihm identisch. Übersicht im Framework-Guide.

Testautomatisierung Beratung

Sie möchten Ihre Testautomatisierung optimieren? Unsere Experten helfen Ihnen bei der Auswahl der richtigen Tools, Best Practices und CI/CD-Integration.

Jetzt anfragen

Finden Sie weitere interessante Artikel zum Thema: