Scrum – Der Ursprung agiler Arbeitsmethoden

Wer im angelsächsischen Raum fragt, was Scrum bedeutet, bekommt vermutlich eine kleine Einführung in Sportwissen. Denn im Rugby benennt Scrum eine besondere Formation: Alle Spieler bewegen, eng zusammengedrängt, gemeinsam den Ball hin und her über das Spielfeld um ihr Ziel zu erreichen. 

Was hat das jetzt mit IT und Softwareentwicklung zu tun hat? 1986 stellten die japanischen Professoren Hirotaka Takeuchi und Ikujiro Nonaka fest, dass die Produktentwicklung flexibler und schneller werden sollte und berichteten im Harvard Business Magazine erstmals über neue Taktiken, wie etwa den “Rugby approach”. Diese Analogie nutzten die US-amerikanischen Softwareentwickler Ken Schwaber und Jeff Sutherland und entwickelten den 2011 erstmals erschienen sogenannten Scrum Guide. 

Warum ist Scrum entstanden?

Der Software- und EDV-Markt ist in den 1980er Jahren explodiert: computergestützte Systeme etablierten sich und der Bedarf an moderner Software stieg rasant an. Der Markt wurde innovativer und von immer neuen Ideen und Weiterentwicklungen überschwemmt. Das hatte zur Folge, dass Softwareprojekte immens teuer wurden, oder neue Produkte bereits bei veraltet waren, wenn sie erschienen. (hier ein Beispiel aus 2017). Das verschlang unnötig Geld und Ressourcen. 

Es mussten also neue Arbeitsweisen her. Die oben erwähnten Softwareentwickler Sutherland und Schwaber begannen mit ihrer Arbeit an einem neuen Framework und veröffentlichten 1995 ihren ersten Beitrag über Scrum. Daraus entwickelten sie in den nachfolgenden Jahren den offiziellen Scrum Guide, der zuletzt 2020 in neuer Version erschien. Inzwischen wird Scrum in immer mehr Arbeitswelten auch außerhalb der IT angewendet.

Was genau ist Scrum?

Scrum ist ein sogenanntes Framework (Rahmenwerk) zur Entwicklung komplexer Produkte oder Dienstleistungen. Dabei wird die Entwicklung des Produkts in sich wiederholenden (iterativen) und aufeinander aufbauenden (inkrementellen) Schritten von einem Scrum Team durchgeführt. Das Ergebnis dieser Schritte ist jeweils ein Mini-Produkt, also ein sogenanntes „Inkrement“ das auf Funktionalität und Kundenbedarf getestet wird. Somit wird in jedem Schritt für die nächste Wiederholung gelernt und das Produkt angepasst. Dieses Vorgehen minimiert Risiken und sorgt dafür, dass schon früh im Entwicklungsprozess ein funktionierendes Produkt entsteht. 

Damit stellt Scrum eine flexible und dynamische (agile) Alternative zur klassischen Produktentwicklung dar, in der oft jahrelang an einem Produkt entwickelt wird und sich erst am Ende eines riesigen Zykluses zeigt, ob das Produkt technisch und am Markt funktioniert.

Wie funktioniert Scrum?

Scrum funktioniert auf Basis von gemeinsamen Werten und festen Steuerungselementen. Auf diesem Fundament aus Werten und Säulen arbeitet das Scrum Team in festgelegten Rollen, mithilfe klar definierter Events innerhalb eines Sprints an verschiedenen Anforderungen und Inkrementen.

Was ist die Basis für Scrum?

Die fünf grundlegenden Werte im Scrum sind Offenheit, Commitment, Fokus, Mut und Respekt. 

Warum sind die Scrum-Werte so wichtig? Beispiel: Ein Team präsentiert das Ergebnis des Arbeitszyklus und bittet um Feedback, um das Produkt zu verbessern. In der Organisation herrscht allerdings keine Kultur von Offenheit und Mut, so dass sich niemand traut offenes Feedback zu geben und auf Schwachstellen in dem Produkt hinzuweisen. Das Team präsentiert, alle lächeln und nicken und das Team macht mit einem fehlerhaften Produkt weiter. So ein Meeting ist für alle Zeitverschwendung. Die oben genannten fünf Werte bilden also die Grundvoraussetzung für den erfolgreichen Einsatz von Scrum. 

Die 3 grundlegenden Elemente zur Steuerung des gesamten Scrum Prozesses (auch Säulen genannt) sind: Überprüfung (Inspect), Anpassung (Adapt) und Transparenz. 

Was bedeutet dieses transparente Inspect & Adapt in der Praxis?  

Der oben beschriebene iterative (sich wiederholende) und inkrementelle (aufeinander aufbauende) Ansatz von Scrum wird durch sogenannte Sprints verwirklicht. Sprints sind feste Zyklen, die eine bis vier Wochen dauern können. Innerhalb eines Sprints arbeiten die Teams an ihrem Produktziel. Am Ende eines Sprints wird dann das geschaffene, nutzbare Produkt, das sogenannte Inkrement, überprüft (inspect) und festgelegt, wie das Produkt angepasst werden soll (adapt). Dabei ist alles Wissen zum Produkt, das Vorgehen und der aktuelle Stand allen Beteiligten klar (transparent).

Welche Rollen und Aufgaben gibt es bei Scrum-Projekten?

In einem Scrum Team gibt es keine Hierarchien und spezielle Titel. Warum? Es geht um Kommunikation auf Augenhöhe und möglichst geteiltes Wissen anstelle von Zuständigkeitsbereichen und Wissensinseln. Dennoch gibt es drei verschiedene Rollen in einem Scrum Team:

• Entwickler – Entwickler bauen das Produkt und setzen die Anforderungen um. Sie entscheiden, wie das Produkt gebaut wird. Dabei ist wichtig dass sie crossfunktional, d.h. bereichsübergreifend, aufgestellt sind, um ihr Produkt eigenständig entwickeln und betreuen zu können.
• Product Owner –  Product Owner haben die Vision für das Produkt. Sie sind dafür zuständig den Wert des Produkts zu maximieren. Dazu gehört ein ständiger Abgleich: was wollen die Kunden? Was passiert am Markt? Was wollen die Stakeholder? Das unter einen Hut zu bringen und zu entscheiden was als nächstes getan wird ist Job des Product Owners (PO).
• Scrum Master – Scrum Master sind für die Effektivität des Teams verantwortlich. Sie sorgen dafür, dass das Team sich hinterfragt, aus Fehlern lernt und sich weiterentwickelt. Sie optimieren Prozesse und Kommunikation und tragen dafür Sorge wie das Team zusammenarbeitet.

Das Besondere an diesen Rollen ist die Aufteilung in Prozess- und Produktverantwortung. 

In klassischen Projekten gibt es meist einen Teamleiter, der für Prozesse und Produkt verantwortlich ist. Dadurch entsteht aber oft ein Ungleichgewicht – steht das Produktziel zu sehr im Mittelpunkt, leidet die Zusammenarbeit im Team. Kümmert sich der Projektleiter zu sehr um Prozesse wird schnell das Produktziel aus den Augen verloren. 

Zudem benötigen beide Bereiche unterschiedliche Kompetenzen. Die Auftrennung dieser Verantwortungsbereiche in zwei Rollen ermöglicht, dass beide Aspekte genug Raum einnehmen und sowohl eine gute Produkt-, als auch eine gute Teamentwicklung stattfinden kann. Denn nur mit einem sich stetig weiterentwickelndem Team kann ein wirklich herausragendes Produkt geschaffen werden.

Welche Ereignisse (Events) gibt es in Scrum?

Ein Scrum Team arbeitet in festgelegten Zeiträumen (Sprints) an einzelnen Produktentwicklungsschritten. Innerhalb des Sprints finden verschiedene Events statt. Diese helfen dem Team sowohl dabei gut zusammenzuarbeiten und ihr Sprint Ziel zu erreichen.

• Planning – Das Planning startet einen neuen Sprint Zyklus. Das ganze Scrum Team kommt zusammen, der Product Owner zeigt auf wie der Wert des Produkts im nächsten Sprint gesteigert werden kann. Daraufhin definiert das Team sowohl Sprint Ziel als auch die Aufgaben der nächsten Wochen. Dabei ist es für das Team wichtig, möglichst genau abzuschätzen, wie viel es wirklich schafft. Es sollte sich weder permanent über-, noch unterschätzen. Hier zählt der Wert Commitment – denn das Team sollte das, was es sich vornimmt, auch erreichen.
• Daily – Das Daily dauert maximal 15 Minuten und findet täglich zu einer festen Zeit statt. Hier tauschen sich die Entwickler aus und bewerten, wie die Arbeit am Sprintziel bisher läuft und entscheiden, ob Änderungen an einzelnen Aufgaben oder am Sprintziel vorgenommen werden müssen. Es ist zu vergleichen mit der Halbzeitbesprechung im Teamsport, in der alle zusammenkommen und gemeinsam überlegen wie sie es schaffen zu gewinnen. Wichtig: Das Daily ist nicht für Status updates gedacht!
• Review – Der Review findet am Ende eines Sprints statt und konzentriert sich auf das Produkt. Hier stellen die Entwickler das aktuelle Inkrement vor. Die relevanten Stakeholder und Kunden haben die Möglichkeit dieses zu testen und Feedback zu geben: Was ist gut daran, was gefällt nicht, was kann und sollte besser werden? Wichtig: Das Review ist kein Ort für reine Powerpoint Präsentationen!
• Retrospektive (Retro) – Die Retro schließt an den Review an und fokussiert sich auf die Prozesse. Hier kommt das gesamte Scrum Team zusammen und bespricht die Zusammenarbeit im letzten Sprint. Wie können wir effektiver werden? Ziel ist es, mindestens eine Veränderung abzuleiten, um sich als Team im nächsten Sprint zu verbessern. Die Retrospektive wird vom Scrum Master moderiert und schließt den Sprint final ab. 
• (Refinement) – dieses Event ist kein offizielles Event im Scrum Guide, wird aber von vielen Scrum Teams während eines Sprints genutzt. Hier kann die Arbeit für den nächsten Sprint schonmal vorbesprochen werden. Welche Anforderungen stehen vor der Tür? Wie lassen sie sich umsetzen? Wie aufwändig schätzen wir diese Aufgabe, wie wichtig ist welche Aufgabe?

Welche Artefakte gibt es?

Als Artefakte werden im Scrum bestimmte Arbeitsergebnisse oder geschaffene Werte bezeichnet. Sie sind nicht statisch, sondern werden stetig adaptiert. Sie dienen der Transparenz und dem Fokus und helfen dabei, den Produktfortschritt abzuschätzen.

• Produkt Backlog – Das Produkt Backlog ist eine priorisierte Sammlung aller Anforderungen an das Produkt. Je weiter oben die Einträge stehen, desto ausgearbeiteter sollten sie sein. Die priorisierten Einträge übernimmt das Scrum Team in seinen nächsten Sprint. Maßgeblich für die Organisation des Produktbacklogs ist das zukünftige Produktziel. Es bietet Orientierung, nach Inspect & Adapt, aber auch Spielraum für Anpassungen.
• Sprint Backlog – Das Sprint Backlog beinhaltet drei Komponenten: Das Sprintziel, die Sammlung an Anforderungen, die im aktuellen Sprint umgesetzt werden und den Plan, wie die Anforderungen zu einem funktionierenden Inkrement umgesetzt werden können.
• Produktinkrement – Das Produktinkrement ist ein wertstiftender, das heißt funktionstüchtiger, Schritt in Richtung Produktziel und Ergebnis eines Sprints. Wann eine Anforderung als umgesetzt und damit als eigenständiges Inkrement angesehen und in der Review präsentiert werden kann, legt das Team selbst fest. Die sogenannten Definition of Done (DoD) beinhaltet alles, was nötig ist, um das zu erstellende Inkrement nutzen zu können. Die DoD unterliegt ebenfalls dem Inspect & Adapt-Prinzip und verändert sich mit der Weiterentwicklung des Teams.

Wie groß ist ein Scrum Team? 

Ein gutes Scrum Team ist klein aber fein. Es besteht aus maximal 10 Personen. So zumindest beschreibt es der Scrum Guide. Diese Größenordnung hat sich in der Praxis durchaus bewährt. Denn, je mehr Personen involviert sind, desto mehr potenzielle Kommunikationswege, Raum für Missverständnisse und verlorengegangene Infos gibt es. Abstimmungen und gemeinsamer Fokus fällt in kleineren Teams oft leichter.

Wie viele Sprints braucht man in Scrum?

Die Anzahl der Sprints hängt vom Produkt ab. Grundsätzlich kann unendlich lange gesprintet werden. Aber: schon am Ende des ersten Sprints wird es ein funktionierendes marktfähiges Produkt geben. Es wird wahrscheinlich nur die notwendigsten Features umfassen, aber schon während des gesamten Entwicklungsprozess wirklich nutzbar sein. Wann macht es keinen Sinn mehr weiter zu sprinten? Es sind keine weiteren Sprints mehr nötig, wenn das Produkt nicht mehr weiterentwickelt werden muss, weil es perfekt ist oder nicht mehr benötigt wird.

Welche Grenzen hat Scrum?

Agilität und Scrum sind gerade en vogue. Aber: nur weil es grade in ist, heißt das nicht, dass jedes Unternehmen auf Biegen und Brechen Scrum einführen sollte. 

Wer Scrum einführen will, sollte sich zunächst fragen: Was möchte ich mit Agilität und Scrum erreichen? Warum brauche ich Agilität? Welches Risiko möchte ich minimieren, wo bin ich unsicher welcher Schritt als nächstes zu gehen ist? Wie flexibel muss ich auf Veränderungen reagieren und wie schnelllebig ist mein Markt? Wenn glasklar ist, was wie zu tun ist, dann ist Scrum nicht der richtige Weg.
Zudem ist wichtig, Scrum nicht als reine Methode zu sehen, die schon funktioniert, weil Events und Rollen eingeführt werden. Scrum muss und sollte vielmehr individuell angepasst werden. Jede Organisation muss experimentieren, wie sie am effektivsten arbeiten und Wert schaffen kann.

Wie kann ich Scrum anwenden? 

Ob und wie Scrum Dir bei Deiner Arbeit helfen kann, erfährst Du in unserem Grundlagenworkshop Scrum. Hier zeigen wir Dir interaktiv und mit vielen Praxisbeispielen, wie Scrum funktioniert, und was Du aus Scrum für Deinen Job mitnehmen kannst. Nur Scrum ist Dir zu einseitig? Dann ist unser Workshop Agile Methoden – verstehen und anwenden vielleicht das richtige. Hier geht es einen Tag lang neben Scrum auch um Kanban, Design Thinking und weitere Methoden und Werkzeugen für agiles Arbeiten – natürlich auch praxisnah und interaktiv.