Warum Scrum kein Prozess ist

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.

Inhaltsverzeichnis

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 Framework, 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 Frameworks 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.

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.

Scrum iterations and their corresponding feedback loops
Abb. 1 - Scrum Zyklen und die zugehörigen Feedback-Schleifen

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.

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.

the relation between Scrum cycles and process steps of a development process
Abb. 2 - Zusammenhang zwischen Scrum und einzelnen Prozessschritten

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.

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.

Zurück zum Blog

Von der Theorie in die Praxis? Besuchen Sie agile Trainings bei AgileSkills!

1 von 4
  • Lead Time und Cycle Time in Kanban Systemen

    Lead Time und Cycle Time in Kanban Systemen

    Bei der Diskussion von Kanban-Systemen tauchen oft die Begriffe "Lead Time" und "Cycle Time" auf. Allerdings verwenden verschiedene Leute diese Begriffe unterschiedlich, und manchmal werden sie sogar synonym verwendet. Dieser...

    Lead Time und Cycle Time in Kanban Systemen

    Bei der Diskussion von Kanban-Systemen tauchen oft die Begriffe "Lead Time" und "Cycle Time" auf. Allerdings verwenden verschiedene Leute diese Begriffe unterschiedlich, und manchmal werden sie sogar synonym verwendet. Dieser...

  • Throughput und Delivery Rate in Kanban Systemen

    Throughput und Delivery Rate in Kanban Systemen

    Obwohl die Begriffe Throughput (Durchsatz) und Delivery Rate (Lieferfrequenz) oft synonym verwendet werden, gibt es feine Unterschiede zwischen ihnen. Dieser Artikel erklärt den genauen Unterschied zwischen Throughput und Delivery Rate...

    Throughput und Delivery Rate in Kanban Systemen

    Obwohl die Begriffe Throughput (Durchsatz) und Delivery Rate (Lieferfrequenz) oft synonym verwendet werden, gibt es feine Unterschiede zwischen ihnen. Dieser Artikel erklärt den genauen Unterschied zwischen Throughput und Delivery Rate...

  • Ein kurzer Leitfaden über Objectives und Key Results

    Ein kurzer Leitfaden über Objectives und Key Re...

    Objectives and Key Results (OKRs) ist ein Zielsetzungsframework, welches Organisationen hilft, klare, messbare Ziele zu setzen. Dieser Artikel zeigt die Definition von OKRs sowie gute Beispiele, die Ihnen helfen könnten,...

    Ein kurzer Leitfaden über Objectives und Key Re...

    Objectives and Key Results (OKRs) ist ein Zielsetzungsframework, welches Organisationen hilft, klare, messbare Ziele zu setzen. Dieser Artikel zeigt die Definition von OKRs sowie gute Beispiele, die Ihnen helfen könnten,...

  • A Beginners Guide to Kanban Metrics

    Ein kurzer Leitfaden über Kanban Metriken

    Kanban-Boards werden von Teams verwendet, um ihren Workflow und aktuellen Aufgaben abzubilden. Leider fehlt vielen Teams das Wissen und die Fähigkeit, die Leistung ihres Workflows zu bewerten. Wie schnell werden...

    Ein kurzer Leitfaden über Kanban Metriken

    Kanban-Boards werden von Teams verwendet, um ihren Workflow und aktuellen Aufgaben abzubilden. Leider fehlt vielen Teams das Wissen und die Fähigkeit, die Leistung ihres Workflows zu bewerten. Wie schnell werden...

1 von 4
Dr.-Ing. Stefan Döbrich

Fragen und Antworten

Sie haben offene Fragen zu Agilität?

Sie haben noch offene Fragen zum Artikel, zu agilen Methoden, oder Probleme bei der Umsetzung von Agilität in der Praxis?

Schreiben Sie mir, und wir vereinbaren ein Erstgespräch! Wir machen uns gemeinsam auf den Weg. Versprochen!

Jetzt Kontakt Aufnehmen