Das agile Manifest und seine 12 Prinzipien

Was das agile Manifest ist und warum es noch wichtig ist

Du kennst das agile Manifest wahrscheinlich. Aber ganz ehrlich: Wann hast du es dir das letzte Mal bewusst angesehen? Mir ist aufgefallen, dass ich es viel zu selten zur Hand nehme. Lass uns das ändern und gemeinsam einen genauen Blick darauf werfen, denn dieses Dokument ist das Fundament für alles, was wir in der agilen Welt tun.

Die Entstehung des Manifests

Stell dir vor: Im Jahr 2001, als schwerfällige Prozesse die Softwareentwicklung dominierten, gewannen leichtgewichtige Alternativen an Popularität. Dazu zählten vor allem Scrum,¹ maßgeblich geprägt von Ken Schwaber² und Jeff Sutherland,³ Extreme Programming (XP)⁴ von Vordenkern wie Kent Beck⁵ und Robert C. Martin,⁶ sowie die Crystal-Methodenfamilie⁷ von Alistair Cockburn.⁸

Genau die Vertreter dieser Strömungen – insgesamt 17 Pioniere – trafen sich im Februar 2001 in einem Ski-Resort in Utah. Sie wollten herausfinden, was ihre unterschiedlichen Ansätze im Kern verbindet und ob sie diese auf ein gemeinsames Fundament stellen können. Das Ergebnis dieser Diskussion war das „Manifest für Agile Softwareentwicklung“⁹

Die vier Kernwerte im Detail

Gehen wir die vier Werte des Manifests durch und was sie für deine tägliche Arbeit bedeuten.

1. Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Natürlich sind Prozesse und Werkzeuge wichtig. Sie geben Struktur und Unterstützung. Aber du solltest dich niemals hinter ihnen verstecken. Anstatt dich im stillen Kämmerlein stur an einen Prozess oder die Vorgaben eines Tools zu halten, sprich lieber direkt mit deinen Kollegen. Die direkte Interaktion zwischen Menschen ist entscheidend, um Herausforderungen zu lösen und wirklich gute Software zu entwickeln.

2. Funktionierende Software mehr als umfassende Dokumentation

Der eigentliche Wert entsteht durch eine Software, die funktioniert und die deine Nutzer verwenden können. Das ist die Existenzberechtigung für deine Arbeit. Eine Dokumentation ist zwar Teil des Entwicklungsprozesses, aber sie darf niemals nur Selbstzweck sein. Es geht hier nicht darum, keine Dokumentation zu schreiben. Vielmehr bedeutet es, dass du im Zweifel immer die funktionierende Software priorisieren solltest. Sie ist letztlich auch ein Teil ihrer eigenen Dokumentation.

3. Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen

Gerade in der Zusammenarbeit mit größeren Unternehmen stößt du auf feste Einkaufs- und Vertragsprozesse. Das ist aus deren Sicht auch verständlich. Doch es ergibt keinen Sinn, stur auf den Details eines Lasten- oder Pflichtenhefts zu beharren, wenn sich die Realität ändert. Auch dein Kunde lernt im Laufe des Projekts dazu. Was anfangs eine gute Idee schien, kann sich später als falsch herausstellen. In solchen Momenten ist es viel wertvoller, das Gespräch zu suchen und gemeinsam eine Lösung zu finden, anstatt auf die Buchstaben des Vertrags zu pochen.

4. Reagieren auf Veränderungen mehr als das Befolgen eines Plans

Ein Plan, den du vor drei Monaten erstellt hast, ist heute höchstwahrscheinlich veraltet. Das bedeutet nicht, dass du planlos arbeiten sollst. Im Gegenteil: Du solltest permanent planen. Lass neue Erkenntnisse und veränderte Rahmenbedingungen kontinuierlich in deine Planung einfließen. Wenn alle Beteiligten erkennen, dass eine Veränderung notwendig ist, ist es unsinnig, an einem alten Plan festzuhalten. Schau gemeinsam mit dem Kunden oder den Stakeholdern, was jetzt getan werden muss und wie ihr am besten auf die neue Situation reagiert.

Ein wichtiger Hinweis

Bei all diesen Vergleichen ist eines ganz entscheidend: Die Aspekte auf der rechten Seite – Prozesse, Dokumentation, Verträge und Pläne – sind nicht unwichtig! Aber die Werte auf der linken Seite sind in der agilen Arbeitsweise wichtiger. Als nächstes sollten wir auf die Ergänzung zum agilen Manifest schauen.

12 Agile Prinzipien

Die 17 Autoren haben es damals nicht bei den vier Kernwerten belassen. Sie haben das Manifest mit zwölf Prinzipien¹⁰ konkretisiert, um es greifbarer und im Alltag anwendbar zu machen. Schauen wir mal rein.

1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.

Es geht darum, dem Kunden so früh wie möglich etwas Funktionierendes in die Hand zu geben. Das erreichst du, indem du deine Aufgaben (oder User Stories) so klein wie möglich hältst und sicherstellst, dass jede kleine Lieferung für sich genommen einen in sich abgeschlossenen Wert hat. So erhältst du wertvolles Feedback – vom Kunden, von dessen Nutzern oder sogar aus Analytics-Daten. Dieses Feedback lässt du direkt in die Weiterentwicklung einfließen und machst die Software Stück für Stück wertvoller.

2. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

Hier steht der Nutzen für den Kunden im Mittelpunkt. Du entwickelst keine Software im luftleeren Raum, und Änderungen sind willkommen, weil sie bedeuten, dass alle Beteiligten im Projektverlauf schlauer werden. Diese neuen Erkenntnisse nutzt du, um dem Kunden einen echten Wettbewerbsvorteil zu verschaffen. Ich weiß, je nach Vertragsgestaltung können Änderungen schwierig sein. Das ist aber ein Anlass, über andere Vertragsmodelle nachzudenken, anstatt wertvolle Änderungen abzulehnen.

3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.

Der Gedanke dahinter ist klar: Du willst einen hohen Durchsatz, frühes Feedback und die Gewissheit, dass deine Ideen in der Praxis funktionieren. Das geht über den reinen MVP-Gedanken hinaus. Indem du über das gesamte Projekt hinweg regelmäßig kleine, funktionierende Versionen lieferst, stellst du vielleicht sogar fest, dass du gar nicht alles entwickeln musst, was ursprünglich geplant war. Oft reichen 80% des ursprünglichen Umfangs aus, weil du durch das frühe Feedback gelernt hast, was wirklich zählt.

4. Fachexperten und Entwickler müssen während des Projekts täglich zusammenarbeiten.

Die Fachexperten sind in der Regel deine Kunden und Stakeholder oder auch Kollegen aus anderen Bereichen wie dem Design. Zugegeben, “täglich” ist in der Praxis oft nicht umsetzbar, da auch der Kunde nicht jeden Tag Zeit hat. Das Ideal ist jedoch ein möglichst enger und regelmäßiger Austausch. Versuche, deinem Team den direkten Draht zum Kunden zu ermöglichen. Wenn dieser Austausch funktioniert, ist der Mehrwert riesig.

5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie ihre Aufgaben erledigen.

Dieser Punkt, besonders der letzte Teil – das Vertrauen –, ist in der Praxis eine der größten Hürden. Ich gehe grundsätzlich davon aus, dass Menschen, die an einem Projekt arbeiten, motiviert sind. Wenn nicht, sind es vielleicht die falschen Leute für das Team. Wenn du aber motivierte Individuen hast, musst du ihnen ein Umfeld schaffen, in dem sie dieses Engagement auch einbringen können. Das bedeutet, ihnen Unterstützung zu geben und vor allem darauf zu vertrauen, dass sie ihre Arbeit erledigen. Dieses Vertrauen ist, wie wir in Teil II sehen werden, die vielleicht wichtigste Aufgabe von moderner Führung.

6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

Direkte und synchrone Kommunikation über die aktuelle Arbeit ist viel effektiver, als asynchrones schriftliches Diskutieren. Das ist auch ein Grund, warum das Daily Scrum ein so wichtiges Event im Framework ist. Außerdem: Dieses Prinzip stammt aus dem Jahr 2001, lange vor der Corona-Pandemie 2020 und der sich seit dem festigenden Homeoffice-Kultur. Dennoch ist es aktueller denn je. Auch wenn Videoanrufe heute Standard sind, geht bei der reinen Online-Kommunikation unglaublich viel verloren. Es ist etwas völlig anderes, gemeinsam in einem Raum vor einem Whiteboard zu stehen und eine Idee zu diskutieren. Der direkte Dialog bleibt unschlagbar, um komplexe Informationen effizient zu übermitteln und ein gemeinsames Verständnis zu schaffen.

7. Funktionierende Software ist das wichtigste Fortschrittsmaß.

Lass diesen Satz auf dich wirken. Dein Fortschritt wird nicht an der “Velocity” oder in komplexen Fortschrittsbalken gemessen. Das einzig wahre Maß ist der Teil der Software, der tatsächlich funktioniert und ausgeliefert werden kann. Halbfertige Funktionen zählen nicht. Das macht diesen Maßstab so ehrlich und verlässlich.

8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

Viele Menschen assoziieren “agil” fälschlicherweise mit “schnell”. Doch agil bedeutet “beweglich”. Es geht nicht darum, in Sprints zu hetzen. Deine Arbeit sollte eher einem Dauerlauf oder einem entspannten Spaziergang gleichen. Das Ziel ist ein gleichmäßiges, nachhaltiges Tempo, das alle Beteiligten auf unbegrenzte Zeit durchhalten können, ohne auszubrennen.

9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.

Wenn du kontinuierlich darauf achtest, dass deine technische Basis sauber und deine Softwarearchitektur (das “Design”) durchdacht ist, schaffst du die Voraussetzung für Beweglichkeit. Nur mit einer exzellenten technischen Grundlage kannst du schnell und sicher auf Umweltveränderungen reagieren, ohne dass dir alles um die Ohren fliegt.

10. Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.

Der größte Erfolg für ein Unternehmen liegt darin, so wenig wie möglich zu tun, um ein Ziel zu erreichen. Das ist eine hohe Kunst. Es bedeutet, ständig zu reflektieren, was gut funktioniert hat und wo “Waste” (Verschwendung) produziert wurde. Indem du kontinuierlich daran arbeitest, Unnötiges wegzulassen, maximierst du den Wert deiner Arbeit.

11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.

Selbstorganisierte Teams sind das große Ziel. Doch der Weg dorthin ist harte Arbeit für alle Beteiligten. Es berührt technische, organisatorische und vor allem menschliche Aspekte wie Verantwortungsübernahme und eine gesunde Fehlerkultur. Aber das Ergebnis ist es wert: Wenn ein Team sich selbst organisiert, entstehen die besten und nachhaltigsten Lösungen. Genau diese Herausforderung schauen wir uns in Teil II noch ganz genau an.

12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.

Die bekannteste Form hierfür ist die Retrospektive. Aber Reflexion ist mehr als nur die Retro. Sie findet im Kleinen bei der Test-Driven Development statt, in “Lessons Learned”-Sessions oder in Formaten wie einem Open Space. Nur wenn du und dein Team regelmäßig innehaltet, um zu reflektieren und daraus Anpassungen abzuleiten, könnt ihr euch wirklich verbessern.

Wenn du dir diese zwölf Prinzipien ansiehst, wird klar, wie praxisnah und relevant sie auch heute noch sind. Ähnlich wie das Manifest selbst geraten sie im Alltag jedoch oft in den Hintergrund. Überlege dir, wie du diese Prinzipien für dich und dein Team präsent halten kannst. Sie sind der perfekte Kompass, besonders dann, wenn ihr Entscheidungen treffen müsst.

Du hast die Werte und Prinzipien jetzt wieder frisch im Kopf. Als Nächstes geht’s darum, warum ohne das richtige Mindset jede Methode zum Theater verkommt.

Quellen

1. Sutherland, Jeff, und J. J. Sutherland. Scrum: the art of doing twice the work in half the time. Revised and updated edition. Penguin Books, 2024.↩︎

2. „Ken Schwaber“. In Wikipedia. 2025. https://en.wikipedia.org/w/index.php?title=Ken_Schwaber&oldid=1304718705.↩︎

3. „Jeff Sutherland“. In Wikipedia. 2025. https://en.wikipedia.org/w/index.php?title=Jeff_Sutherland&oldid=1311551395.↩︎

4. Beck, Kent, und Cynthia Andres. Extreme programming explained: embrace change. 2. ed., 11. print. The XP Series. Addison-Wesley, 2012.↩︎

5. „Kent Beck“. In Wikipedia. 2025. https://en.wikipedia.org/w/index.php?title=Kent_Beck&oldid=1312048143.↩︎

6. „Robert C. Martin“. In Wikipedia. 2025. https://en.wikipedia.org/w/index.php?title=Robert_C._Martin&oldid=1307213143.↩︎

7. Cockburn, Alistair. Crystal clear: a human-powered methodology for small teams. The agile software development series. Addison-Wesley, 2005.↩︎

8. „Alistair Cockburn“. In Wikipedia. 2025. https://en.wikipedia.org/w/index.php?title=Alistair_Cockburn&oldid=1303150136.↩︎

9. Manifest für Agile Softwareentwicklung. o. J. Zugegriffen 15. Oktober 2025. https://agilemanifesto.org/iso/de/manifesto.html.↩︎

10. Prinzipien hinter dem Agilen Manifest. o. J. Zugegriffen 15. Oktober 2025. https://agilemanifesto.org/iso/de/principles.html.↩︎