Wie Scrum Flow erzeugt

In diesem Artikel zeige ich Dir, durch welche Mechanismen Scrum Flow erzeugt. Außerdem machen wir einen kleinen Ausflug in die Welt des Game-Designs, um einige Parallelen zu Scrum aufzuzeigen. Das Flow-Erlebnis nach Mihály Csíkszentmihályi basiert auf vier wichtigen Grundsätzen, die gegeben sein müssen, damit er entstehen kann. Diese vier Elemente sind:

Im Folgenden werde ich für Dich die Stellen im Scrum Guide aufzeigen, die auf genau diese Elemente abzielen.

Auf das Flow-Erlebnis selbst und das Framework Scrum als solches werde ich hier jedoch nicht detailliert eingehen. Für Dich heißt das, dass Du schon ein wenig Vorwissen zu beiden Themen mitbringen solltest. Falls das nicht der Fall ist, empfehle ich Dir zum einen, zuerst den Scrum Guide zu lesen und Dich zum anderen ein wenig ausführlicher mit dem Flow-Erleben auseinanderzusetzen.

Die bekannteste Voraussetzung für die Entstehung von Flow ist der Einklang von Herausforderungen der Aufgabe & den eigenen Fähigkeiten. Vereinfacht gesagt entsteht Flow also nur dann, wenn wir weder über- noch unterfordert sind. Im Scrum Guide gibt es dazu eine Stelle, an der besonders deutlich wird, wie Scrum diese Bedingung für Flow ermöglicht. Der Schlüssel liegt in der Zusammenstellung interdisziplinärer Teams:

Scrum Teams sind interdisziplinär, d.h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen.

Es geht hier jedoch gar nicht so sehr um die Abgrenzung des Scrum Teams nach außen, sondern vielmehr darum, dass das Team als Ganzes der Aufgabe gewachsen ist. Wenn Kompetenzen zur Erledigung einer Aufgabe sich nicht im Team wiederfinden und deshalb “ausgelagert” werden müssen, dann wird dieser Teil der Aufgabe zwar vielleicht gut erledigt, aber Flow entsteht dadurch eben nicht.

Die verschiedenen Kompetenzen innerhalb des Teams sorgen dafür, dass es gemeinsam den Flow-Kanal erreichen kann. Außerdem ermöglichen die individuellen Fähigkeiten und Kompetenzen, dass Synergie-Effekte innerhalb des Teams entstehen können, die typisch für den sogenannten Team Flow sind.

Der Einklang von Herausforderungen und Fähigkeiten ist zwar der bekannteste Aspekt für die Entstehung von Flow, aber bei Weitem nicht der einzige. Damit Scrum die Entstehung von Flow begünstigt, ist es darüber hinaus wichtig, dass alle Mitglieder eines Teams intrinsisch motiviert sind. Scrum erzeugt intrinsische Motivation dadurch, dass es den Fokus auf den Wert des Produktes (für den Nutzer) legt und das Team einen Weg findet, ihn zu verwirklichen.

Dabei spielt beispielsweise das Sprint Planning eine zentrale Rolle. Während der Product Owner eine Idee davon entwickelt, was der Wert des Produktes ist, entwickelt das gesamte Scrum Team während des Sprint Plannings einen gemeinsamen Plan, wie dieser Wert realisiert werden kann. Im Scrum Guide heißt es dazu:

Das gesamte Scrum Team arbeitet dann zusammen, um ein Sprintziel zu definieren, das verdeutlicht, warum der Sprint für die Stakeholder wertvoll ist.

Ich glaube, diese Stelle im Scrum Guide ist eine der am wenigsten wahrgenommenen Stellen überhaupt.

Auf den ersten Blick klingt das vielleicht wie ein Taschenspielertrick, aber durch dieses Vorgehen verändert das, was ein Scrum Team macht, seine Bedeutung. Eventuell bearbeitet es sogar die gleichen Aufgaben und Tasks wie früher. Aber der Grund, warum es die Aufgaben erledigt, ist ein vollkommen anderer. Wenn Ziele gemeinsam im Team so gesetzt werden, dass sie das gesamte Team “in Schwingung versetzen”, dann entstehen resonante Ziele, die intrinsische Motivation ermöglichen.

Der dritte Punkt, der notwendig ist, um Flow zu erleben bzw. möglich zu machen, ist unmittelbares Feedback. Um Flow zu erleben, müssen wir immer genau wissen, wo wir gerade stehen und was unsere nächsten Schritte sind. Ohne Feedback kein Flow.

Das Scrum Framework basiert auf den drei Säulen Transparenz, Überprüfung und Anpassung. Nahezu alles, was Du im Scrum Guide findest, legt den Fokus darauf, Dinge transparent zu machen. Und zwar stets so schnell und früh wie möglich.

Das gilt natürlich ganz besonders für die drei Scrum Artefakte.

Wenn wir Scrum aus dieser Perspektive betrachten, erkennen wir leicht, dass auch dem Daily Scrum eine besondere Rolle zukommt. Es ist eine regelmäßige Schleife für die Entwickler des Scrum Teams, die ihnen Feedback darüber gibt, wo sie gerade stehen.

Der Zweck des Daily Scrums besteht darin, den Fortschritt in Richtung des Sprintziels zu überprüfen und das Sprint Backlog bei Bedarf anzupassen, um die bevorstehende geplante Arbeit zu justieren.

Auch das Sprint Backlog, das meist noch mit einem Burn-Down-Chart ergänzt wird, sorgt für ein permanentes Feedback und Transparenz über den aktuellen Stand und was als Nächstes zu tun ist.

Außerdem wird an dieser Stelle auch klar, warum Scrum einen so starken Fokus auf Timeboxing legt. Der Grund für Timeboxen ist eben der, dass sie notwendig sind, um Transparenz zu erzeugen. Wenn Zeiträume schwammig und undefiniert sind, mal verlängert oder mal verkürzt werden, dann geht das stets zulasten der Transparenz. Ergebnisse und erreichte Ziele sind dann kein präzises Feedback mehr darüber, wo man gerade steht.

Spannend in diesem Zusammenhang ist übrigens auch, dass Scrum den Fokus auf progressives Feedback legt und nicht auf Performance-Feedback. Die Sprint Velocity ist zum Beispiel keine Kennzahl, die dazu dienen soll, sich Maßnahmen zu überlegen, wie man diese steigern kann. Genauso wie Timeboxen dient die Velocity dazu, präzises Feedback zu erzeugen. Ein Sprint Backlog misst keine Performance, sondern zeigt den aktuellen Fortschritt. Feedback-Events in Scrum wie das Daily Scrum, Sprint Review oder die Sprint Retro sollen einem Team dabei helfen, Dinge zu verbessern und hinzuzulernen.

Nur heißt es eben im Scrum Guide nicht Lernen, sondern Überprüfung & Anpassung.

Die vierte und letzte Bedingung für Flow sind klare Ziele. Präzises Feedback über das, was in der Vergangenheit geschah und wie der aktuelle Stand ist, allein nicht aus. Die Transparenz muss auch in Richtung Zukunft vorhanden sein. Dazu nutzt Scrum das sogenannte Sprint Backlog:

Das Sprint Backlog besteht aus dem Sprintziel (Warum), den für den Sprint ausgewählten Product Backlog Items (Was) sowie einem umsetzbaren Plan für die Lieferung des Inkrements (Wie).

Einer der wichtigsten Zwecke des Sprint Backlogs ist es also präzise zu visualisieren, was genau als Nächstes zu tun ist. Damit ist die Vorgehensweise in Scrum, um Flow zu erzeugen, den Quests oder Missionen in Computerspielen sehr ähnlich. Eine epische Mission besteht aus vielen kleinen Teil-Aufgaben, die wir nacheinander “abarbeiten”. Die kurzen Zeiträume eines Sprints und die Priorisierung des Product Backlogs gewährleisten gleichzeitig, dass wir in unserer Mission nicht vom Weg abkommen und in die falsche Richtung gehen.

Und eine weitere Parallele zum Game-Design taucht an dieser Stelle auf: In ihrem Buch Reality is broken schreibt Jane McGonigal folgenden Satz über Quest-Beschreibungen:

[…] lists a clear goal, and why it matters, followed by actionable steps, where to go, step-by-step instructions for what to do when you got there, and a concrete measure of proof you’re expected to gather to demonstrate your success.

Das sind alles Äußerungen, die wir so oder ähnlich auch im Scrum Guide finden könn(t)en. Wie bei Quests in Computerspielen kennt auch Scrum ein Element, das als concrete measure of proof dient: Die Definition of Done. Denn sie dient einem Scrum Team dazu, genau erkennen zu können, wann es eine bestimmte Aufgabe erledigt hat und das Sprintziel erreicht wurde. Wenn ein Scrum Team sich Ziele setzt, aber zeitgleich nicht genau definiert, was das Ergebnis sein soll, wird das Ziel unscharf.

Abschließend können wir also festhalten, dass Scrum Flow in allen vier wichtigen Punkten ermöglicht. Ich hoffe, ich habe Dir ein wenig die Augen geöffnet, warum es wichtig ist, die Grundsätze im Scrum Guide einzuhalten. Denn wenn wir damit beginnen, Scrum “ans Unternehmen anzupassen”, besteht immer die Gefahr, dabei wichtige Funktionen des agilen Frameworkes eliminieren!