Agiles Manifest

Was ist das Agile Manifest?

Das Manifest für Agile Softwareentwicklung entstand im Februar 2001 bei einem Treffen von 17 Softwarepraktikern in Snowbird im US-Bundesstaat Utah. Die Beteiligten kamen aus unterschiedlichen Ansätzen wie Extreme Programming, Scrum, DSDM, Crystal und Feature-Driven Development. Ihr Ziel war nicht, ein neues einheitliches Prozessmodell zu erfinden, sondern Gemeinsamkeiten in ihren Erfahrungen mit leichteren, anpassungsfähigeren Formen der Softwareentwicklung zu formulieren.

Das Ergebnis waren vier Wertpaare. Der entscheidende Satz des Manifests wird dabei häufig übersehen: Die jeweils rechts genannten Aspekte haben weiterhin einen Wert – die Aspekte auf der linken Seite werden lediglich höher gewichtet. Agilität bedeutet deshalb weder „keine Prozesse“ noch „keine Dokumentation“ oder „keine Planung“.

Die vier Werte des Agilen Manifests

Das Manifest stellt vier Prioritäten gegenüber:

• Individuen und Interaktionen werden höher gewichtet als Prozesse und Werkzeuge.
• Funktionierende Software wird höher gewichtet als umfassende Dokumentation.
• Zusammenarbeit mit dem Kunden wird höher gewichtet als Vertragsverhandlung.
• Reagieren auf Veränderung wird höher gewichtet als das Befolgen eines Plans.

Diese Aussagen sind keine Verbote der rechten Seite. Ein reguliertes Projekt kann beispielsweise umfangreiche Dokumentation benötigen und trotzdem agil arbeiten. Relevant ist, ob Dokumentation dem Produkt und der Zusammenarbeit dient oder selbst zum dominierenden Projektzweck wird.

Warum gehören die zwölf Prinzipien unbedingt dazu?

Die vier Werte sind sehr kompakt und können leicht zu Schlagworten verkürzt werden. Die zwölf Prinzipien konkretisieren deshalb, was die Autoren darunter verstanden. Sie betonen unter anderem frühe und kontinuierliche Lieferung wertvoller Software, den konstruktiven Umgang mit geänderten Anforderungen, enge Zusammenarbeit zwischen Fachseite und Entwicklung, nachhaltiges Arbeitstempo, technische Exzellenz, Einfachheit sowie regelmäßige Reflexion und Anpassung.

Gerade für die Praxis sind diese Prinzipien oft hilfreicher als die vier bekannten Wertpaare. Wer beispielsweise täglich Stand-ups durchführt, aber über Monate keine nutzbare Software liefert, erfüllt zwar eine verbreitete agile Praxis, aber nicht automatisch den im Manifest beschriebenen Gedanken früher Wertlieferung.

Das Agile Manifest ist keine Methode

Das Manifest legt weder Rollen noch Meetings, Artefakte oder Projektphasen fest. Es schreibt keinen Product Owner, keinen Sprint, kein Kanban Board und keine User Story vor. Solche Elemente stammen aus konkreten Frameworks oder Praktiken.

Deshalb ist die Aussage „Wir arbeiten nach dem Agilen Manifest“ allein noch keine Beschreibung eines Entwicklungsprozesses. Ein Team benötigt weiterhin konkrete Regeln für Priorisierung, Qualitätsarbeit, Zusammenarbeit, Architektur, Auslieferung und Entscheidungsfindung.

Wie hängen Scrum, Kanban und SAFe mit dem Manifest zusammen?

Scrum bietet einen konkreten Rahmen mit Verantwortlichkeiten, Events und Artefakten. Kanban fokussiert die Definition und Verbesserung von Workflow und Flow. SAFe adressiert die Koordination größerer Organisationen. Keiner dieser Ansätze ist mit dem Agilen Manifest identisch.

Gerade bei skalierten Frameworks lohnt sich diese Trennung: Mehr Rollen, Planungsebenen und Koordinationsmechanismen können organisatorisch notwendig sein, sollten aber daran gemessen werden, ob sie weiterhin schnelle Rückkopplung, Wertlieferung und Anpassungsfähigkeit unterstützen. Empirische Forschung von Kuhrmann et al. zeigt zudem, dass Agilität in der Praxis nicht allein aus dem Namen einer Methode abgeleitet werden kann; die tatsächlich eingesetzten Praktiken und der Kontext spielen eine wesentliche Rolle.

Typische Missverständnisse

„Agil bedeutet, nicht zu planen.“

Das Manifest wertet das Reagieren auf Veränderung höher als das Befolgen eines Plans. Es erklärt Planung nicht für wertlos. Sinnvoll ist vielmehr eine Planung, die bei neuen Erkenntnissen angepasst werden darf.

„Agil bedeutet, keine Dokumentation zu schreiben.“

Auch das ist falsch. Funktionierende Software wird höher gewichtet als umfassende Dokumentation. Notwendige Architekturentscheidungen, Anforderungen, Betriebswissen, Sicherheitsdokumentation oder regulatorische Nachweise können weiterhin zentral sein.

„Scrum ist die Definition von agil.“

Scrum ist ein möglicher Rahmen. Das Manifest ist breiter. Teams können agile Prinzipien mit anderen Vorgehensweisen umsetzen, und ein Team kann Scrum-Events formal durchführen, ohne besonders anpassungsfähig zu arbeiten.

Wie lässt sich das Manifest im Unternehmen sinnvoll nutzen?

Statt „agil“ als Label einzuführen, kann das Manifest als Prüfraster für konkrete Arbeitsweisen dienen:

• Wie schnell entsteht ein prüfbarer Nutzen für Nutzer oder Fachbereiche?
• Wie früh erhalten wir Feedback?
• Können Erkenntnisse den Plan tatsächlich verändern?
• Arbeiten Fachseite und Entwicklung eng genug zusammen?
• Unterstützen Prozesse die Arbeit – oder wird vor allem der Prozess bedient?
• Bleibt technische Qualität hoch genug, um auch künftig schnell ändern zu können?

Damit wird das Manifest weniger zu einem historischen Poster und mehr zu einer Grundlage für die Bewertung realer Entwicklungs- und Organisationsentscheidungen.

Fazit

Das Agile Manifest ist der Werte- und Prinzipienrahmen, aus dem sich die moderne agile Softwareentwicklung historisch stark entwickelt hat. Es liefert bewusst keine fertige Projektmethode. Sein Wert liegt gerade darin, konkrete Prozesse, Frameworks und Praktiken immer wieder an einem grundlegenden Ziel zu messen: funktionierende Lösungen in enger Zusammenarbeit zu entwickeln, früh Wert zu liefern und auf neue Erkenntnisse reagieren zu können.