Scrum (Framework)

Scrum ist ein weit verbreitetes agiles Framework, das ursprünglich aus der Softwareentwicklung kommt und bis in das Jahr 1995 auf Ken Schwaber und Jeff Sutherland zurückzuführen ist. Es basiert auf der Idee, dass komplexe Aufgaben am besten in kurzen, iterativen Zyklen bearbeitet werden, die kontinuierlich verbessert und angepasst werden. Das Wort "iterativ" meint dabei die Anpassung in wiederholenden häufigen Zyklen.

Durch regelmäßige Feedbackschleifen und enge Zusammenarbeit zwischen den Teammitgliedern sorgt Scrum für eine hohe Flexibilität und schnelle Anpassung an sich verändernde Anforderungen. Dadurch unterscheidet es sich vom klassischen Projektmanagement, in dem mit einem starren Plan zwischen einem Anfang- und Endzeitpunkt gearbeitet wird. 

Die drei Säulen von Scrum beziehen sich auf Transparenz (erste Säule), die eine Überprüfung (zweite Säule) der einzelnen Ziele und somit eine Anpassung (dritte Säule) von festgestellten Abweichungen des Zielzustandes ermöglicht. 

Das Scrum-Framework beinhaltet verschiedene Elemente, deren Begriffe nachfolgend erläutert werden:

• Werte: Die erfolgreiche Nutzung des Scrum-Frameworks basiert auf den fünf agilen Werten 1) Commitment 2) Fokus 3) Offenheit 4) Respekt 5) Mut, die durch die beteiligten Personen gelebt werden müssen.
• Rollen: Die drei Hauptrollen im Scrum sind Product Owner, Scrum Master und mehrere Developer (das Entwicklungsteam). Zusammen bilden sie das Scrum Team.
• Artefakte: Scrum verwendet sogenannte Artefakte, also verschiedene Schritte, wie das Product Backlog, das Sprint Backlog und das Inkrement, um den Fortschritt und die Anforderungen zu dokumentieren. Das Inkrement wird stets in Hinblick auf die "Definition of Done", also dem Zielzustand, weiterentwickelt.
• Ereignisse: Es gibt verschiedene regelmäßige Ereignisse („Events“), darunter das Sprint Planning, das Daily Scrum, die Sprint Review und die Sprint Retrospective.

Die einzelnen Personen im Scrum-Zyklus arbeiten in den nachfolgend dargestellten Rollen, ohne Hierarchien und selbstständig mit einer kollektiven Intelligenz aus Personen, die diverse Fachkenntnisse- und Kompetenzen abdecken. Die wichtigsten Rollen sind nachfolgend aufgeführt:

1. Product Owner
   Der Product Owner ist verantwortlich für die Verwaltung und Priorisierung des Product Backlogs, das alle Anforderungen und Aufgaben des Projekts enthält. Diese Person stellt durch die transparente und klare Kommunikation und Organisation des Product Backlogs sicher, dass die Developer an den wertvollsten Aufgaben arbeiten und sorgt dafür, dass das Produkt den Erwartungen der Stakeholder entspricht. Der Product Owner trägt die Verantwortung für das Erreichen der Produktziele.
2. Scrum Master
   Der Scrum Master unterstützt bei der Einführung des Scrum-Frameworks, indem er überwacht, dass die Scrum-Prinzipien und  -Prozesse befolgt werden. Die Person hilft dabei, Hindernisse (so genannte „Impediments“) zu beseitigen, die den Fortschritt des Teams behindern könnten, und fördert kontinuierliche Verbesserungen im Team. Stets in Hinblick auf die Scrum-Theorie und  -Praxis. Zudem unterstützt der Scrum Master den Product Owner und das Team bei der optimalen Zusammenarbeit.
3. Developer
   Die Mitglieder des Entwicklungsteams, so genannte Developer, arbeiten gemeinsam ergebnisorientiert an dem Produktinkrementen. Sie sind selbstorganisiert und interdisziplinär. Durch die tägliche Planung mit Hilfe des Sprint-Backlogs entscheidet das Team selbst, wie es die Arbeit am besten erledigen kann und arbeitet mit hoher Qualität unter Berücksichtigung der Definition of Done.

Ein Sprint wird häufig als das Herzstück eines Scrum-Zyklus bezeichnet. Ein Sprint ist ein kurzes, zeitlich festgelegtes Intervall (in der Regel ein bis vier  Wochen), in dem ein funktionsfähiges Produktinkrement entwickelt wird. Weitere Ereignisse sorgen für Transparenz und kontinuierliches Feedback: 

1. Jeder Sprint beginnt mit einem Sprint Planning (max. acht Stunden). Bei dem Termin legt das Team mit dem Product Owner fest, welche Aufgaben aus dem Product Backlog in diesem Sprint bearbeitet werden sollen. Das Product Backlog enthält alle Anforderungen, die im Verlauf des Projekts bearbeitet werden müssen, und wird vom Product Owner kontinuierlich gepflegt und priorisiert. Während des Sprints arbeitet das Scrum Team am Sprint Backlog, einer detaillierten Liste von Aufgaben, die für den Sprint vorgesehen sind.
2. Daily Scrum: In diesem täglichen, maximal 15-minütigen Termin wird das Sprint Backlog angepasst, der aktuelle Sachstand wird berichtet. Hier darf auch das Entwicklungsteam seine Ziele im Sprint-Backlog anpassen.
3. Sprint Review: Am Ende eines Sprints wird das Produktinkrement den Stakeholdern präsentiert und bewertet. In der Review (max. vier Stunden) geht es um die inhaltliche Betrachtung des Inkrements.
4. Sprint Retrospective: Nach jedem Sprint reflektiert das Team über den Arbeitsprozess und identifiziert Verbesserungspotenziale. In der Retro (max. drei Stunden) geht es explizit um die Zusammenarbeit, Qualitätsverbesserung und Effizienz für die zukünftigen Zyklen.

1. Flexibilität und Anpassungsfähigkeit
   Scrum ermöglicht es Teams, schnell auf Veränderungen zu reagieren. Da es auf regelmäßigen Feedbackschleifen basiert, können sich die Anforderungen im Verlauf eines Projekts ändern, ohne dass das gesamte Projekt gefährdet wird.
2. Transparenz und Kommunikation
   Durch regelmäßige Meetings und die Visualisierung des Fortschritts (z. B. durch Burndown Charts) wird der Arbeitsprozess transparent. Alle Teammitglieder und Stakeholder sind stets über den aktuellen Stand informiert.
3. Kontinuierliche Verbesserung
   Die Sprint Retrospective fördert eine Kultur der kontinuierlichen Verbesserung. Jedes Teammitglied hat die Möglichkeit, Feedback für die Optimierung des Arbeitsprozesses einzubringen.
4. Engagierte Teamarbeit
   Scrum fördert eine hohe Eigenverantwortung und Selbstorganisation in Teams. Dies steigert nicht nur die Motivation der einzelnen Teammitglieder, sondern auch die Qualität der Arbeitsergebnisse durch eine diverse Zusammensetzung verschiedener Personen mit unterschiedlichen Fachkenntnissen.

Immer wieder betonen Anwendende, dass Scrum starr oder dogmatisch sei. Das Framework im Scrum Guide ist über mehrere Versionen gewachsen, Erfahrungen von zehntausenden Teams sind eingeflossen. Schwaber und Sutherland passten die Regeln anhand von Rückmeldungen immer wieder an und überprüften sie auf Erfolg. Inzwischen hat sich im Guide der Kanon mit den oben beschriebenen zentralen Bausteinen auf ein Minimum begrenzt. Diese können zwar angepasst werden, das Framework Scrum verliert jedoch somit seine beabsichtigte Wirkung.

Scrum hat seine große Stärke und Hebelwirkung in Entwicklungsaufgaben für Teams, die sich ganz auf diese Tätigkeit konzentrieren können. Kann ein Team nicht jeden Tag mit dem Framework arbeiten, ergibt es wenig Sinn, in einem Daily zusammen zu kommen.

Das Framework setzt das Scrum Team mit seiner Selbstorganisation und flachen Hierarchie ein, um den Beteiligten größtmögliche Freiheit und Kreativität zu ermöglichen. Einflüsse und Ansprüche von außen hält die Person mit der Scrum-Master-Rolle fern. Das bedeutet zugleich, dass diese Rolle innerhalb der Organisation Rückhalt und das Mandat benötigt, starre Hierarchien müssen aufgebrochen werden.

Für langfristige Veränderungen und Planungen bietet Scrum keine Lösungen, auch für parallele Teams ist im Scrum Guide keine Aussage vorhanden. Das liegt daran, dass Scrum sich auf das Wesentliche fokussiert und ein Framework für (Software-)Entwicklungen ist. In Kombination mit strategischen Frameworks wie Objectives and Key Results (OKR) oder Hoshin Kanri kann Scrum bei der Umsetzung eingesetzt werden. Für mehrere Scrum-Teams wurde Large-scale Scrum (LeSS) entwickelt.

Schwaber, K. & Sutherland, J. (2020). The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game. https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf

Deutsche Version zu finden unter: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-German.pdf