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?
- Die vier Werte im Klartext
- Die zwölf Prinzipien im Überblick
- Was die Prinzipien für Tester bedeuten
- Bleiben die Werte in der KI-Ära aktuell?
- Sieben häufige Missverständnisse
- Praxis-Check: Manifesto im Daily Standup
- Vom Manifest zu Frameworks: Scrum, Kanban, SAFe
- Fazit
- FAQ: Häufige Fragen zum Agilen Manifest
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.

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:
| Wert | Bedeutung | Praxis-Frage |
|---|---|---|
| Individuen und Interaktionen über Prozesse und Werkzeuge | Menschen lösen Probleme, nicht Tools | Wann hast du das letzte Mal mit dem Entwickler gesprochen statt ein Ticket geöffnet? |
| Funktionierende Software über umfassende Dokumentation | Wert entsteht durch Ergebnisse, nicht durch Beschreibung | Wäre dein Stakeholder froh über Doku, wenn das Feature nicht läuft? |
| Zusammenarbeit mit dem Kunden über Vertragsverhandlung | Lernen während der Arbeit schlägt vorab festgelegte Pflichtenhefte | Wann wurde der letzte Akzeptanzkriterien-Workshop mit Fachbereich durchgeführt? |
| Reagieren auf Veränderung über das Befolgen eines Plans | Pläne sind Werkzeuge, kein Selbstzweck | Wie 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:
- Frühe und kontinuierliche Auslieferung wertvoller Software ist die höchste Priorität.
- Anforderungsänderungen sind willkommen, auch spät im Projekt, zum Wettbewerbsvorteil des Kunden.
- Liefere funktionierende Software regelmäßig in Wochen bis Monaten, kürzere Zyklen bevorzugt.
- Fachexperten und Entwickler arbeiten täglich zusammen während des Projekts.
- Errichte Projekte um motivierte Individuen, gib ihnen Umgebung und Unterstützung, vertraue ihnen.
- Direkte Kommunikation ist die effizienteste Informationsübertragung im Team.
- Funktionierende Software ist das wichtigste Fortschrittsmaß.
- Nachhaltiges Tempo: Sponsoren, Entwickler und Anwender sollten auf Dauer ein gleichmäßiges Tempo halten können.
- Ständige Aufmerksamkeit für technische Exzellenz und gutes Design erhöht die Agilität.
- Einfachheit ist essenziell: Die Kunst, möglichst viel Arbeit wegzulassen.
- Die besten Architekturen, Anforderungen und Entwürfe entstehen in selbstorganisierten Teams.
- 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.

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:
- „Wir brauchen keine Dokumentation." Falsch. Das Manifest priorisiert funktionierende Software, ohne Doku abzulehnen. Wer ohne Architektur-Diagramm baut, hat das Manifest missverstanden.
- „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.
- „Agile bedeutet schneller." Teilweise falsch. Agile zielt auf Wertfokus, frühere Auslieferung und Lernen. Schneller ist oft ein Nebenprodukt, kein Ziel.
- „Stand-ups sind das Manifest." Falsch. Stand-ups sind eine Praktik aus Scrum. Das Manifest ist viel grundsätzlicher.
- „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.
- „Agile geht nur in kleinen Teams." Falsch. Skalierungs-Frameworks wie SAFe oder LeSS bringen die Werte in Großorganisationen. Siehe SAFe-Zertifizierungen.
- „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:
| Framework | Schwerpunkt | Team-Größe | Manifest-Bezug stark in |
|---|---|---|---|
| Scrum | Iterative Auslieferung, klare Rollen | 5 bis 9 Personen | Prinzip 1, 3, 12 (Reflexion) |
| Kanban | Flow, Limitierung der WIP, kontinuierliche Lieferung | Beliebig | Prinzip 1, 8, 10 (Einfachheit) |
| Extreme Programming (XP) | Technische Praktiken, Pair Programming, TDD | 5 bis 12 Personen | Prinzip 9 (technische Exzellenz) |
| SAFe | Skalierung in Konzernen, Programm-Inkremente | 50 bis 1000+ | Alle, mit Programm-Linse |
| LeSS | Skalierung mit minimalem Overhead | 50 bis 500 | Prinzip 10, 11 (Einfachheit, Selbstorganisation) |
| Spotify-Modell | Kultur, Tribes/Squads | Beliebig | Prinzip 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.