Scrum verstehen – eine Einführung in das agile Framework

Scrum zählt zu den bekanntesten Frameworks des agilen Projektmanagements und genießt insbesondere in der Softwareentwicklung besondere Beliebtheit. Im Gegensatz zu einer Methode gibt Scrum als Framework einen losen Rahmen vor, der Raum für den Einsatz von Werkzeugen lässt. Dies ist vor allem dann von Vorteil, wenn das Projektziel noch nicht genau definiert ist und Anpassungen während des Prozesses erforderlich sind. Die Implementierung und Umsetzung des Frameworks in die Strukturen des Unternehmens erfordert jedoch Zeit, da sich das Team und auch die Geschäftsführung erst an die neuen Spielregeln gewöhnen müssen. Mit der Zeit entwickeln sich die Beteiligten jedoch weiter und werden immer versierter im Umgang mit dem Scrum Framework. Doch was zeichnet Scrum überhaupt aus und wieso ist es ein Framework und keine Methode?

Eine Methode stellt eine Reihe von Prinzipien, Werkzeugen und Praktiken zur Verfügung, mit denen Prozesse gelenkt werden, um das Ziel zu erreichen. Es handelt sich um vordefinierte Schritte, die auf diese Weise durchgeführt werden müssen. Somit handelt es sich um eine systematische Lösung, die ihre Grenzen in der Flexibilität hat. Wenn man also ein Projekt hat, in dem wenig Änderungen zu erwarten sind, ist eine Methode wahrscheinlich die bessere Wahl. Im Gegensatz dazu hat ein Framework eine lose, unvollständige Struktur, die viel Raum für andere Werkzeuge und Praktiken lässt. Es muss an die individuellen Probleme angepasst werden und dient nur als Grundgerüst.
Und genau so, als Framework, verhält sich Scrum. Es ist unvollständig und gibt nur die Teile vor, die für die Durchführung des Projekts unbedingt notwendig sind. Es werden keine strikten Vorgaben gemacht, denn die Regeln sollen das Team leiten. Um dieser losen Struktur folgen zu können, gibt es drei Begriffe – die sogenannten Säulen –, die Scrum Stabilität verleihen: Transparenz, Überprüfung und Anpassung.

Offene Kommunikation und Wissensaustausch sorgen für Transparenz im Team, sodass der Prozess für alle sichtbar ist. Jede Entscheidung in einem Projekt wird auf der Grundlage des Zustands der Artefakte getroffen, und wenn diese nicht transparent sind, kann es zu Fehlentscheidungen kommen. Diese können die Qualität des Projekts mindern und das Risiko für den Projekterfolg erhöhen. Schließlich ermöglicht Transparenz auch die Überprüfung der Ergebnisse, da diese offen liegen. 
Durch die regelmäßige Überprüfung der Prozessdokumente kann kontrolliert werden, ob das Vorgehen und die Arbeitsweise überhaupt zielführend sind. Unerwünschte Abweichungen und Probleme können so frühzeitig erkannt und Anpassungen durch Veränderungen ermöglicht werden.
In Scrum ist es wichtig, dass die Rahmenbedingungen umgesetzt werden und wenn etwas nicht akzeptabel ist, muss eine Anpassung erfolgen. Nur so können Abweichungen so schnell wie möglich minimiert werden.

Bei Scrum gibt es keinen Projektmanager, sondern drei zentrale Rollen, welche zusammenarbeiten um ein möglichst optimales Projekt zu erzeugen. Alle Beteiligten haben das Ziel von Scrum im Hinterkopf: in jedem Sprint ein lieferbares Ergebnis zu erzeugen.

Der Product Owner agiert entweder als direkter Kunde oder als dessen Vertreter und trägt die Verantwortung dafür, dass die Anforderungen und Ideen des Kunden in das laufende Projekt einfließen. Er stellt sicher, dass alle Aktivitäten und Aufgaben auf das angestrebte Product Goal ausgerichtet sind und alle Funktionalitäten erfüllt werden, die im sog. Product Backlog definiert sind.
Als Manager des Product Backlogs ist der Product Owner dafür verantwortlich, dass das Produkt einen Mehrwert bietet und wirtschaftlich erfolgreich ist. Er übernimmt daher die Aufgabe, die Einträge im Product Backlog zu erstellen und zu priorisieren, um sicherzustellen, dass das Product Goal erreicht wird. Gemeinsam mit den Developern erarbeitet er das Sprint Goal, also das Ziel eines jeden Sprints. Dabei ist er der zentrale Ansprechpartner für die Developer und sollte deswegen immer gut erreichbar sein.

Der Scrum Master ist für die Förderung und Umsetzung von Scrum im Unternehmen verantwortlich. Das heißt, er ist dafür verantwortlich, dass alle Beteiligten Scrum verstehen und die Handlungsanweisungen, Regeln und Werte befolgt werden. Dazu ist es für den Scrum Master wichtig zu wissen, wie das Unternehmen strukturiert ist: Hierarchisch? Ist Delegation möglich? Gibt es bereits ein Verständnis für agiles Arbeiten? Auf Basis dieser Antworten kann Scrum implementiert und kommuniziert werden.
Ebenso steht der Scrum Master den Developern zur Seite und unterstützt sie im Selbstmanagement, damit sie lernen, ihre Entscheidungen eigenständig zu treffen. Er sollte sicherstellen, dass die Scrum Events korrekt ablaufen, der Zeitplan eingehalten wird und das Team produktiv arbeiten kann. 
Bei Bedarf kann er den Product Owner auch bei der Formulierung des Product Goals und der Erstellung der Product Backlog Items sowie deren Priorisierung unterstützen. Auf diese Weise kann er bei der Implementierung von Scrum helfen und sicherstellen, dass Scrum effektiv umgesetzt wird.

Die Developer kommen aus unterschiedlichen Disziplinen, so dass das Team cross-functional aufgestellt ist. So wird sichergestellt, dass alle Kompetenzen vertreten sind. Die Aufgabe des Teams ist es, gemeinsam mit dem Product Owner das Sprint Backlog zu erstellen und nach jedem Sprint ein nutzbares Increment erstellt zu haben. Dieses Increment muss die „Definition of Done“ erfüllen, die den Zustand beschreibt, dass das Increment die gewünschte Qualität erfüllt. Erst wenn ein Increment die Definition of Done erfüllt, kann es als nutzbar angesehen werden.

Artefakte sind Prozessdokumente, die dem Scrum Team einen Überblick über die Arbeit und die Werte geben. Dazu zählen das Product Backlog, Sprint Backlog und Increment. Zu jedem Scrum Artefakt gehört ein Commitment, zu dem sich das Scrum Team verpflichtet und das Transparenz schafft.

Das Product Backlog wird zu Beginn des Projekts erstellt und enthält alle Anforderungen an das Produkt. Das Product Goal ist das Commitment des Scrum Teams zum Product Backlog. 
Die einzelnen Einträge werden als Product Backlog Items bezeichnet, aus denen das Endprodukt erstellt wird. Sie werden nach Wichtigkeit geordnet und die obersten, die möglichst genau beschrieben sein müssen, werden im nächsten Sprint umgesetzt. Üblicherweise sind Product Backlog Items als User Stories formuliert. Diese geben dem Nutzer die Möglichkeit, Wünsche und Anforderungen an das Endprodukt zu formulieren. User Stories, die einfach umzusetzen sind, werden priorisiert. Diejenigen, die noch zu komplex und umfangreich sind, werden als sogenannte Epics weiter unten im Product Backlog priorisiert. Da das Product Backlog immer wieder aktualisiert wird, werden auch die Einträge immer wieder neu bewertet. Es ist wichtig immer wieder zu überprüfen, ob einige Einträge bereits veraltet sind und entfernt werden sollten. 
Wenn die Einträge der Definition von Ready entsprechen, d. h. wenn die Einträge von den Developern verstanden wurden und bereit sind, im nächsten Sprint umgesetzt zu werden, und wenn sie dem entsprechenden Sprint Goal entsprechen, werden sie in das Sprint Backlog verschoben.

Im Sprint Backlog werden die User Stories abgelegt, die im aktuellen Sprint umgesetzt werden sollen. Im Laufe eines Sprints werden diese abgearbeitet, um das im Sprint Planning Meeting festgelegte Sprint Goal zu erreichen. Das Sprint Goal stellt das Commitment für das Sprint Backlog dar. 
Die User Stories im Sprint Backlog sollten auch priorisiert werden, damit die Developer wissen, woran sie zuerst arbeiten sollen. Gleichzeitig sollten Tasks formuliert werden, die zur Umsetzung der User Stories dienen. Außerdem sollte immer festgehalten werden, woran gerade gearbeitet wird und was bereits erledigt ist. Stellt man fest, dass eine User Story zu lange bearbeitet wird, gilt es herauszufinden, woran das liegt und Gegenmaßnahmen einzuleiten.

Ein Increment ist ein wesentlicher Schritt zur Erreichung des Product Goals und gleichzeitig das Hauptziel eines jeden Sprints. Am Ende sollte ein erfolgreich getestetes und nutzbares Teilprodukt stehen, das in Kombination mit anderen Increments das Endprodukt bildet. Um dieses Ziel zu erreichen, ist es unerlässlich, die Definition of Done zu erfüllen. Die Definition of Done dient dabei als Commitment des Increments: Nur Arbeiten, die die Anforderungen der Definition of Done erfüllen, können als vollständiges Increment betrachtet werden.

Im Scrum Framework gibt es fünf Events, die in einer festen Abfolge stattfinden und zeitlich begrenzt sind, um die Effizienz zu erhöhen. Diese sind Sprint, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective. Die Begriffe beziehen sich auf den jeweiligen Sprint und finden im Rahmen dieses Sprints statt. Ein Sprint ist also wie ein „Container“ für alle anderen Events. Sobald ein Sprint endet, beginnt ein neuer und in jedem Sprint wird auf das Sprint Goal hingearbeitet, um ein Increment zu erstellen, das zum Endprodukt beiträgt. Ein Sprint sollte nicht länger als vier Wochen dauern, da so Anpassungen schneller vorgenommen werden können und das Risiko, dass ein Fehler zu lange unentdeckt bleibt, minimiert wird.
Während jedes Sprints findet zwischen dem Sprint Planning Meeting und dem Sprint Review die eigentliche Entwicklungsarbeit, das Sprinting, statt. Zusätzlich wird jeden Tag ein Daily Scrum Meeting abgehalten.
Im Sprint Planning Meeting, das vor dem Sprinting stattfindet, wird der kommende Sprint geplant. Dazu werden Einträge aus dem Product Backlog ausgewählt, die zum Sprint Goal passen.
Das Daily Scrum findet jeden Tag zur gleichen Zeit statt und ist ein Muss für alle Beteiligten. Hier bringen sich die Developer in aller Kürze, in maximal 15 Minuten, auf den neuesten Stand. Was wurde gemacht, was ist für heute geplant und welche Dinge haben den Workflow gestört? Es soll ein reger Austausch zwischen allen Developern stattfinden.
Das Sprint Review findet nach dem Sprinting statt. Hier werden die Ergebnisse überprüft und eventuelle Anpassungen für zukünftige Sprints besprochen. Ebenso wird die Abnahme der Increments besprochen, wobei der Product Owner diese auch testen kann und offen seine Meinung dazu äußert, damit sich die Developer gegebenenfalls verbessern können. Auf diese Weise wird überprüft, ob das Sprint Goal erreicht wurde und ob Fortschritte in Richtung Product Goal gemacht wurden. Sollte dies nicht der Fall sein, werden nicht abgeschlossene Product Backlog Items wieder in das Product Backlog aufgenommen. 
Direkt im Anschluss an das Sprint Review kann die Sprint Retrospective stattfinden. Hier wird die Arbeitsweise bewertet und die Developer diskutieren über mögliche Produktivitäts- und Prozessverbesserungen. Sie stellen sich die Frage, was in zukünftigen Sprints besser gemacht werden kann.

Wenn es noch keinen richtigen Workflow gibt, kann es viele Herausforderungen geben. In solchen Situationen ist es oft unvermeidlich, Kompromisse einzugehen. Es ist jedoch wichtig, sich immer zu fragen, ob diese Kompromisse das Engagement des Teams negativ beeinflussen könnten. Wenn dies der Fall ist, sollte sorgfältig über alternative Wege nachgedacht werden, um die Herausforderungen effektiv zu bewältigen.

Widerstände bei der Einführung von Scrum können oft entstehen, wenn das Unternehmen inkonsequent handelt und wenig Anreize schafft. Um dies zu vermeiden, sollte auf die Sorgen und Ängste der Mitarbeitenden eingegangen werden, damit sie sich wahrgenommen und wertgeschätzt fühlen. Eine gute Möglichkeit, Widerständen entgegenzuwirken, besteht darin, zunächst das beste Team in Scrum einzuführen. Denn durch den Erfolg des besten Teams, auch wenn es am Anfang noch etwas holprig ist, kann die Motivation auf die anderen Teams überspringen und die Skepsis nimmt ab. 
Es ist wichtig, den Mitarbeitenden Zeit, viel Hilfe und Unterstützung zu geben. Coachings und Trainings können helfen, das Team selbst, aber auch den Umgang mit Scrum zu schulen.
Durch die Daily Scrums kann ein Gefühl der Kontrolle entstehen, daher sollte aufgezeigt werden, welche Freiheiten dadurch gewonnen werden. Schließlich arbeitet das Team völlig selbstständig, unterstützt sich gegenseitig und kommt so zum Ziel.

Wenn im Team nicht klar ist, wer wofür verantwortlich ist, kann es schnell zu Verzögerungen oder sogar zum Scheitern des Projekts kommen. Deshalb müssen die Rollen von Anfang an klar definiert und Unsicherheiten schnell ausgeräumt werden. Dazu muss das Team zusammenarbeiten. Besonders wichtig ist dabei der Scrum Master. Er hat die Aufgabe, Scrum im Team und damit bei den Developern zu implementieren. Wenn er merkt, dass sich die Mitglieder über ihre Aufgaben nicht im Klaren sind, muss er eingreifen und gegebenenfalls Workshops durchführen, damit den Mitgliedern bewusst wird, worauf es ankommt und sie sich über ihre Rolle in Scrum im Klaren sind.

Die Zusammenarbeit und Kommunikation im Team hängen unter anderem von der Zusammensetzung des Teams ab. Das Team sollte über Eigenschaften, Kenntnisse und Fähigkeiten verfügen, die sich gegenseitig ergänzen. Die Wünsche der zukünftigen Teammitglieder sollten berücksichtigt werden, da einige von ihnen vielleicht bereits zusammengearbeitet haben und daher wissen, wer mit wem am besten harmoniert, auch wenn sich das Team natürlich erst im Laufe der Zeit zusammenfindet und einspielt. Wichtige Eigenschaften, die die Teammitglieder mitbringen sollten, sind eine gute und offene Kommunikation, so dass auch Probleme direkt besprochen oder Hilfestellungen sofort gegeben werden, Engagement, d. h. dass die Teammitglieder motiviert sind, ihre Aufgaben zu erledigen können, Selbstkontrolle, da sie sich selbst organisieren müssen, sowie Loyalität und Fairness. Auch wenn die Teammitglieder einige dieser Eigenschaften mitbringen, kann es natürlich zu Problemen kommen. Dafür gibt es den Scrum Master, der die Teambildung unterstützen kann, indem er Konflikte löst oder eine vernünftige Streitkultur etabliert. Gerade hier sind die Offenheit und Kommunikationsfähigkeit der Teammitglieder von großem Vorteil.
Eine Möglichkeit, die dem Scrum Master zur Verfügung steht, ist die Teambildung nach Tuckman. Dazu gehören unter anderem Teambildungsworkshops, in denen formale, also arbeitstechnische, aber auch persönliche Anliegen besprochen werden. Sollte es Konflikte in früheren Projekten gegeben haben, können diese hier ebenfalls besprochen und im Idealfall gelöst werden. In den nächsten Phasen lernen sich die Mitglieder langsam kennen und organisieren sich selbst. Jeder weiß mit der Zeit, was seine Aufgabe ist und der Scrum Master kann sich um andere Dinge kümmern. 
Generell sollte darauf geachtet werden, die Fluktuation so gering wie möglich zu halten, damit das Team auf einem konstant guten Niveau bleibt.

Der Product Owner legt fest, welche Product Backlog Items zuerst umgesetzt werden. Auch wenn der Product Owner die Wünsche des Kunden im Hinterkopf hat, ist es nicht immer einfach, die Einträge entsprechend zu priorisieren. Hier kann das Kano-Modell helfen. Dieses stellt den Zusammenhang zwischen Kundenzufriedenheit und realisiertem Qualitätsmerkmal grafisch dar. Die Kundenzufriedenheit kann zwischen niedrig und hoch variieren, die Qualität zwischen nicht erfüllt und erfüllt. Es gibt drei verschiedene Merkmale, die von besonderer Bedeutung sind: Basismerkmale, die vom Kunden vorausgesetzt werden und daher selbstverständlich sind. Sie machen den Kunden aber nicht zufriedener, wenn sie vorhanden sind, sondern fallen erst auf, wenn sie fehlen, weil der Kunde dann unzufrieden ist. Leistungsmerkmale werden aktiv nachgefragt und können durch Marktbeobachtung entdeckt werden. Sie machen den Kunden zufrieden, wenn sie vorhanden sind, und unzufrieden, wenn sie fehlen. Begeisterungsmerkmale sind nicht selbstverständlich und werden nicht aktiv nachgefragt. Sie machen den Kunden nicht unzufrieden, wenn sie nicht vorhanden sind, aber überproportional zufrieden, wenn sie vorhanden sind. Auf diese Weise lässt sich herausfinden, welche Merkmale zuerst umgesetzt werden sollten. Denn wenn man sich durch ein Begeisterungsmerkmal vom Rest des Marktes abheben kann, lohnt es sich manchmal, dieses zuerst umzusetzen.

Scrum eignet sich vor allem für Projekte ohne fest definiertes Ziel und ohne festen Zeitrahmen, da das Projekt agil in kurzen Sprints von einem selbstständig arbeitenden Team umgesetzt werden kann. Die Freiheit des Teams bringt jedoch auch viele Unsicherheiten mit sich - sowohl für das Team, das sich erst an die Vorgehensweise gewöhnen muss, als auch für den Kunden, der nicht genau weiß, wann das Projekt abgeschlossen sein wird und welches Budget benötigt wird. Hier ist es besonders wichtig, dass der Scrum Master alle Beteiligten im Blick hat und mit allen an einem Strang zieht. Im Laufe des Projekts entwickeln sich aus den Herausforderungen immer mehr Lösungsansätze und man erkennt, wann das Framework an seine Grenzen stößt und wie es weitergehen soll.

Sie wollen noch tiefer in das Thema einsteigen? Dann empfehlen wir Ihnen unsere Weblearning-Plattform "Certified Junior Agile Project Manager (IAPM)".