Scrum

Scrum ist ein leichtgewichtiges agiles Framework, das Teams und Organisationen hilft, adaptive Lösungen für komplexe Probleme zu entwickeln und Wert zu schaffen. Ursprünglich aus der Softwareentwicklung stammend, setzt es iterative Sprints von einem Monat oder weniger ein, um funktionsfähige Produktinkremente zu erstellen. Scrum basiert auf empirischen Prinzipien und Lean Thinking, um Transparenz, Inspektion und Anpassung zu fördern. Es unterstützt selbstorganisierte Zusammenarbeit in cross-funktionalen Teams.

Hintergrund und Prinzipien

Scrum entstand 1995 durch Ken Schwaber und Jeff Sutherland als Antwort auf Herausforderungen komplexer Softwareprojekte. Der Name stammt aus der Rugbysprache und bezeichnet ein Gedränge, das sich dynamisch anpasst – kein Akronym, sondern ein Begriff für kollaborative, adaptive Arbeit. Scrum gehört zur agilen Bewegung, die durch das Agile Manifesto von 2001 geprägt wurde. Es betont empirische Prozesse: Transparenz (alle relevanten Informationen sind sichtbar), Inspektion (regelmäßige Überprüfung des Fortschritts) und Anpassung (flexible Reaktion auf Veränderungen). Im Gegensatz zu traditionellem Projektmanagement verzichtet Scrum auf detaillierte Vorgaben und lässt Raum für organisationsspezifische Praktiken. Daher ist es ein Framework, keine vollständige Methode.

Zentrale Begriffe

Scrum definiert klare Accountabilities, Artefakte, Events und Werte, die empirische Arbeit unterstützen.

• Scrum-Team: Eine kleine, cross-funktionale und selbstverwaltete Einheit von maximal zehn Personen, bestehend aus Product Owner, Scrum Master und Developers. Es gibt keine Unter-Teams oder Hierarchien.
• Accountabilities: Seit 2020 im Scrum Guide als Verantwortlichkeiten bezeichnet, anstelle der älteren "Rollen". Der Product Owner ist accountable für den Produktwert und das Product Backlog, der Scrum Master für die Scrum-Umsetzung und Hindernisbeseitigung, die Developers für die Erstellung nutzbarer Increments.
• Artefakte: Drei zentrale Elemente – Product Backlog (emergente Liste von Anforderungen mit Commitment zum Product Goal), Sprint Backlog (Plan für den Sprint mit Commitment zum Sprint Goal) und Increment (nutzbares Produktteil mit Commitment zur Definition of Done).
• Events: Fünf zeitlich begrenzte Events innerhalb des Sprints: Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective, eingebettet in den Sprint als Container.
• Scrum Values: Fünf Werte leiten Verhalten und Entscheidungen: Commitment (Verpflichtung zu Zielen), Focus (Konzentration auf Sprint-Ziele), Openness (transparente Kommunikation), Respect (gegenseitige Wertschätzung) und Courage (Mut zu Veränderungen).

Ablauf

Scrum verwendet Sprints von einem Monat oder weniger, typischerweise zwei bis vier Wochen. Jeder Sprint endet mit einem nutzbaren Increment. Die drei empirischen Säulen – Transparenz, Inspektion und Adaptation – bilden die Basis: Alle Informationen sind sichtbar, Fortschritt wird regelmäßig überprüft, und Pläne werden angepasst. Das Scrum-Team plant im Sprint Planning das "Was" und "Wie", trifft sich täglich im Daily Scrum zur Koordination, präsentiert Ergebnisse im Sprint Review und reflektiert Verbesserungen in der Sprint Retrospective. Artefakte bleiben emergent und anpassbar, Commitments wie Product Goal oder Definition of Done sichern Qualität.

Praxisbeispiel

In einem Datenanalyse-Projekt plant ein Scrum-Team einen zweiwöchigen Sprint zur Entwicklung eines Dashboards. Der Product Owner priorisiert im Product Backlog Features wie Datenfilter (Schätzung: 5 Story Points) und Visualisierungen (8 Story Points). Im Sprint Planning wählen Developers Aufgaben aus, definieren das Sprint Goal Nutzerfreundliches Dashboard für Verkaufsdaten und erstellen das Sprint Backlog. Täglich im 15-minütigen Daily Scrum berichten sie Fortschritte: "Gestern Filter implementiert, heute Visualisierung starten." Nach dem Sprint präsentieren sie ein lauffähiges Increment im Sprint Review, das die Definition of Done erfüllt (getestet, dokumentiert). In der Retrospective identifizieren sie Verbesserungen, etwa bessere Schätzungen, und passen für den nächsten Sprint an.

Häufige Fehler und Empfehlungen

Fehler treten auf, wenn Scrum als starres Regelwerk missverstanden wird – stattdessen ist es bewusst unvollständig und anpassbar. Mikromanagement durch den Product Owner sollte vermieden werden; er entscheidet Prioritäten, nicht das "Wie". Der Scrum Master agiert nicht als "Chef", sondern als Servant Leader. Teams ohne täglichen Fokus auf Entwicklungsaufgaben profitieren weniger; bei Bedarf ist eine Kombination mit Frameworks wie OKR für langfristige Ziele sinnvoll. Bei großen Teams bietet sich der Einsatz von Large-Scale Scrum (LeSS) an. Commitments wie die Definition of Done sollten stringent eingehalten werden, um Qualität zu sichern, und die fünf Scrum Values sollten für Vertrauen gefördert werden.

Siehe auch

Für vertiefte Kenntnisse zu agilen Methoden bietet sich die Betrachtung von Kanban an, das Scrum ergänzen kann. Bei skalierter Anwendung mehrerer Teams empfiehlt sich die Auseinandersetzung mit LeSS oder SAFe.