METHODE

Scrum

Ein agiles Framework, das Arbeit in feste Sprints gliedert, mit definierten Rollen, Events und Artefakten für einen engen Liefer- und Inspektionszyklus.

Zuletzt geprüft: vonKevin Riedl wiki ↗

Scrum hat drei Rollen, drei Artefakte und eine Handvoll Events. Der Product Owner entscheidet, was gebaut wird und in welcher Reihenfolge. Der Scrum Master räumt Blockaden aus dem Weg und schützt den Prozess. Die Entwickler bauen es. Die Artefakte sind das Product Backlog (alles, was gebaut werden könnte), das Sprint Backlog (worauf sich dieser Sprint festlegt) und das Increment (was tatsächlich ausgeliefert wird). Die Events sind Sprint Planning, der Daily Standup, das Sprint Review und die Retrospektive.

Wo Scrum wirklich hilft: bei Teams, die mit Fokus und Sichtbarkeit kämpfen. Der feste Sprint erzwingt eine echte Festlegung, das Review erzwingt eine echte Demo, und die Retro zwingt das Team, den eigenen Prozess anzuschauen statt ihn zu ignorieren. Für ein Team, das noch nie in einem Takt geliefert hat, ist Scrum ein nützliches Gerüst.

Wo es zum Theater wird: wenn die Events überleben, aber die Substanz stirbt. Ein Standup, der ein Statusbericht an den Manager ist. Ein Review ohne lauffähige Software zum Zeigen. Eine Retro, die alle zwei Wochen dieselben drei Maßnahmen produziert und keine davon umsetzt. Viele Scrum-Teams führen die Zeremonien durch und holen keinen Wert daraus. Wenn ihr die Meetings macht, aber kein lauffähiges Increment demonstrieren könnt, habt ihr kein Scrum, sondern eine Meeting-Gewohnheit.

Praxisbeispiel für die Overhead-Falle: Ein fünfköpfiges Team führt Scrum nach Lehrbuch ein und landet bei Sprint Planning, einem Daily Standup, einer Backlog-Refinement-Session, einem Sprint Review und einer Retro alle zwei Wochen. Bei dieser Teamgröße kann diese Zeremonienlast gut den größeren Teil eines Tages pro Woche und Person fressen, und die Planungspräzision, die sie erkauft, ist verschwendet, weil ein fünfköpfiges Team ohnehin weiß, was alle tun. Das Framework wurde entworfen, um Teams zu koordinieren, die diese Sichtbarkeit verloren hatten; alles davon einem Team aufzuzwingen, das sie nie verloren hat, ist reine Steuer. Die Lösung ist nicht, die Feedback-Schleifen aufzugeben (behaltet die Demo und die Retro), sondern die Koordinationszeremonien zu streichen, die ein Problem lösen, das ihr nicht habt.

Wavects ehrliche Sicht: Scrum ist ein gutes Einstiegs-Framework und eine schlechte Religion. Behaltet die Teile, die Feedback erzeugen, und lasst die Teile weg, die Overhead erzeugen. Die meisten reifen Teams driften zu etwas Leichterem, oft näher an Kanban, sobald die Disziplin verinnerlicht ist.

// FAQ

Häufige Fragen

Ein agiles Framework, das Arbeit in feste Sprints abwickelt, mit drei Rollen (Product Owner, Scrum Master, Entwickler), drei Artefakten (Product Backlog, Sprint Backlog, Increment) und vier Events (Planning, Standup, Review, Retro). Das Ziel ist ein enger Bau- und Inspektionszyklus, nicht die Meetings selbst.
Scrum bündelt Arbeit in feste Sprints mit einer Festlegung und einem Review an jeder Grenze. Kanban läuft als kontinuierlicher Fluss mit WIP-Limits und ohne feste Iterationen. Wählt Scrum, wenn ein Team die Struktur eines Takts braucht, um Lieferdisziplin aufzubauen. Wählt Kanban, wenn Arbeit unvorhersehbar eintrifft oder das Team reif genug ist, den Fluss ohne Gerüst zu steuern.
Wenn die Zeremonien laufen, aber nichts produzieren. Ein Standup, der zum Statusmeeting wurde, ein Review ohne Demo, eine Retro, die nichts ändert. Wenn ihr am Ende eines Sprints kein lauffähiges Increment zeigen könnt, ist das Framework Theater, und ihr solltet die Substanz reparieren, nicht mehr Prozess hinzufügen.