Scrum: der große Leitfaden zum agilen Framework (2024)

Scrum: eine kompakte Einführung

In den letzten Jahren hat sich Scrum in vielen Branchen als beliebte Alternative zum klassischen Projektmanagement etabliert. Der Grund dafür liegt in der Fähigkeit des Vorgehensmodells, größere Projekte oder Produkte in kleine, überschaubare Einheiten zu zerlegen und diese in kurzen Zeitintervallen (den sogenannten Sprints) zu bearbeiten. Dadurch können Teams flexibler, effektiver und schneller Mehrwert für ihre Kund*innen erzeugen.

Scrum zeichnet sich durch seine klaren Rollen und Events aus. Die wichtigsten Rollen sind der Product Owner, der Scrum Master und die Entwickler*innen:

• Der Product Owner entwickelt die Produktvision und verwaltet das Backlog.
• Der Scrum Master ist dafür verantwortlich, dass das Team das Scrum-Framework richtig anwendet und nach den Scrum-Prinzipien arbeitet.
• Das Entwicklerteam setzt die Aufgaben aus dem Backlog um.

Das Scrum-Team organisiert seine Arbeit dabei innerhalb der fünf Scrum-Events (Sprint, Sprint Planning, Daily Stand-up, Sprint Review, Sprint Retrospective).

Ein Vorteil von Scrum gegenüber dem klassischen Projektmanagement liegt in der kontinuierlichen Verbesserung. Durch die regelmäßigen Feedbackschleifen und die kritische Bewertung der Ergebnisse nach jedem Sprint können Schwächen und Probleme schnell erkannt und behoben werden. Die Planung der Arbeitspakete innerhalb von Sprints ermöglicht es Teams, in kürzester Zeit auf Änderungen im Projektverlauf zu reagieren. Zudem sorgt Scrum für eine hohe Transparenz und Flexibilität, indem es über Backlog und User Stories die anstehende sowie aktuelle Arbeit sichtbar macht.

Warum funktioniert klassisches Projektmanagement nicht (immer)?

Die Arbeit mit klassischen Projektmanagementmodellen (z. B. der Wasserfall-Methode) hat lange Zeit gut funktioniert. Doch mit zunehmender Komplexität der Projekte und Aufgaben stößt die Vorgehensweise zunehmend an seine Grenzen. Viele Beispiele zeigen, dass klassisches Projektmanagement in einem komplexen Umfeld mit sich ändernden Rahmenbedingungen nicht die gewünschten Ergebnisse liefert.

Bei der klassischen Vorgehensweise steht die Planung im Vordergrund: Im Vorfeld werden Umfang, Budget, Zeit und Ressourcen für das Projekt festgelegt. Von diesem Plan weicht das Team während der Durchführung nur in Ausnahmefällen ab. Im klassischen Projektmanagement geht man davon aus, dass es einen bestmöglichen Weg gibt, um das Projektziel zu erreichen. Je komplexer ein Projekt ist, desto unwahrscheinlicher ist es, dass diese Einschätzung tatsächlich eintritt. Weicht die Entwicklung vom ursprünglichen Plan ab, kommt es zu Verzögerungen im Projektablauf. Das können Veränderungen im Lieferumfang oder der -qualität sein, die dann meist Zeit- und Kostensteigerungen zur Folge haben. Dies führt häufig dazu, dass die Verantwortlichen den Projektumfang reduzieren, um Zeitplan und Budget unter Kontrolle zu halten.

Die häufigsten Probleme im klassischen Projektmanagement:

• Projekte haben eine sehr lange Planungsphase, bevor die Umsetzung startet.
• Hohe Komplexität der Projekte nötigt zu Annahmen für die Kalkulation.
• Planer und Umsetzer arbeiten nicht eng genug zusammen, so dass es zu Missverständnissen kommt.
• Planung bezieht sich auf Expertenwissen, statt Kundengruppen einzubinden.
• Rahmenbedingungen verändern sich häufig, die Planung wird jedoch nicht angepasst.
• Kalkulationen treffen nicht ein, weil Bedingungen sich ständig verändern.
• Einzelne Gewerke übernehmen Verantwortung für ihre Aufgaben anstatt für das Ergebnis.
• Erst mit zunehmender Fertigstellung wird mangelnder Kundennutzen deutlich.

Beispiel: Opernhaus Sidney

Insbesondere in Bauprojekten mangelt es nicht an Beispielen: die Elbphilharmonie, der Flughafen Berlin-Brandenburg und auch das berühmte Opernhaus in Sydney waren in Bezug auf das Projektmanagement keine Erfolgsgeschichten. So überstieg der Bau des australischen Konzerthauses das Budget und den Zeitplan bei weitem. Während der gesamten Bauzeit kam es immer wieder zu Auseinandersetzungen zwischen dem Architekten Jørn Utzon und der australischen Regierung. Streitpunkte waren die Mehrkosten und Verzögerungen, die notwendig waren, um Utzons Vision vollständig umzusetzen. Die Kosten stiegen während der Bauphase um mehr als das 14-fache des geplanten Budgets und die Fertigstellung dauerte mehrere Jahre länger als geplant.

Als sowohl der Zeit- als auch der Kostenrahmen deutlich überschritten wurden, begannen die Auftraggeber den Umfang massiv zu kürzen, um das Budget in den Griff zu bekommen. Schließlich wurden die Spannungen so groß, dass sich Utzon aus dem Projekt zurückzog. Die Kompromisse zur Kostenreduzierung wurden fortgesetzt, um das Projekt in einem angemessenen Zeitrahmen fertigzustellen.

Dabei wurde das ursprüngliche Ziel weit verfehlt. Nach Utzons Vision hätte das Opernhaus eine hervorragende Akustik geboten. Kosteneinsparungen führten jedoch dazu, dass Interpreten und Publikum nach der Eröffnung des Konzerthauses 1973 jahrzehntelang mit einer schlechten Akustik leben mussten: Ein optisch perfektes Opernhaus mit nicht ganz so perfekter Klangqualität. Erst 2016 wurde mit einer umfassenden Sanierung begonnen, um die größten Probleme zu beheben und die Akustik des Gebäudes der ursprünglichen Idee Utzons anzunähern.

Unterschiede klassisches und agiles Projektmanagement 

Die Opernhaus-Episode illustriert sehr gut das Dilemma des klassischen Projektmanagements: Zu Beginn wird der Umfang als wichtigster Parameter des Projekts festgelegt. Die Beteiligten gehen davon aus, dass die Zeit- und Kostenvorgaben schon ausreichen werden. Laufen dann im Projektverlauf Zeit und Kosten aus dem Ruder, rücken diese beiden Faktoren plötzlich in den Vordergrund und der Umfang wird angepasst.

Bei agilen Ansätzen hingegen sind Zeit und Kosten fix. Der Fokus liegt darauf, innerhalb dieses Rahmens einen möglichst großen Wert für die Kund*innen zu erzeugen. Der Umfang wird geschätzt, regelmäßig neu bewertet und entwickelt sich im Laufe des Projekts weiter. Das bedeutet, dass sich auch im agilen Projektmanagement der geplante Umfang durchaus ändern kann. Dies passiert z.B. wenn die gesteckten Ziele im gegebenen Rahmen nicht erreichbar sind oder keinen Mehrwert für Kund*innen liefern. Der Unterschied zum klassischen Vorgehen ist, dass dies bewusst geschieht und nicht erst, wenn Kosten- und Zeitdruck dazu zwingen.

Ein agilerer Ansatz hätte dazu geführt, dass bei der Entwicklung des Opernhauses mehr Fokus auf die zentralen Elemente des Bauwerks und den Mehrwert für die späteren Nutzer*innen gelegt worden wäre. Im Falle von unvorhergesehenen Änderungen hätte eine Neupriorisierung des Projektumfangs zu einem geringeren Zeit- und Kostenaufwand führen können. Die Elemente mit dem höchsten Mehrwert für die Kund*innen und die absoluten “Must-haves” wären von vornherein in der Planung am höchsten priorisiert worden. “Nice-to-have”-Elemente wären entsprechend später realisiert worden. Der Wegfall dieser optionalen Bestandteile wäre bei einer Reduktion des Umfangs leichter zu verkraften gewesen.

Im Video sehen Sie, wie die Hotelkette Marriot den Bau eines Hotels in New York durch die Verwendung vorgebauter Module auf 90 Tage reduziert hat:

Vorteile von Scrum: kontinuierliche Verbesserung

Scrum ist das wahrscheinlich bekannteste agile Framework in der dynamischen Projekt- und Produktentwicklung. Im Gegensatz zum klassischen Ansatz, wo das Gesamtprojekt im Voraus geplant wird, verwendet Scrum einen „iterativen“ Ansatz: Teams planen Aufgaben für einen überschaubaren Zeithorizont (Sprints) und entwickeln in jedem Sprint-Zyklus bereits einen Mehrwert für die Kund*innen. Das Team kann so jederzeit auf Unplanbares und neue Anforderungen reagieren.

Die wichtigsten Vorteile von Scrum:

• mehr Flexibilität bei der Entwicklung von Lösungen, Produkten und Services
• höhere Kunden- und Mitarbeiterzufriedenheit durch schnellere und kontinuierliche Lieferung von Ergebnissen
• bessere Transparenz und Kommunikation zwischen Teammitgliedern und Kund*innen
• höhere Qualität der Produkte durch ständiges Feedback und kontinuierliche Verbesserung
• bessere Planung und Steuerung von Projekten durch den Einsatz von Sprints, Backlogs und anderen Scrum-Elementen

Die Geschichte hinter Scrum

Scrum stammt ursprünglich aus der Softwareentwicklung und wurde in den 1990er-Jahren von Ken Schwaber und Jeff Sutherland entwickelt. Im letzten Jahrzehnt des 20. Jahrhunderts stieg der weltweite Bedarf an leistungsfähiger Software rasant an. Gleichzeitig scheiterte damals rund ein Drittel aller IT-Projekte frühzeitig. Gerade einmal 16 Prozent der Vorhaben wurden erfolgreich abgeschlossen. Dies ergab die erste CHAOS-Studie der Standish Group aus dem Jahr 1994. Die Entwicklung von Scrum war die Antwort auf diese Situation. Schwaber und Sutherland sahen die Lösung der Probleme in einer Flexibilisierung des Projektprozesses und erhofften sich dadurch, schneller bessere Ergebnisse zu erzielen.

Hierzu haben sie zentrale Werte und Prinzipien definiert und in Meetingformate, Rollen und Arbeitswerkzeuge übertragen. Die Grundlagen des Frameworks haben Schwaber und Sutherland im Scrum Guide niedergeschrieben, der seit seiner Entstehung regelmäßig aktualisiert wird. Aktuell ist die sechste Version von 2020 verfügbar.

Scrum als agiles Framework

Um an dieser Stelle ein gängiges Missverständnis auszuräumen: Scrum ist keine agile Methode, sondern ein agiles Framework. Die beiden Begriffe werden häufig miteinander verwechselt. Sie unterscheiden sich jedoch in einigen wichtigen Punkten: Agile Frameworks legen Regeln und Prozesse fest und definieren den Rahmen für ein Vorgehen, um sich im Alltag zu organisieren. Agile Methoden hingegen helfen bei ganz bestimmten Aufgaben im Alltag: Sie erleichtern es beispielsweise, Aufwände zu schätzen, Aufgaben zu priorisieren oder Entscheidungen treffen.

Als agiles Framework oder Vorgehensmodell bietet Scrum Teams einen Rahmen für die Organisation der Zusammenarbeit und skizziert einen idealtypischen Ablauf mit klaren Regeln. Dazu gehören unter anderem die 5 Scrum-Events (Sprint, Sprint Planning Daily Stand-up, Review und Retrospective) und die im Scrum-Team definierten Rollen im Team (Product Owner, Scrum Master, Entwickler*innen).

Die Grundlagen von Scrum

Scrum verfolgt einen iterativen und inkrementellen Ansatz: Scrum-Teams arbeiten kontinuierlich und schrittweise (iterativ) an einem Produkt oder Projekt. Dabei liefern sie regelmäßig Ergebnisse in Form von Teilprodukten oder bestimmten Bestandteilen (Inkrement) aus.

Das Framework basiert auf Empirie und Lean Thinking. Lean Thinking hält die Teams dazu an, sich auf das Wesentliche zu konzentrieren und die drei Arten von Verschwendung (jap. Muda, Mura, Muri) zu reduzieren. Unter Verschwendung werden alle Aktivitäten verstanden, die die Wertschöpfung verringern und die Kosten erhöhen (z.B. aufwändige Dokumentation oder unproduktive Meetings).

Empirie bedeutet, dass „Wissen aus Erfahrung gewonnen wird und Entscheidungen auf der Grundlage von Beobachtungen getroffen werden“ (Scrum Guide). Die Scrum-Empirie basiert auf drei Säulen:

• Transparenz: Alle Beteiligten müssen die Ergebnisse und Fortschritte sowie die wichtigsten Elemente jederzeit transparent einsehen können.
• Überprüfung: Der Fortschritt auf dem Weg zum Etappenziel muss regelmäßig überprüft werden, um auf eventuell unerwünschte Abweichungen oder Probleme reagieren zu können. Dazu dienen beispielsweise die Scrum-Events.
• Anpassung: Erkannte Abweichungen müssen schnellstmöglich durch Anpassungen behoben werden.

Das Scrum-Team: Rollen statt Titel

Ein Scrum-Team ist anders strukturiert als ein klassisches Projekt- oder Produktteam. Es existieren keine Machthierarchien, alle Mitglieder agieren auf Augenhöhe. Statt Positionen gibt es Rollen, die von den einzelnen Mitgliedern wahrgenommen werden. Das Scrum-Team ist eine „geschlossene Einheit von Fachleuten“ (Scrum Guide). Es arbeitet selbstorganisiert auf ein gemeinsames Ziel hin und verteilt die Verantwortlichkeiten und Zuständigkeiten auf die drei Scrum-Rollen: Product Owner, Scrum Master und Entwickler*innen.

• Product Owner: Hauptaufgaben des Product Owners sind die Erstellung und Pflege des Product Backlogs. Dazu gehören u. a. das Sammeln und Priorisieren der Anforderungen an das Projekt bzw. Produkt.
• Scrum Master: Der Scrum Master unterstützt in seiner prozessgebenden Rolle bei der Anwendung des Frameworks.
• Entwickler*innen: Das crossfunktionale Entwicklungsteam besteht aus den operativen Fachexpert*innen, die sich mit der Entwicklung von Lösungen aller Art befassen. Bei der Zusammensetzung des Teams sollte darauf geachtet werden, dass es alle notwendigen Fähigkeiten und Kenntnisse abdeckt, um das Projekt erfolgreich abzuschließen.

Product Owner: Verantwortung für das Gesamtprodukt

Der Product Owner (PO) vertritt im Team die Interessen der Kund*innen und verantwortet das Gesamtprodukt. Er entwickelt eine Produktvision und gibt die Zielrichtung für die Entwicklung vor. Der PO sammelt Probleme, Anforderungen und Ziele aller Stakeholder*innen (z. B. Kund*innen, Auftraggeber, Unternehmensvertreter) an das Produkt oder Projekt in einem Product Backlog und wandelt diese in zu bearbeitende Aufgaben um. Dies geschieht z. B. in Form von User Stories. Darüber hinaus priorisiert der Product Owner die Aufgaben Er legt fest, in welcher Reihenfolge die User Stories oder andere Backlog-Einträge vom Team bearbeitet werden.

Der Product Owner ist ergebnisverantwortlich für die kontinuierliche Verbesserung und Wertmaximierung des Produkts. Dabei übernimmt er im Wesentlichen drei Aufgaben:

• Product-Backlog-Management: Der Product Owner formuliert eine Produktvision und erstellt die Backlog-Einträge. Er priorisiert die Einträge und sorgt dafür, dass Backlog transparent und nachvollziehbar ist.
• Stakeholder-Management: Der Product Owner ist im ständigen Austausch mit Stakeholder*innen und bezieht deren Interessen mit ein. So stellt er sicher, dass das Backlog sinnvoll strukturiert ist und die Entwickler*innen einen Mehrwert schaffen können.
• Release-Management: Der PO hat immer im Blick, wann die die entwickelten Lösungen bei den Nutzer*innen ankommen. Innerhalb des Sprints gibt es keine fixen Releasedaten und das Team kann jederzeit liefern. Der PO muss immer wissen, wann die einzelnen Lösungen veröffentlicht werden.

Scrum Master: Verantwortung für die Zusammenarbeit

Der Scrum Master ist der methodische Experte des Scrum-Teams. Er verbessert die Zusammenarbeit, sorgt für optimale Arbeitsbedingungen, die Einhaltung des Scrum Guides und unterstützt das Team bei der Selbstorganisation.

Sein Fokus liegt darauf, bestmögliche Rahmenbedingungen zu schaffen, damit das Team konzentriert an den Aufgaben des Sprints arbeiten kann. Dazu gehört auch, dass der Scrum Master dem Team dabei hilft, Hindernisse (sogenannte Impediments) bei der Arbeit zu identifizieren und zu beseitigen. Darüber hinaus fördert er die Zusammenarbeit und Kommunikation im Team. So stellt der Scrum Master sicher, dass die Scrum-Events stattfinden und produktiv sind.

Der Scrum Master hat laut Scrum Guide eine „dienende Funktion“ und unterstützt

• den Product Owner bei der Definition des Produktziels, dem Backlog-Management und der Zusammenarbeit mit Stakeholder*innen,
• die Entwickler*innen dabei, sich selbst zu organisieren und auf die Schaffung hochwertiger Produktbestandteile (Inkremente) zu fokussieren sowie
• die Organisation bei der Einführung von Scrum.

Entwickler*innen: Verantwortung für die Ergebnisse der Arbeit

Die Entwickler*innen sind die operativen Fachexpert*innen des Teams. Sie entwickeln das Produkt bzw. eine Lösung für ein konkret definiertes Kundenproblem und sind für die Arbeitsergebnisse verantwortlich. Während sich der Product Owner darum kümmert, „was getan werden muss“, entscheiden die Entwickler*innen, „wie es getan wird“. Sie legen fest, welche Aufgaben sie erledigen, um das Produkt oder Produktkomponenten zu erstellen.

Die Entwickler*innen sind verantwortlich dafür, in jedem Sprint ein Inkrement auszuliefern, das Wert für den Kunden stiftet. Sie entscheiden selbstorganisiert über ihre Zusammenarbeit. Das bedeutet aber nicht, dass alle Entwickler*innen die gleichen Aufgaben oder Fähigkeiten haben. Ein Scrum-Team ist eine funktionsübergreifende Gruppe von Fachleuten mit unterschiedlichen Kompetenzen und Expertisen.

Der Scrum-Sprint: kontinuierlicher Arbeitsrhythmus mit klarem Ziel

Der Sprint ist ein zentraler Bestandteil des Scrum-Frameworks. In diesem festgelegten Zeitraum arbeitet das Scrum-Team konzentriert an gemeinsam definierten Arbeitspaketen. Dies ist ein entscheidender Unterschied zum klassischen Projektmanagement: Aufgaben werden nur für einen überschaubaren Zeithorizont geplant. So kann das Team jederzeit auf Unvorhergesehenes, Änderungen oder neue Anforderungen reagieren. Durch die regelmäßige Durchführung von Sprints lernt das Team zudem ständig dazu und hat die Möglichkeit, seine Arbeit zu optimieren.

Wie lange der Sprint dauert, legt das Team fest. In der Regel dauert ein Zyklus ein bis vier Wochen. Es gibt keine Pausen: Nach Ablauf des Sprint-Zeitraums beginnt der nächste Sprint. Innerhalb eines Sprintzyklus entwickelt das Team ein Teilprodukt bzw. Inkrement. Dieses stellt einen „Zwischenschritt“ zum finalen Produkt oder Projekt dar und liefert im Idealfall bereits einen Mehrwert für die Kund*innen bzw. Nutzer*innen.

Doch nicht alle Teams arbeiten in mehrwöchigen Sprints: Erfahren Sie im Video, wie Tesla mit deutlich kürzeren Zyklen arbeitet, die manchmal nur wenige Tage dauern:

Sprints geben der Arbeit des Teams einen wiederkehrenden Rhythmus aus Planung, Durchführung und Review/Retrospektive und haben ein klares Ziel. In jedem Sprint definiert das Team eine bestimmte Menge an Arbeit, die es zu erledigen hat. Dies bringt Klarheit und Fokus in die Arbeit des Teams, da alle Teammitglieder genau wissen, was sie zu tun haben. Scrum-Sprints fördern die Motivation und die Zusammenarbeit im Team. Jedes Teammitglied ist an der Erreichung des Sprintziels beteiligt und leistet seinen individuellen Beitrag.

Die Scrum-Events

Im laufenden Sprint organisiert das Scrum-Team seine Zusammenarbeit über vier zentrale Events: Sprint Planning, Daily Stand-up, Sprint Review und Sprint Retrospective sind im Scrum Guide als verbindliche Bestandteile des Frameworks definiert. Der Sprint bildet dabei die zeitliche Klammer, in dem die Events stattfinden und das vereinbarte Arbeitspaket umgesetzt wird. Sind weitere Meetings, Workshops oder Maßnahmen nötig, um die Arbeit erledigen zu können, organisiert das Team diese nach Bedarf.

Sprint Planning: Auftakt für den Sprint

Das Sprint Planning eröffnet den Sprint. Während des Meetings plant das Team die Arbeit für den anstehenden Zyklus. In der Regel formuliert der Product Owner ein Sprintziel vor. Außerdem wählt er die Einträge aus dem Product Backlog aus, die seiner Meinung nach umgesetzt werden müssen, um dieses Ziel zu erreichen.

Dieser Vorschlag des Product Owners bildet die Diskussionsgrundlage für das Planning: Das gesamte Scrum-Team arbeitet im Anschluss zusammen, um ein finales Sprintziel zu definieren. Dieses verdeutlicht, warum der Sprint für die Stakeholder*innen wertvoll ist. Im Gespräch mit dem Product Owner wählen die Entwickler*innen die Einträge aus dem Product Backlog aus, die in den aktuellen Sprint aufgenommen werden. Lesen Sie im Interview mit Andreas Schneider, Product Owner bei den DEVK Versicherungen, wie ein Sprint Planning in seinem Team abläuft.

Im Sprint Planning legen die Entwickler*innen eigenständig fest, wie viel Arbeit sie erledigen. Sie schätzen den Aufwand für die einzelnen Einträge und planen die notwendigen Aktivitäten, um das Sprintziel zu erreichen. Die ausgewählten Einträge und das Sprintziel bilden am Ende das sogenannte Sprint Backlog. Im laufenden Sprint arbeiten die Entwickler*innen selbstständig an diesem vereinbarten Arbeitspaket.

Der Scrum Guide begrenzt die Dauer des Sprint Plannings auf maximal acht Stunden für einen vierwöchigen Sprint. Bei kürzeren Sprints ist das Event entsprechend kürzer.

Daily Stand-up: tägliches Update fürs Team

Im laufenden Sprint trifft sich das Team täglich zum Daily Stand-up. In diesem Treffen besprechen es die Ergebnisse des vorherigen Tages und den Plan für den aktuellen Tag. Die Teammitglieder nutzen die 15 Minuten des Termins auch, um über Hindernisse in ihrer Arbeit zu sprechen und wie sie diese (gemeinsam) beseitigen können.

Das Stand-up-Meeting sorgt für Klarheit zur aktuellen Situation während des Sprints. Es ist keine Kontrollmaßnahme, es geht vielmehr um Transparenz im Team und gegenseitige Hilfestellung. Diese Transparenz ermöglicht es dem Team, mögliche Hindernisse oder Verzögerungen zu identifizieren und schnell darauf zu reagieren. Hauptaufgaben sind, das Team informiert zu halten und den Fortschritt in Richtung Sprintziel zu gewährleisten. Viele Teams strukturieren das Daily Stand-up mit drei Fragen:

• Was passiert bei mir aktuell?
• Was ist kürzlich fertig geworden?
• Wo benötige ich Unterstützung?

Sprint Review: fachliches Feedback einholen

Am Ende des Sprintzyklus versammelt das Team alle wichtigen Stakeholder*innen zur Sprint Review und präsentiert die Ergebnisse des Sprints. Ziel der Sprint Reviews ist es, fachliches Feedback einzuholen und für den nächsten Sprint zu lernen. Gemeinsam mit den Stakeholder*innen überprüft das Team die Arbeitsergebnisse des Sprints und das entwickelte Teilprodukt (Inkrement). Sie diskutieren den Fortschritt in Richtung des finalen Projektziels und legen Anpassungen für den nächsten Sprint fest. Die Rolle der Stakeholder*innen (z. B. Kund*innen, Management, Kolleg*innen aus anderen Unternehmensbereichen) ist es, ihre Erfahrungen und Perspektiven einzubringen. Sie treffen keine Entscheidungen für das Team, sondern unterstützen mit ihren Impulsen und Ideen.

Im Sprint Review präsentiert das Team greifbare Ergebnisse, im besten Fall einen fertigen Prototyp oder eine Funktion. Hierbei sollte jedes Mitglied maximal eine Stunde Vorbereitungszeit investieren. Es sollten keine speziellen Dokumente nur für dieses Meeting erstellt werden, die nach der Review niemanden mehr interessieren. Stattdessen zeigt das Team seine realen Ergebnisse. Hierbei können auch halbfertige Dinge präsentiert werden. Fokus liegt nicht darauf, was das Team gemacht hat, sondern welcher Nutzen für die Kund*innen geschaffen wurde.

Sprint Retrospective: Zusammenarbeit verbessern

Am Ende des Sprints lädt der Scrum Master das gesamte Team zur Sprint Retrospective ein. Hier reflektieren die Teammitglieder ihre Zusammenarbeit während des Sprints. Regelmäßige Retrospektiven helfen dem Team, besser zu werden.

Es gibt viele Methoden, eine Retrospektive durchzuführen. Eine beliebte Variante ist die Keep-Start-Stop-Retrospektive. Dabei stehen drei Fragen im Mittelpunkt:

• Was ist gut gelaufen und sollte beibehalten werden?
• Womit sollten wir anfangen?
• Was ist nicht gut gelaufen und sollte nicht wieder passieren?

Inhaltlich sprechen die Teilnehmer, anders als bei der Sprint Review, nicht über die Arbeitsergebnisse, sondern über den Weg dorthin. Themen können beispielsweise die Kommunikation im Team, bestimmte Prozesse und Abläufe, die Rollenverteilung, verwendete Tools und Methoden oder auch Prinzipien und Regeln sein. Durch regelmäßige Retros gewöhnt sich das Team daran, auch kritische Themen anzusprechen und Probleme offen zu klären.

Die Scrum-Artefakte: Werkzeuge zur effektiven Planung und Organisation

Ein Grundprinzip von Scrum ist es, komplexe Projekte oder Produkte in kleine, überschaubare Teile zu zerlegen und diese in regelmäßigen Abständen zu liefern. Wichtige Werkzeuge hierfür sind die drei im Scrum Guide definierten Artefakte: Product Backlog, Sprint Backlog und Inkrement. Mit ihnen kann das Scrum-Team seine Arbeit effektiv planen und organisieren. Jedem Artefakt ist ein übergeordnetes Ziel (im Scrum Guide „Commitment“ genannt) zugeordnet, das erreicht werden soll.

Product Backlog: dynamische und priorisierte Aufgabenliste

Im Product Backlog sammelt das Scrum-Team alle Anforderungen, Funktionen und Verbesserungsvorschläge für das Produkt oder Projekt. Der Product Owner priorisiert die Einträge aus dem Backlog, so dass die wichtigsten und wertvollsten Elemente zuerst entwickelt werden können. Das Product Backlog wird laufend angepasst und aktualisiert, damit das Scrum-Team immer eine klare Vorstellung davon hat, was als nächstes zu tun ist.

Die einzelnen Einträge des Product Backlogs werden in Form von User Stories, Job Stories, Epics oder Tasks formuliert. In der Regel beschreiben die Einträge den Mehrwert, der für die Nutzer*innen erreicht werden soll. Die Teammitglieder haben so die Möglichkeit, selbstorganisiert und eigenverantwortlich zu entscheiden, wie sie dies erreichen und können ihre fachliche Expertise in die Entwicklung einbringen.

Das oberste Commitment des Product Backlogs – also die verbindliche Zusage des Teams – ist das Produktziel. Dieses beschreibt den zukünftigen Zustand des Produkts oder Projekts, auf den das Team iterativ hinarbeitet. Die einzelnen Backlog-Einträge werden erstellt, um dieses Produktziel zu erreichen. Sie müssen daher immer mit dem Ziel abgeglichen werden. Zahlen sie nicht darauf ein, werden sie nicht in das Product Backlog aufgenommen oder wieder entfernt.

Sprint Backlog: Arbeitspaket für den Sprint

Das Sprint Backlog wird vom Team während des Sprint Plannings erstellt. Dieses „Arbeitspaket“ besteht aus dem Sprintziel und den für den Sprint ausgewählten Product‐Backlog‐Einträgen. Zudem erhält es einen umsetzbaren Plan für die Lieferung des Inkrements. Hierfür zerlegen die Entwickler*innen die einzelnen Einträge in kleinere Arbeitseinheiten und Aufgaben, die an maximal einem Tag abgearbeitet werden können.

Das Commitment ist das Sprintziel: Während des Sprints halten die Entwickler*innen dieses immer im Blick und arbeiten darauf hin.

Inkrement: Zwischenergebnis mit Mehrwert

Ein Inkrement ist ein Zwischenergebnis, das am Ende des Sprints fertiggestellt wird und einen Mehrwert für die Kund*innen oder Nutzer*innen des Produkts darstellt. Das Inkrement ist eine integrierte und funktionsfähige Erweiterung des Produkts. Es enthält alle fertiggestellten Product-Backlog-Einträge, die im Sprint umgesetzt wurden. Ein Inkrement ist somit ein konkreter Schritt in Richtung des Produktziels.

Jedes Inkrement ist additiv zu allen vorherigen zu verstehen. Mit jedem Inkrement wird das Produkt funktionsfähiger und wertvoller, bis das Produktziel bzw. das Endprodukt erreicht ist. Die kontinuierliche Integration von Inkrementen führt zu einer schrittweisen Verbesserung und erhöht somit die Kundenzufriedenheit.

Das Commitment ist die Definition of Done. Sie enthält Kriterien, die ein Inkrement erfüllen muss, um als abgeschlossen zu gelten.

Herausforderungen bei der Scrum-Einführung

Scrum funktioniert fundamental anders als klassische Formen der Projektarbeit. Dies kann anfangs zu Reibungen in der Zusammenarbeit im Team oder mit weiteren Stakeholder*innen führen. Bei der Einführung von Scrum müssen sich die Mitarbeitenden an die neue Arbeitsweise gewöhnen. In vielen eher traditionell organisierten Unternehmen stellen die neuen Rollen und Verantwortlichkeiten im Team sowie der iterative Ansatz einen Bruch mit den bisherigen Arbeitsgewohnheiten dar. Mitunter müssen Teams mit Kolleg*innen neu zusammengesetzt werden, die zuvor noch nicht so zusammengearbeitet haben. Dies kann zu Konflikten über Zuständigkeiten oder Aufgabenverteilung führen.

Typische Herausforderungen

Im Folgenden skizzieren wir weitere typische Herausforderungen, die bei der Einführung von Scrum auftreten und zu Unsicherheiten führen können:

• Angst vor Veränderungen: In traditionell ausgerichteten Unternehmen haben sich über die Jahre feste Strukturen und Prozesse etabliert. Die Einführung von Scrum erfordert Veränderungen, die Ängste und Widerstand auslösen können. Daher ist es ist wichtig, die betroffenen Mitarbeitenden von Anfang einzubeziehen und ihre Bedenken ernst zu nehmen.
• Fehlendes Wissen: Scrum erfordert spezielle Kenntnisse und Erfahrungen, die in vielen Unternehmen nicht vorhanden sind. Mitarbeitende haben oft wenig Erfahrung mit agilen Vorgehensmodellen und Methoden und müssen geschult werden. Zudem bringt das Framework ein eigenes, ungewohntes Vokabular mit sich.
• Konflikte über Rollen- und Verantwortlichkeiten: In klassischen Unternehmen sind die Rollen und Verantwortlichkeiten der Mitarbeitenden oft sehr klar definiert. Bei der Scrum-Einführung kann es zu Konflikten kommen, wenn die Verantwortlichkeiten unklar sind oder sich überschneiden.
• Fehlende Unterstützung durch das Management: Die Einführung von Scrum erfordert die Unterstützung der Führungskräfte im Unternehmen. Wenn diese die Veränderungen nicht unterstützen, kann dies zu Problemen führen. Beispielsweise könnten sie Bedenken hinsichtlich der Umsetzbarkeit und negativer Auswirkungen auf den Geschäftsbetrieb äußern und damit Zweifel säen. Oder sie weigern sich, die notwendigen Mitarbeitenden oder Ressourcen zur Verfügung zu stellen.
• Interaktion mit anderen Teams: Scrum basiert auf einer engen Zusammenarbeit zwischen Team und Stakeholder*innen. In klassisch organisierten Unternehmen ist die Zusammenarbeit oft hierarchisch und formalisiert strukturiert. Wenn es um die Abstimmung der Arbeitsabläufe und die Kommunikation geht, ist es oft schwierig, eine effektive Zusammenarbeit zu etablieren.

Beliebte Fehler in der Praxis

Aber auch in der Praxis von Scrum-Teams werden Fehler gemacht werden, die dazu führen, dass das Framework nicht effektiv eingesetzt wird und nicht die gewünschten Ergebnisse liefert. Hier trifft man oft auf ähnliche Probleme. In den folgenden Abschnitten zeigen wir drei Beispiele für beliebte Fehler in der Anwendung des Scrum-Frameworks, denen unsere Agile Coaches in ihrer Arbeit begegnet sind.

Daily Stand-ups als Statusmeetings

Ein Klassiker unter den Scrum-Fehlern: Teams nutzen das Daily Stand-up als Statusmeeting. Das haben wir zum Beispiel bei einem mittelständischen Unternehmen erlebt. Als Scrum Master hat einer unserer Coaches ein IT-Team unterstützt, das „schon lange mit Scrum arbeitet“. Was schnell auffiel: Die Dailys wurden regelmäßig überzogen, teilweise auf bis zu 60 Minuten. Die Teammitglieder stellten sehr ausführlich dar, was sie am Vortag gemacht hatten und was sie am heutigen Tag vorhatten: “Ich habe das gemacht und dann hat er reagiert und dann ist das passiert. Heute mache ich das, weil…“

Die Organisation hatte sehr viele Kontrollinstanzen eingeführt. Die Teammitglieder nutzten das Daily Stand-up, um allen zu zeigen, dass sie viel zu tun haben.

Das geht an Sinn und Wirkung des Daily Stand-ups vorbei: Die Veranstaltung ist kein Statusmeeting. Es geht nicht darum, sich zu rechtfertigen, sondern den Fortschritt des Sprints transparent zu machen und sich gegenseitig zu unterstützen.

Product Owner und Scrum Master in Personalunion

Ein anderes Problem erlebten wir in einem großen internationalen Konzern: Hier sollten wir ein Team bei der Einführung von Scrum unterstützen. Die Besetzung des Teams und der Rollen erfolgte jedoch vor unserem Kickoff-Termin: Eine Führungskraft übernahm dabei die Rollen Product Owner (PO) und Scrum Master in Personalunion. Der Product-Owner-Scrum-Master hatte zwar keine disziplinarische Verantwortung für das Scrum-Team. Allerdings war sein persönlicher Jahresbonus an den Erfolg des Teams gekoppelt.

Daher war es nicht möglich, die Zusammensetzung des Teams zu ändern und die Rollen auf andere Personen zu verteilen. Der Interessenskonflikt der Person zeigte sich auch auf verschiedenen Ebenen der Zusammenarbeit:

• Jede Form von Iteration und mögliche Rückschritte wurden sofort ans Management kommuniziert, da der Bonus in Gefahr schien.
• Entscheidungen wurden immer mit dem Blick auf den Lenkungskreis getroffen, nicht im Sinne der Kund*innen.
• Das Team vertraute der Person nicht. Die Teammitglieder waren unsicher, ob sie offen über Herausforderungen sprechen konnten, ohne dass dies „gemeldet“ würde.

Dieses Beispiel illustriert sehr gut, warum es wichtig ist, die Rollen PO und Scrum Master auf zwei Personen zu verteilen. Andererseits zeigt es auch, dass die Verknüpfung von persönlichen Boni mit Teamerfolgen die Zusammenarbeit im Team behindern kann. Wenn einzelne Teammitglieder andere Ziele verfolgen als der Rest des Teams, führt dies zu Vertrauensverlust und einer gestörten Zusammenarbeit. Die gesteckten Ziele rücken in weite Ferne.

Die Teilzeit-Sprints

In einem mittelständischen Unternehmen haben wir ein IT-Team als Scrum Master unterstützt. Das neu formierte Scrum-Team durfte jedoch nur einen Teil der täglichen Arbeitszeit für die Scrum-Sprints aufwenden. In der übrigen Zeit wurden die Mitarbeitenden in anderen Teams oder Abteilungen benötigt und übernahmen dort teilweise relevante Schlüsselrollen für den Betrieb. Eine realistische Einschätzung der Sprintziele und der darin geplanten Ressourcen war daher kaum möglich.

Auf Basis dieser Herausforderung haben wir Planning-Poker-Karten mit Zeitangabe entwickelt. Eine Schätzung in (ohnehin sehr komplexen) Story Points erschien uns aufgrund der nur anteiligen Arbeitszeit im Sprint unmöglich. Mit Hilfe unserer Planning-Poker-Karten konnte das Team realistische Arbeitspakete für ihre Teilzeit-Sprints schätzen und aufstellen.

Generell raten wir von dieser Arbeitsweise ab:  Der Fokus auf die vereinbarten Arbeiten im Sprint ist essenziell, um die Sprintziele zu erreichen und die Vorteile des Scrum-Frameworks auszuspielen.

Wann ist Scrum sinnvoll und wo funktioniert Scrum nicht?

Scrum wird mittlerweile in vielen Unternehmen praktiziert. Neben der IT hat sich das Framework in anderen Bereichen wie dem Marketing, der Produktentwicklung und sogar in der Buchhaltung und der Kantine etabliert.

Aber ist Scrum als Framework überall einsetzbar? Benjamin Britten, Lead Product Owner bei der Shop Apotheke, hält das nicht für sinnvoll: „Ich bin ein großer Fan von Scrum: Ich glaube, wenn man das Vorgehensmodell so anwendet, wie man es sollte, erzielt man bessere Ergebnisse. Scrum passt aber nicht auf alle Bereiche. Es ist ein Produktionsprozess. Das Vorgehensmodell funktioniert super für Teams, die Produkte oder Lösungen entwickeln. In anderen Bereichen eignen sich andere Frameworks oder Arbeitsweisen besser. Scrum wird in vielen Organisationen missverstanden. Wer Scrum überall einsetzt, auch da, wo es gar nicht passt, fährt nicht die Erfolge ein, die er gerne haben möchte. Das führt dazu, dass Mitarbeitende aber auch Führungskräfte dann sagen: ‚Das mit der Agilität funktioniert ja doch nicht.‘ Und schon ist Agilität dort verbrannt.“

Scrum eignet sich vor allem in komplexen Umgebungen, in denen Teams schnell auf Veränderungen reagieren müssen. In anderen Situationen oder Arbeitsumgebungen eignen sich andere Frameworks besser. Auch das gute alte Wasserfall-Modell hat nicht ausgedient und beispielsweise in kleineren Projekten mit überschaubarem Zeithorizont und im Voraus planbaren Aufgaben weiterhin seine Berechtigung.

Bei der Auswahl der richtigen Arbeitsweise sollte sich das Team daher zunächst bewusst machen, wie es am besten Wert für Kund*innen und Organisation schafft. Der Agile Framework Navigator von Me & Company hilft dabei, das passende Framework zu finden. Zur Einordnung müssen sich Teams nur zwei Fragen stellen:

• Was ist unser taktisches Ziel? (X-Achse)
• In welcher Arbeitsumgebung bewegen wir uns? (Y-Achse)

Fazit

Das agile Framework Scrum hat sich mittlerweile in vielen Unternehmen unterschiedlicher Branchen etabliert. Durch eine eindeutige Struktur, überschaubare Planungshorizonte und iterative Entwicklung kommen Teams schneller zu besseren Ergebnissen. Die Verteilung der Verantwortung auf die drei Scrum-Rollen sorgt für klare Zuständigkeiten und die Arbeit in Sprints erhöht die Flexibilität und Anpassungsfähigkeit der Teams. Regelmäßiges Feedback führt zu einer kontinuierlichen Verbesserung des Produkts, der Dienstleistung oder Lösung.

Lohnt sich Scrum auch für Ihr Unternehmen? Oder eignen sich andere Frameworks besser, um die Zusammenarbeit zu organisieren? Wir unterstützen Sie gerne bei der Einführung von Scrum und neuen Formen der Zusammenarbeit. Unsere Agile Coaches begleiten Ihre Teams sowohl in der Einführungsphase als auch im Alltag.