Warum Scrum kein Prozess ist

Written by Stefan Döbrich

1. März 2021

}
7 minutes

Stellenausschreibungen für Scrum Master finden sich inzwischen quer durch alle Branchen. Nicht alle dieser Anzeigen beschreiben die Tätigkeiten eines Scrum Masters korrekt, und oft lässt sich an den gewählten Formulierungen der agile Reifegrad des Unternehmens ablesen. Ein häufiger Fehler betrifft die Beschreibung des Scrum Masters als die Person, die für die Implementierung und Ausführung des “Scrum-Prozesses” verantwortlich ist. Dieser Artikel erklärt, warum Scrum kein Prozess ist und wie der Entwicklungsprozess eines Unternehmens in Scrum eingebettet werden kann.

Wie Scrum Definiert ist

Lasst uns zunächst einen Blick darauf werfen, wie der Scrum Guide selbst Scrum definiert. Das gibt uns einen gültigen und soliden Ausgangspunkt für unsere Überlegungen.

Scrum ist ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren.

Scrum ist ein Framework, das uns hilft, Lösungen für Probleme zu finden. Schon die Definition des Scrum Guide macht deutlich, dass Scrum kein Prozess ist. Darüber hinaus stellt der Scrum Guide auch eine Beziehung zu den Prozessen innerhalb einer Organisation her.

Innerhalb des Rahmenwerks können verschiedene Prozesse, Techniken und Methoden eingesetzt werden. Scrum umhüllt bestehende Praktiken oder macht sie überflüssig. Scrum macht die relative Wirksamkeit des aktuellen Managements, der Umgebung und der Arbeitstechniken sichtbar, sodass Verbesserungen vorgenommen werden können.

Scrum hat daher die Fähigkeit, mit bestehenden Prozessen und Abläufen einer Organisation integriert zu werden. Es bietet der Organisation Grundregeln und einen Rahmen, in dem Anforderungen durch den Entwicklungsprozess in ein Produkt umgewandelt werden. Schauen wir uns nun genauer an, warum Scrum kein Prozess ist, was es Organisationen als Framework bietet und wie bestehende Prozesse eine Umsetzung in Scrum finden können.

Verwandtes Material

The Scrum Guide

Scrum is a framework for developing and sustaining complex products. This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together. Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and provided by them. Together, they stand behind the Scrum Guide.

Warum Scrum kein Prozess ist

Let’s first take a look at the definition of a process. This will give us our first clues as to why Scrum is not a process. The American National Standards Institute (ANSI) defines a technical process as follows.

In der Technik ist ein Prozess eine Reihe von zusammenhängenden Aufgaben, die zusammen die Eingaben in eine bestimmte Ausgabe umwandeln.

ANSI/EIA-632-1998 Processes for Engineering a System, Appendix A, p66

Eine sehr ähnliche Definition liefert das Deutsche Institut für Normung (DIN).

Gesamtheit der wechselwirkenden Prozesse in einem System, durch die Materie, Energie oder Information umgewandelt, transportiert oder gespeichert wird.

DIN IEC 60050-351: Internationales Elektrotechnisches Wörterbuch – Teil 351-21-43: Leittechnik

Wie wir sehen, umfasst ein Prozess alle Vorgänge innerhalb eines Systems, die notwendig sind, um einen gegebenen Input in einen entsprechenden, gewünschten Output umzuwandeln, zu transformieren oder zu verarbeiten. Im Scrum Guide gibt es jedoch keine Aussage über auch nur einen dieser Punkte. Demnach kann Scrum per Definition kein Prozess sein. Das wirft die Frage auf, was Scrum dann ist. Schauen wir uns an, was Scrum einer Organisation an Methoden und Werkzeugen bietet und wie sich diese von einem Prozess unterscheiden.

Was Scrum Dir und Deinem Team bietet

Der Scrum Guide definiert die folgenden Mehrwerte für Scrum-Teams. Die fünf Scrum Events, die fünf Scrum Values, die drei Scrum Artefakte und die drei spezifischen Verantwortlichkeiten des Scrum Masters, des Product Owners und der Entwickler.

Um zu verstehen, warum Scrum kein Prozess ist, müssen wir uns die fünf Scrum Events genauer ansehen. Der Sprint dient als Container für alle anderen Ereignisse. Dabei schafft der Sprint einen Rahmen für kurze Iterationszyklen und damit auch für kurze Feedbackschleifen.

Der Sprint wird durch die drei Ereignisse Sprint Planning, Sprint Review und Sprint Retrospective eingerahmt. Innerhalb dieses Rahmens werden die Anforderungen aus dem Sprint Backlog verarbeitet und zum Inkrement umgewandelt. Das Daily Scrum schafft noch kürzere Planungs- und Feedback-Zyklen auf täglicher Basis. Die Anzahl der Daily Scrum-Events innerhalb Ihres Sprints hängt natürlich von der Länge des Sprints ab.

Wie wir sehen, definiert Scrum selbst nicht den Entwicklungsprozess, aber es definiert ein Framework, innerhalb dessen Prozesse etabliert werden können. Schauen wir uns an, wie Scrum und Prozesse miteinander kombiniert werden.

Verwandtes Material

Mastering Professional Scrum

The authors aim to help you focus on proven Scrum approaches for improving quality, getting and using fast feedback, and becoming more adaptable, instead of going through the motions and settling for only modest improvements.

Die Verbindung von Scrum und Prozessen

Die fünf Scrum Events bilden den PDCA-Zyklus in einer Scrum-Organisation. Um die Kombination von Scrum und Prozessen näher beleuchten zu können, müssen wir uns die Scrum Events und ihren Zweck genauer ansehen.

Während des Sprint Planning erstellt das Scrum Team das Sprint Backlog aus vier Inputs. Diese sind das Inkrement des letzten Sprints, das Product Backlog, die Velocity des Teams und seine voraussichtliche Kapazität für den nächsten Sprint. Im Ergebnis ist das Sprint Backlog der mittelfristige Plan des Scrum Teams für die Aufgaben, die in den kommenden Wochen erledigt werden sollen.

Im Sprint Review betrachten das Scrum Team und die Stakeholder das Ergebnis des letzten Sprints. Hier wird ein Blick auf das Sprint Backlog und alle erledigten Aufgaben geworfen. Das Inkrement wird inspiziert und es wird besprochen, welche Aufgaben und Schritte als nächstes in Bezug auf das Produkt umgesetzt werden können. Das Ergebnis ist ein überarbeitetes Product Backlog. Dieses wiederum dient als Input für das nächste Sprint Planning.

In der Sprint Retrospektive inspiziert das Scrum Team sich selbst, seine Prozesse, Werkzeuge und Techniken. Der Fokus liegt dabei auf möglichen Verbesserungen, die im nächsten Sprint oder einem der folgenden Sprints umgesetzt werden können. Diese werden als Tasks in das Product Backlog aufgenommen und können somit auch im nächsten Sprint Backlog nach dem Sprint Planning erscheinen.

Im Gegensatz dazu wird beim Daily Scrum ein kleiner PDCA-Zyklus auf Tagesbasis durchgeführt. Hier werden die Rückschau auf die Ergebnisse des letzten Tages und die Planung der nächsten Schritte im selben Event abgehandelt. Das Ziel des Daily Scrum ist die Erstellung eines Plans für die Aufgaben, die das Scrum-Team in den nächsten 24 Stunden erledigen will. Hier wird eine sehr kurze Feedbackschleife etabliert.

Der Zusammenhang zwischen Scrum und den Entwicklungsprozessen einer Organisation wird nun langsam deutlicher. Zu Beginn eines Sprints dient das Sprint Planning einem Scrum Team als Planungsveranstaltung. Hier werden die zu realisierenden Anforderungen ausgewählt und unter einem klaren Sprintziel im Sprint Backlog zusammengefasst. Am Ende eines jeden Sprints wird das Inkrement überprüft und die nächsten Umsetzungsschritte in Absprache mit den Stakeholdern diskutiert. Das Ergebnis ist eine überarbeitete Version des Product Backlogs.

Es gibt jedoch eine Frage, die von Scrum nicht beantwortet wird. Das ist die Frage nach der Art und Weise, wie Anforderungen in Inkremente umgewandelt werden. Dies geschieht durch den Entwicklungsprozess. Dieser Prozess variiert von Organisation zu Organisation. Er kann sogar zwischen Teams der gleichen Organisation unterschiedlich sein.

Scrum und seine Werte, Artefakte, Ereignisse und Verantwortlichkeiten sind für alle Organisationen auf der Welt gleich. Der Entwicklungsprozess ist die Menge der Schritte, Verfahren und Regeln, durch die eine Anforderung in einen Teil des Endprodukts umgewandelt wird. Dieser Prozess ist nicht durch Scrum definiert. Deshalb ist Scrum auch kein Prozess. Scrum bietet einen organisatorischen Rahmen und eine Grundlage für die Umsetzung des eigentlichen Entwicklungsprozesses.

Wie Scrum Teams Lessons Learned Workshops Durchführen

Abschließende Gedanken

Nachdem wir nun den Unterschied zwischen Scrum und einem Entwicklungsprozess herausgearbeitet haben, bleibt noch Platz für einige abschließende Worte. Scrum bietet Teams einen Rahmen mit kurzen Feedbackschleifen, um ihre Ablauforganisation zu strukturieren. Dieser Rahmen wird durch den Sprint und die anderen vier Scrum Events gebildet. Innerhalb dieses Rahmens liegt es an den Teams und Organisationen, effektive und effiziente Prozesse zu definieren. Tatsächlich wäre auch die Implementierung von Wasserfall Prozessen innerhalb von Scrum möglich, wird aber aus Gründen der Risikominimierung nicht empfohlen. (Bitte wählt und definiert Eure Prozesse verantwortungsvoll!) Scrum ist kein Prozess – diese Tatsache macht Scrum so universell einsetzbar und ermöglicht Kombinationen mit vielen verschiedenen Prozessmodellen und anderen Frameworks.

Related Articles

Become Agile!
Start today!

Do you have any questions about agile transitions, would you like to train your employees, or be accompanied by us in a transition project? Send us a message!