Skip to main content
← Zurück zur BibliothekMethoden

Scrum

Scrum ist ein agiles Rahmenwerk, das Teams mit festen Rollen, Events und Artefakten dabei unterstützt, komplexe Aufgaben in kurzen, iterativen Zyklen zu bearbeiten.

Scrum ist ein agiles Rahmenwerk zur Entwicklung und Steuerung komplexer Produkte, das ursprünglich aus der Softwareentwicklung stammt und heute in vielen Branchen eingesetzt wird. Es beruht auf dem Prinzip der empirischen Prozesssteuerung: Statt eine Aufgabe von Anfang bis Ende durchzuplanen, arbeitet ein Team in kurzen, festen Zeitabschnitten, den Sprints, die meist ein bis vier Wochen dauern. Nach jedem Sprint entsteht ein nutzbares Teilergebnis, das Feedback ermöglicht und die weitere Planung anpasst. Diese Kombination aus Transparenz, Überprüfung und Anpassung macht Scrum besonders geeignet für Vorhaben mit unsicheren oder sich ändernden Anforderungen.

Scrum legt drei feste Rollen fest. Der Product Owner verantwortet den Wert des Produkts und pflegt das Product Backlog, eine priorisierte Liste aller Anforderungen. Der Scrum Master sorgt dafür, dass das Team den Rahmen einhält, räumt Hindernisse aus dem Weg und moderiert die Zusammenarbeit, ohne selbst inhaltlich Aufgaben zuzuweisen. Das Entwicklungsteam plant und erledigt die Arbeit eigenverantwortlich. Vier feste Events strukturieren jeden Sprint: Sprint Planning zu Beginn, das tägliche Daily Scrum zur Abstimmung, das Sprint Review zur Präsentation des Ergebnisses und die Sprint Retrospektive zur Verbesserung der Zusammenarbeit.

Scrum eignet sich besonders für Aufgaben, deren Umfang oder Lösung zu Beginn noch nicht vollständig klar ist, etwa Produktentwicklung oder komplexe Projekte mit mehreren Beteiligten. Es unterscheidet sich von Kanban durch die festen Zeitzyklen und die klar definierten Rollen, während Kanban stärker auf einen kontinuierlichen Fluss ohne feste Iterationen setzt. Gegenüber klassischer Wasserfallplanung liegt der Vorteil in der regelmäßigen Überprüfung: Fehleinschätzungen fallen früh auf, nicht erst am Projektende. In der Praxis scheitert Scrum häufig nicht am Rahmenwerk selbst, sondern an halbherziger Umsetzung, etwa wenn Retrospektiven ausfallen oder das Backlog nicht gepflegt wird.

Praxisbeispiel

Ein mittelständischer Maschinenbauer entwickelt eine neue Software zur Anlagenüberwachung. Das fünfköpfige Team arbeitet in zweiwöchigen Sprints: Zu Sprint-Beginn wählt es aus rund 40 offenen Backlog-Einträgen die zehn wichtigsten aus, die im täglichen Daily Scrum von 15 Minuten abgestimmt werden. Nach zehn Sprints, also fünf Monaten, steht eine erste einsatzfähige Version bereit, statt wie ursprünglich geplant erst nach neun Monaten Entwicklung ohne Zwischenergebnis. Die Retrospektiven decken dabei auf, dass unklare Anforderungen in den ersten drei Sprints rund 20 Prozent der Kapazität gekostet haben, woraufhin der Product Owner das Backlog künftig genauer beschreibt.

So hilft Leanshift

Die Sprint Retrospektive ist im Kern nichts anderes als ein regelmäßiger Kaizen-Zyklus: Das Team hält kurz inne, blickt ehrlich auf den letzten Abschnitt zurück und verbessert gezielt die eigene Arbeitsweise, bevor es weitermacht. Das passt zur Leanshift-Haltung, Verbesserung nicht als einmaliges Projekt zu verstehen, sondern als feste, wiederkehrende Gewohnheit im Arbeitsalltag. Wer Scrum so lebt, verbessert nicht nur das Produkt, sondern befähigt das ganze Team, selbst zu Verbesserern zu werden.

Häufige Fragen

Ist Scrum nur für Softwareentwicklung geeignet?

Nein. Scrum stammt aus der Softwarebranche, wird inzwischen aber auch in Marketing, Produktentwicklung, Bildung und anderen Bereichen eingesetzt, überall dort, wo Aufgaben komplex sind und sich Anforderungen im Verlauf ändern können.

Wie unterscheidet sich Scrum von Kanban?

Scrum arbeitet in festen Zeitzyklen, den Sprints, mit definierten Rollen und Events. Kanban dagegen visualisiert einen kontinuierlichen Arbeitsfluss ohne feste Iterationen und legt den Fokus auf die Begrenzung gleichzeitiger Arbeit.

Braucht ein kleines Team wirklich einen eigenen Scrum Master?

Nicht zwingend als Vollzeitrolle. In kleinen Teams übernimmt die Aufgabe oft eine Person zusätzlich zur fachlichen Arbeit, wichtig ist nur, dass die Moderationsfunktion und die Einhaltung des Rahmens tatsächlich wahrgenommen werden.