Scrum: Das ist Agiles Projektmanagement

Jun 13, 2024 | Allgemein

Schnelle flexible Anpassungen an veränderte Rahmenbedingungen, mehr Effizienz und Effektivität sowie die Einbeziehung aller Teammitglieder: Das sind die Versprechungen von Scrum. Kein Wunder, dass die Zertifizierungen zum Scrum Master und Product Owner seit Jahren regen Zulauf haben. Seit 2022 bereitet das D.Network in eigenen Workshops auf diese Zertifizierungen vor – und unsere Absolvent:innen sind auf dem Arbeitsmarkt heiß begehrt. Doch was ist eigentlich dieses Scrum?

1. Was ist Scrum?

Scrum ist ein Framework für Agiles Projektmanagement, das Rollen beschreibt, Events, Zuständigkeiten, Erwartungs-Definitionen, Zusammenarbeit mit dem Kunden bzw Auftraggeber und vieles Anderes mehr. Im Gegensatz zu anderen Methoden des Projektmanagements, sind im Scrum die verschiedenen Phasen nicht strikt voneinander getrennt, also es gibt nicht eine Planungsphase, eine Arbeitsphase und eine Evaluationsphase, sondern die Phasen wiederholen sich in engen Schleifen immer wieder. Durch dieses iterative Vorgehen ermöglicht Scrum stetige Verbesserungen im Ergebnis, aber auch im Teamwork. Scrum fördert Partizipation, Kommunikation und Zusammenarbeit im Team und ist daher besonders geeignet für cross-funktionale Teams, die sich beständig weiterentwickeln wollen.

2. Wozu brauchen wir genau jetzt Agiles Projektmanagement?

Wir leben in einer VUKA-Welt. Der griechische Philosoph Heraklit sagte bereits: “Man kann nie zweimal in den selben Fluss steigen.” Denn: Wo sich Rahmenbedingungen schnell ins Extreme ändern können, Ungewissheit herrscht und komplexe Systeme keine klaren Deutungsmöglichkeiten zulassen, ist es notwendig, auf Sicht zu fahren und in kleinen Schritten vorzugehen. Immer mehr Organisationen merken, dass sie mit klassischen Projektmanagement, 5-Jahres-Plänen und hierarchischen Entscheidungswegen nicht schnell und flexibel auf Veränderungen reagieren können. Scrum erlaubt agiles Handeln und ermöglicht es, die Schwarmintelligenz einer Gruppe zu nutzen. 

3. Welche Rollen gibt es im Scrum?

Scrum definiert drei explizite Rollen, die von unterschiedlichen Personen ausgeübt werden sollten. Auf zwei der Rollen (Scrum Master und Product Owner) kann man sich mit Zertifizierung ausbilden lassen, weitere Zertifizierungen vertiefen das Rollenverständnis oder installieren zusätzliche Rollen auf der Meta-Ebene. Ein Scrum-Team besteht inkl. Scrum-Master und Product Owner aus fünf bis neun Personen.

Die Rollen im Scrum sind:

  • Scrum Master: Er ist der Team-Coach, der das Team dazu befähigt seine Arbeit zu erledigen. Dazu moderiert er alle Events, schlichtet Konflikte, räumt Hindernisse aus dem Weg und kommuniziert sein Wissen über Scrum in die Organisation. Ziel des Scrum Masters ist, dass das Team sich eigenständig organisieren kann und der Scrum Master selbst damit überflüssig wird. Pro Team gibt es einen Scrum Master, wobei der selbe Scrum-Master mehrere Teams gleichzeitig betreuen kann.
  • Product Owner: Er ist der Kontakt des Scrum-Teams zum Kunden und zum Auftraggeber. Gleichzeitig hat er die Zielgruppe und weitere Stakeholder im Blick, betreibt User Research, kennt die Mega-Trends und Business-Kennzahlen sowie das Budget. Pro Projekt gibt es einen Product Owner (“one face to the customer”). Auf dem selben Projekt können mehrere Teams arbeiten und der Product Owner kann Aufgaben outsourcen, beispielsweise an Assistenzen oder externe Dienstleister. Als einziges Teammitglied kann der Product Owner einen Sprint abbrechen, falls aufgrund veränderter Rahmenbedingunugen die Arbeit an den aktuellen ToDos keinen Sinn mehr ergibt.
  • Team Member / Developer: Die Developer entwickeln das eigentliche Produkt oder die Dienstleistung, indem sie Sprint für Sprint neuen Mehrwert hinzufügen. Die Developer verfügen über die Fähigkeiten und das nötige Fachwissen, um ihre Aufgaben pro-aktiv zu erledigen und sich dabei weitgehend selbst zu organisieren. Ist dies nicht der Fall, haben die Developer zumindest die Bereitschaft, sich durch Weiterbildungen oder Persönlichkeitsentwicklung in diesen Zustand zu gelangen.

4. Wie läuft so ein Scrum-Prozess ab?

Ein Projekt, das mit Scrum bearbeitet wird. verläuft in mehreren Arbeitszyklen – den so genannten Sprints. Ein Sprint dauert zwischen ein bis vier Wochen. Je nachdem, wie schnell und unberechenbar sich die Rahmenbedingungen verändern können, kann es sinnvoll sein, eine Sprint-Länge kurz zu halten, damit das Team schnell und flexibel reagieren kann. Die Sprintdauer wird zu Beginn eines Projektes festgelegt und ist dann in jedem Sprint gleich.

Das sind die Events in einem Sprint:

  • Planning: Jeder Sprint startet mit einem Planning, das aus zwei Teilen besteht: Im “What-Meeting” präsentiert der Product Owner, welcher Mehrwert in diesem Sprint geschaffen werden soll (“Sprint-Ziel”) und welche ToDos dafür geeignet sind. Die Developer schätzen den Aufwand und gleichen mit ihren Kapazitäten ab. Im “How-Meeting” fügen die Developer den ToDos weitere Details hinzu, identifizieren Abhängigkeiten und geben bereits ein Meinungsbild, wer welche Aufgabe bearbeiten möchte. Ein Planning dauert einen Tag lang, oder kürzer.
  • Daily: Jeder Tag beginnt mit einem Daily. Das ist ein kurzes, knackiges Meeting von 15 Minuten Dauer, indem jedes Teammitglied drei Fragen beantwortet: Was habe ich zuletzt getan? Was will ich als nächstes machen? Und welche Hindernisse liegen mir im Weg?
  • Der Rest des Tages besteht aus der Arbeitsphase. Diese hat im Scrum keinen eigenen Begriff. Die Arbeitsphase besteht aus der Arbeit am eigentlichen Sprintziel, informellen Meetings und der Dokumentation. Der Scrum-Master stellt sicher, dass die Developer im Flow bleiben und räumt dafür Hindernisse aus dem Weg. Der Product Owner ist für den Rest des Teams erreichbar, falls Rückfragen entstehen, verbringt die meiste Zeit aber beim Kunden, bei der User Research, der Priorisierung der nächsten ToDos oder seinen zahlreichen anderen Zuständigkeiten. 
  • Review: In der Review kommt das komplette Team inkl. Product Owner mit dem Kunden zusammen und präsentiert den Mehrwert, der in diesem Sprint erzeugt wurde. Es handelt sich hier nicht um eine Ergebnis-Präsentation sondern mehr um eine Werk-Schau, bei der auch Unfertiges bewußt gezeigt wird, um erstes Feedback zu erhalten (“User-Testing”). Hier entscheidet sich, welche User-Stories vom Product Owner tatsächlich als erledigt gekennzeichnet werden und welche zur Wiedervorlage für einen nächsten Sprint zurück ins Product Backlog wandern. Zur Review können auch weitere Stakeholder einigeladen werden. Die Review dauert maximal einen halben Tag.
  • Retrospektive: Im Gegensatz zur Review, wird bei der Retrospektive nicht über das Ergebnis gesprochen sondern es wird auf der Metaebene die Zusammenarbeit im Team besprochen. Was lief gut, was lief nicht so gut und was möchte das Team in Zukunft anders machen? Weil diese Art der Meta-Reflektion für Viele ungewohnt ist, moderiert der Scrum Master zunächst einen Check-In, in der jede Person kurz mündlich ihre Stimmung mitteilt. Dann werden auf Post-It’s Verbesserungsvorschläge für den kommenden Sprint festgehalten und priorisiert. Ziel ist, dass mindestens ein konkreter Verbesserungsvorschlag im kommenden Sprint umgesetzt wird (“Action Item”). Die Retrospektive dauert maximal vier Stunden. 
  • Backlog Refinement/Grooming: Hierbei handelt es sich um ein außerplanmäßiges Event, was vom Team nach Bedarf einberufen werden kann. Beim Refinement räumt das ganze Team gemeinsam alle ToDo-Sammlungen (“Product Backlog” und “Sprint Backlog”) auf, ergänzt notwendige Details und stellt sicher, dass alles auf dem aktuellen Stand ist.

5. Wie werden die ToDos festgehalten?

ToDos sind in unterschiedlichen Formen an drei Orten zu finden: Im Product Backlog, in den Sprint Backlogs und in den Tickets. Alle ToDos sollen jeweils so offen wie möglich, aber so konkret wie nötig formuliert werden, damit die Erwartungen aller Beteiligten in die gleiche Richtung gehen und dennoch am Ende die Person, die eine Aufgabe übernimmt, größtmöglichen Freiraum hat (“Entscheidung nach Kompetenz und Betroffenheit”). Der Erwartungsrahmen wird in einer „Definition of Done“ (DoD) als Akzeptanzkriterium formuliert. Der Rahmen aller ToDos ist außerdem beschränkt durch Rahmenbedingungen, die die Organisation oder der Kunde vorgeben können, beispielsweise eigene Werte (“Darf keine Tierprodukte enthalten!”) oder Limitierungen (Budgetbeschränkung). 

So werden ToDos festgehalten:

  • Product Backlog: Diese Liste wird vom Product Owner gepflegt und enthält Anforderungen in Form von User Stories. Eine User Story hat die Form “Ich als ROLLE möchte FUNKTION um NUTZEN.” Das Product Backlog ist nach Dringlichkeit und Wichtigkeit priorisiert. Eine User Story ist umso dringender und wichtiger, je höher das ihr zugrunde liegende Risiko (Schaden x Eintrittswahrscheinlichkeit) auszufallen droht. User Stories entstehen, indem der Product Owner sehr grobe Schlagwörter (“Topics”) in Anforderungen (“Requirements”) konkretisiert und daraus anschließend User Stories formuliert. In Form eines “Release Plan” erhält auch der Kunde Einsicht in das Product Backlog in einer sehr abgespekcten, vereinfachten Version; hier kann er einsehen, bis wann welche Teilergebnisse zu erwarten sind. 
  • Sprint Backlogs: In jedem Sprint entsteht ein Sprint Backlog, meist in der Form eines Kanban Boards. Unter der Sprint Vision werden in einer Spalte “ToDo” alle User Stories gesammelt, die in diesem Sprint bearbeitet werden sollen. Anschließend werden diese von den Developern in konkretere und kleinere Aufgaben-Pakete zerlegt (“Ticket”)
  • Ticket: Innerhalb jedes Aufgaben-Pakets werden im Laufe des Sprints weitere Details ergänzt, wie zum Beispiel kleinere Unter-Aufgaben, Notizen oder gesammelte Erfahrungen. Innerhalb jedes Tickets ist eine Unter-Aufgabe die “Dokumentation”, also das Sichern von Informationen, die in der Zukunft weiterhin Relevanz besitzen können. In vielen Fällen ist das Ergebnis, was herauskommt wenn ein Ticket erledigt ist, allerdings bereits ausreichend als Dokumentation – das Ergebnis steht sozusagen für sich. Ein erledigtes Ticket fließt in Form eines “Inkrements” in das Gesamt-Projekt ein.

6. Was ist ein Kanban-Board?

Viele Scrum-Teams arbeiten mit Kanban-Boards als Sprint-Backlog. Das sind zweidimensionale, gemeinsame ToDo-Listen, die Tickets entlang eines Zeitstrahls abbilden. Tickets wandern entsprechend von links nach rechts, je weiter sie fortgeschritten sind. Ein Kanban-Board ist eine transparente Art, um ToDos zu sammeln, aus dem klar der Fortschritt ersichtlich ist sowie die Auslastung der einzelnen Teammitglieder. Ein Kanban-Board ist eine gute Grundlage für die Events “Planning”, “Daily”, “Backlog Refinement/Grooming” und “Review”. 

Mögliche Spalten in einem Kanban-Board sind:

  • Todo: Was soll als nächstes getan werden?
  • Doing: An was wird jetzt gerade in diesem Moment gearbeitet?
  • Pending/Blocked: Woran kann aus externen Gründen gerade nicht weitergearbeitet werden?
  • Done: Was ist erledigt?
  • Tested: Was ist erfolgreich getestet worden?

7. Wie wird Erfolg gemessen?

Im Agilen Projektmanagement wird möglichst ressourcenschonend gearbeitet. Unnötiges Sammeln von Daten gilt es zu vermeiden. Daher ist es wichtig, dass ein Scrum Team zu Beginn eines Sprints genau überlegt, was die eigene Definition von Erfolg ist: Kundenzufriedenheit, Schnelligkeit, Qualität, wenig Überstunden, Müllvermeidung – all das können Erfolgsfaktoren sein, oder auch nicht. Für Aufgabenpakete gibt es darüber hinaus Schätzungen. 

So funktionieren Schätzungen:

  • Zu Beginn eines Sprints schätzt jedes Teammitglied für jedes Ticket den gefühlten Aufwand – entweder in Ticket-Größen (S, M, L, XL) oder mit der Fibunacci-Sequenz (mehr hier). Hier geht es nicht um feste Größen wie Zeit oder Kosten, sondern tatsächlich um den subjektiv gefühlten Aufwand hinter einem Aufgabenpaket.
  • Anschließend dürfen die Personen mit besonders geringen und mit besonders hohen Schätzungen ihre subjektiven Begründungen äußern.
  • Danach wird erneut von allen eine Schätzung abgegeben, so lange, bis ein Konsens vorliegt, wie aufwändig eine Aufgabe ist und wer sie bearbeiten möchte. 
  • Der Scrum Master hält täglich im Daily den Fortschritt aller Aufgaben in Relation zu den abgegebenen Schätzungen in Form eines Burn-Down-Charts fest und gibt anhand dessen eine Prognose über den weiteren Sprint-Verlauf ab.
  • Am Ende eines Sprints kann in der Review mit dem Burn-Down-Chart der Team-Erfolg ausgewertet werden

8. Auf welchen Grundprinzipien und Werten basiert Scrum?

Die Vorüberlegungen von Scrum wurden bereits im Jahr 2001 im Agilen Manifest von 17 Software-Entwickler:innen niedergeschrieben. Die drei Säulen von Scrum sind Transparenz, Überprüfung und Anpassung; das macht Scrum zu einem auf Empirie basierenden Prozess. Werte, die in einem Scrum-Team gelebt werden sollten, sind Transparenz, Mut, Offenheit, Commitment und Respekt.  

9. Welche anderen Methoden oder Ansätze passen gut zu Scrum?

Scrum bzw. Agiles Projektmanagement gehört zur Familie des Agilen Arbeitens und zu New Work. In New Work werden Arbeit und Privatleben nicht mehr getrennt voneinander betrachtet sondern das Individuum wird vielmehr als ganzheitliche Persönlichkeit wahrgenommen, mit Gefühlen, Bedürfnissen, Antreibern und Fähigkeiten. Grundannahme ist, dass Menschen von Natur aus miteinander kooperieren und gemeinsam etwas voranbringen wollen, um Mehrwert für sich, die Menschheit und den Planeten zu erzeugen. 

Diese Methoden und Ansätze lassen sich gut mit Scrum kombinieren:

  • Design Thinking, um schneller bessere Ideen zu entwickeln, zum Beispiel für das Product Backlog oder um generell Probleme zu lösen.
  • Gewaltfreie Kommunikation (GfK) um miteinander respektvoll zu kommunizieren und möglichst eindeutige Informationen auszutauschen.
  • Servant Leadership als eine Haltung, um Verantwortung zu übernehmen (insbes. für den Scrum Master)
  • Transaktionsanalyse, um zwischenmenschliche Interaktionen besser zu verstehen
  • Liberating Structures als Methodensammlung zur Kooperation, Kollaboration und Präsentation

10. In welchen Branchen oder Bereichen kann Scrum eingesetzt werden, und wie?

Scrum hat Wurzeln in der Produkt- und in der Software-Entwicklung, kann aber generell in allen Bereichen eingesetzt werden, die von den Auswirkungen der VUKA-Welt betroffen sind. Wichtig ist, zu Beginn bei der Einführung von Scrum den Mehrwert zu definieren, der Schritt für Schritt erzeugt werden soll. Das können Updates einer App sein, tägliich frische Brötchen einer Bäckerei (und damit satte und glückliche Kund:innnen), ein Monats-Magazin, ein jährlich stattfindendes Festival, ein besseres Abschneiden der eigenen Partei bei der “Sonntagsfrage”. Laut Zertifizierungsinstituten kann Scrum nur hundertprozentig nach Lehrbuch eingeführt werden. Die Praxis zeigt allerdings, dass einzelne Elemente von Scrum sehr gut für sich funktionieren können.

Folgende Elemente von Scrum werden häufig eigenständig eingeführt:

  • Einteilen einer Projektlaufzeit in kurze Arbeitszyklen.
  • Durchführen eines Daily
  • Einführun der Events “Daily”, “Review”, “Retrospektive”
  • Kanban-Board inkl. der damit verbundenen Transparenz
  • Rollen wie Scrum Master und Product Owner

Unsere Expert:innen für Servant Leadership

Im D.Network haben wir verschiedene Expert:innen für die einzelnen Module der Servant-Leadership-Weiterbildung. Ansprechpersonen für das Gesamtkonzept sind: