Ansatz & Methode
Scrum ist ein leichtgewichtiges Framework, mit dem Menschen, Teams und Organisationen komplexe Probleme in kurzen, wiederkehrenden Zyklen bearbeiten. Rollen, Ereignisse und Artefakte sind bewusst minimal gehalten; die konkrete Praxis entsteht aus der Arbeit der Beteiligten.
Kurz gesagt
Scrum ist laut Scrum Guide ein leichtgewichtiges Framework, das Menschen, Teams und Organisationen dabei unterstützt, durch adaptive Lösungen Wert für komplexe Probleme zu erzeugen. Ein Scrum Team arbeitet in Sprints, also in kurzen Zyklen mit festem Rahmen. Drei Verantwortlichkeiten (Product Owner, Scrum Master, Developers), fünf Ereignisse und drei Artefakte bilden das Gerüst; wie die Arbeit im Einzelnen aussieht, entscheidet das Team selbst. Das Framework ist absichtlich unvollständig und entfaltet seine Wirkung nur vollständig umgesetzt.
Weitere Bezeichnungen: Scrum Framework · Scrum Guide
Diese beiden Listen beantworten die häufigste Frage zuerst: Wofür ist der Ansatz gedacht, und wann ist er die falsche Wahl? Alles Weitere auf dieser Seite vertieft genau diese Entscheidung.
Bei komplexer Arbeit ist zu Beginn nicht vollständig bekannt, was gebaut werden soll und welche Annahmen tragen. Ohne kurzen, verbindlichen Rhythmus werden Entscheidungen nach hinten verschoben, und Erkenntnisse aus der Umsetzung kommen zu spät zurück.
Wenn Ziele, Priorisierung und Arbeitsweise zwischen vielen Rollen unklar bleiben, entsteht Abstimmungsaufwand ohne Entscheidungswirkung. Scrum ordnet diese Fragen ausdrücklich drei Verantwortlichkeiten zu, statt sie informell zu lösen.
Scrum ist auf Empirie gegründet: Wissen entsteht aus Erfahrung und aus dem, was tatsächlich beobachtet wird. Transparenz, Inspektion und Anpassung sind die Mechanik, über die ein Sprint lernfähig bleibt.
Der Sprint ist ein Behälter mit festem Zeitrahmen, in dem alle anderen Ereignisse stattfinden. Der feste Rahmen erzeugt Vergleichbarkeit und macht Abweichungen sichtbar, statt sie in eine laufende Endlosplanung zu verschieben.
Das Scrum Team ist selbstorganisierend und arbeitet als eine Einheit. Product Owner ordnet den Backlog, Scrum Master fördert die Umsetzung des Frameworks, Developers erstellen das Increment.
Scrum beschreibt nur das Minimum an Regeln. Das Framework liefert keine Detailanweisungen, sondern einen Rahmen, den Teams mit eigenen Verfahren, Techniken und Erkenntnissen füllen.
Alle Arbeit findet in einem Sprint statt. Sein Zweck ist, ein nutzbares Increment zu erzeugen; ohne vereinbartes Sprintziel ändern sich Umfang und Annahmen fortlaufend.
In der Sprint Planning wird festgelegt, warum der Sprint wertvoll ist, was erreicht werden soll und wie die Arbeit aussehen wird. Ergebnis ist ein Sprint Backlog mit einem Sprintziel.
Im Daily Scrum prüft das Team den Fortschritt am Sprintziel und passt den Plan an. Der Sprint Review dient der Inspektion des Ergebnisses mit den Stakeholdern und der Anpassung des Product Backlogs.
Die Retrospektive betrachtet Qualität und Wirksamkeit der Zusammenarbeit und leitet konkrete Verbesserungen ab. Jedes Increment ist ein geprüfter Schritt in Richtung Product Goal und erfüllt die Definition of Done.
Verantwortet die Wertmaximierung am Produkt und ordnet das Product Backlog so, dass das Product Goal adressiert wird.
Verantwortet die Wirksamkeit des Scrum Teams und dafür, dass Scrum tatsächlich umgesetzt wird – nicht die Ergebnisse der Produktarbeit.
Erstellen in jedem Sprint ein nutzbares Increment, planen ihre Arbeit und verantworten Definition of Done und technische Qualität.
Beginnen Sie mit einem Vorhaben, das ein Team über mehrere Sprints eigenständig voranbringen kann, statt mit einer bereichsübergreifenden Gesamtorganisation.
Product Owner, Scrum Master und Developers werden als Verantwortungen besetzt – nicht als zusätzliche Aufgabe neben bestehenden Linienfunktionen.
Führen Sie alle Ereignisse in einem Sprint nach den Regeln des Scrum Guides durch und werten Sie danach aus, wo der feste Rahmen gebrochen wurde.
Nach mehreren Sprints lässt sich Scrum auf weitere Teams ausdehnen. Erhalten Sie dabei die vollständige Umsetzung, weil einzelne Elemente allein nicht Scrum sind.
Die Zuordnung stammt aus den strukturierten Methodenangaben der Profile und den ausgewiesenen Quellen.
Bild: agile.coach
Berlin, Deutschland
Certified Scrum Trainer®
Agile.Coach GmbH & Co. KG
Anton Skornyakov ist Certified Scrum Trainer® und seit 2008 im Bereich Agilität tätig. Er arbeitet als Coach und Trainer mit dem Schwerpunkt Scrum und ist in Berlin ansässig.
Bild: professionalscrum.ch
Schweiz
Professional Scrum Trainer
Value Talks
Ari Byland ist Professional Scrum Trainer bei Value Talks und arbeitet seit 2011 in der Schweiz. Seine Arbeit verbindet Scrum-Trainings mit Organisationsentwicklung, wobei er auf Methoden wie Scrum und Liberating Structures setzt.
Münster, Deutschland
Unternehmensberater im Bereich Agile-Leadership / Management 3.0 / Change-Management
Martin Reimer ist Unternehmensberater im Bereich Agile-Leadership, Management 3.0 und Change-Management mit Sitz in Münster. Er arbeitet mit den Methoden Management 3.0 und Scrum und ist in Deutschland, Österreich und der Schweiz tätig.
Bild: freelancermap.at
Rotenburg, Deutschland
Scrum Master, Coach, Trainer & Autor
Moritz Knüppel ist Scrum Master, Coach, Trainer und Autor mit Sitz in Rotenburg, Deutschland. Seit 2020 ist er beruflich in den Bereichen Beratung, Coaching und Training tätig, mit den Schwerpunkten Scrum und Kanban. Er arbeitet remote und ist in Deutschland, Zypern, Ungarn und Japan tätig.
Die Inhalte dieser Seite wurden eigenständig verfasst und anhand der folgenden öffentlichen Quellen geprüft.
Publikation
Ken Schwaber und Jeff Sutherland (ScrumGuides.org)
Quelle öffnenOffizielle Website
ScrumGuides.org
Quelle öffnenVergleiche Profile, die diesen Ansatz einsetzen – nach Rolle, Sprache und Zusammenarbeit.
Profile zum Ansatz ansehen