Ich habe heute zufällig eine Grafik gesehen, die oft gezeigt wird, wenn jemand Scrum erklärt. Ein großer Kreis mit einem kleineren Kreis darin, der sich hineinschraubt. Der Sprint dreht sich, der Daily Stand-Up dreht sich darin. Darunter ein Fließband: Backlog, Planning, Sprint-Backlog, Sprint, Finished Work. Von links nach rechts.
Eine Schnecke.
Die Schnecke ist kein schlechtes Tier. Sie ist beständig, anpassungsfähig, kommt ans Ziel. Aber agil? Nicht das erste Wort, das einem einfällt. Und doch trägt die bekannteste Visualisierung eines der einflussreichsten agilen Frameworks ihr Bild.
Das hat mich zum Nachdenken gebracht.
Was das Manifest wollte
2001 trafen sich siebzehn Softwareentwickler in Snowbird, Utah. Sie waren frustriert – nicht von der Softwareentwicklung selbst, sondern von dem, was drumherum entstanden war: schwerfällige Prozesse, dicke Dokumente, Pläne, die der Realität nie standhielten. Sie schrieben das Agile Manifest.
Es hat 68 Wörter.
Vier Werte, zwölf Prinzipien. Kein Prozess. Keine Rollen. Keine Zeremonien. Keine Grafiken. Eine Haltung.
Der erste Wert lautet: Individuen und Interaktionen vor Prozesse und Werkzeuge.
Das ist keine Ablehnung von Prozessen. Es ist eine Priorisierung. Prozesse und Werkzeuge haben ihren Platz – aber sie dienen den Menschen, nicht umgekehrt. Das Team entscheidet, wie es arbeitet. Nicht das Framework, nicht das Management, nicht eine Grafik mit einer Schnecke darin.
Das klingt selbstverständlich. Ist es aber nicht. Denn genau diese Priorisierung geht verloren, wenn aus einer Haltung ein Prozess wird – und aus einem Prozess eine Vorschrift.
Scrum als Werkzeug
Scrum ist ein gutes Framework. Es ist durchdacht, in sich konsistent und hat sich in vielen Teams bewährt. Es gibt klare Rollen – Product Owner, Scrum Master, Entwicklungsteam. Klare Artefakte – Backlog, Sprint-Backlog, Increment. Klare Ereignisse – Planning, Daily, Review, Retrospektive.
Das ist kein Fehler. Das ist der Zweck eines Frameworks.
Ich denke dabei an Symfony. Symfony ist ein gutes Framework. Wer es vollständig einsetzt und damit klarkommt, hat eine solide Basis. Wer nur einzelne Komponenten braucht – den Mailer, den Validator oder die Console – nimmt sich, was er braucht, und lässt den Rest. Symfony erlaubt Komposition.
Scrum ist anders. Der Scrum Guide ist explizit: Wer Teile weglässt, macht kein angepasstes Scrum – er macht etwas anderes. Das ist keine Schwäche des Teams, sondern eine Eigenschaft des Frameworks. Scrum ist als Ganzes gedacht.
Das bedeutet nicht, dass ein Team Scrum vollständig einsetzen muss. Es bedeutet nur, dass es dann ehrlich sein sollte: Wenn ein Team Zeremonien weglässt, Rollen zusammenlegt oder den Rhythmus verändert, dann macht es kein Scrum mehr. Es macht etwas Eigenes. Und das ist völlig in Ordnung.
Softwareframeworks optimieren Anpassbarkeit. Prozessframeworks optimieren Einheitlichkeit. Beides hat seinen Platz – aber es verfolgt unterschiedliche Ziele.
Das Missverständnis
Das Problem entsteht nicht, wenn ein Team Scrum einsetzt. Es entsteht, wenn Scrum von oben verordnet wird – wenn „wir machen jetzt Scrum“ eine organisatorische Entscheidung ist und keine des Teams.
Nicht aus böser Absicht, sondern aus dem Wunsch nach Planbarkeit.
Frameworks versprechen Struktur. Struktur verspricht Vorhersagbarkeit. Und Vorhersagbarkeit beruhigt Organisationen. Agilität dagegen beginnt oft mit Unsicherheit: Entscheidungen werden näher ans Team verlagert, Pläne werden verhandelbar, Richtung kann sich ändern.
Es ist verständlich, dass Organisationen zuerst das Framework einführen – und erst später versuchen, die Haltung zu verstehen.
Doch damit kehrt sich der erste Wert des Manifests um: Nicht Individuen und Interaktionen vor Prozesse und Werkzeuge, sondern der Prozess vor das Team. Die Schnecke dreht sich, aber niemand hat gefragt, ob das Team eine Schnecke wollte.
„Wir machen Scrum, also sind wir agil“ ist eine bequeme Schlussfolgerung. Sie erspart die unbequemere Frage: Reagieren wir wirklich auf Veränderung? Liefern wir früh? Hören wir dem Kunden zu? Ändern wir die Richtung, wenn es nötig ist?
Ein Team, das diese Fragen mit Ja beantwortet und dabei kein einziges Scrum-Artefakt verwendet, ist agiler als ein Team, das jeden Sprint perfekt durchführt und sich nie fragt, ob es das Richtige baut.
Was bleibt
Die Schnecke ist kein falsches Bild für Scrum. Beständigkeit, Rhythmus, Schritt für Schritt – das sind keine schlechten Eigenschaften für ein Entwicklungsteam. Aber Beständigkeit ist nicht Agilität.
Agilität ist eine Haltung. Sie entsteht nicht durch ein Framework – sie entsteht durch ein Team, das sich einigt, wie es arbeiten will. Das kann Scrum sein. Oder Kanban. Oder etwas dazwischen. Oder etwas, das noch keinen Namen hat.
Das Manifest schreibt kein Framework vor. Es schreibt vor, dass das Team entscheidet.
Die Schnecke – sie trägt ihr Haus selbst.