Wie in Scrum Flow entsteht

Home » Blog » Scrum » Wie in Scrum Flow entsteht
  • Wie in Scrum Flow entsteht

Wie in Scrum Flow entsteht

In der letzten Woche schrieb ich darüber, durch welche Mechaniken Scrum Autonomie möglich macht. Heute geht es darum, wie Scrum Flow erzeugt und die zweite Säule für die Entstehung von Motivation realisiert. Außerdem zeige ich Euch einige Parallelen zwischen Scrum und Game-Design auf. Der Flow-Effekt nach Mihaly Csikszentmihalyi basiert auf vier wichtigen Grundsätzen, die gegeben sein müssen, damit er entstehen kann. Diese vier Elemente sind: Einklang von Herausforderung und Fähigkeiten (1), intrinsische Motivation (2), unmittelbares Feedback (3) und klare Ziele (4). Im Folgenden werde ich für Dich die Stellen im Scrum Guide herausarbeiten, die auf genau diese Elemente abzielen.

Auf das Flow-Erlebnis als solches und das Rahmenwerk Scrum werde ich nicht genauer eingehen. Für Dich heißt das, dass Du schon ziemlich viel 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 Thema Flow auseinanderzusetzen. Beides kannst Du hier tun:

Natürlich kannst Du auch gerne die Kommentarfunktion nutzen, wenn Dir noch was unklar ist. Ich freu mich über Feedback, Anregungen und Kritik!

Herausforderungen und Fähigkeiten im Einklang

Die bekannteste Voraussetzung für die Entstehung von Flow ist der Einklang von Herausforderungen und eigenen Fähigkeiten. Vereinfacht gesagt entsteht Flow also nur dann, wenn wir weder über- noch unterfordert sind. Im Scrum Guide gibt es zwei wichtige Stellen, an denen deutlich wird, wie in Scrum Flow möglich gemacht wird. Der Schlüssel liegt in der Komposition sogenannter cross-functional teams:

Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. (Scrum Guide, Seite 6)

und

Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment (Scrum Guide, Seite 7)

Es geht deshalb 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. Klassischerweise führt das Aufsplitten von Aufgaben in kleine, sehr einfach zu erledigende Teile dazu, dass die Anforderungen so gering sind, dass alle Beteiligten absolut unterfordert sind.

Die verschiedenen Kompetenzen innerhalb des Teams sorgen dafür, dass es den Flow-Kanal erreichen kann. Außerdem sorgen die verschiedenen Fähigkeiten und Kompetenzen in einem Scrum Team dafür, dass Synergie-Effekte entstehen können, die typisch für den sogenannten Team Flow sind. (Hierzu werde ich in einem späteren Artikel noch ausführlicher eingehen.) An dieser Stelle genügt es, festzuhalten, dass durch Scrum zwar Komplexität reduziert wird, aber eine Aufgabe (oder ein Sprintziel) als Ganzes nicht so stark zersplintert wird, damit sie eben immer noch ausreichend herausfordernd ist.

Intrinsische Motivation

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 Flow entstehen lassen kann, ist es außerdem 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 Kunden) legt und das Team einen Weg findet, ihn zu verwirklichen.

Dabei spielt das Event Sprint Planning eine zentrale Rolle. Während der Product Owner gemeinsam mit den Stakeholdern eine Idee davon entwickelt, was dieser Wert ist (beispielsweise durch Userstories oder ähnliches), entwickelt das gesamte Scrum Team während des Sprint Plannings gemeinsam einen Plan, wie dieser Wert realisiert werden kann.

The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team. (Scrum Guide, Seite 10)

Resultat dieser Planung ist das Sprintziel und außerdem ein Plan, wie dieses erreicht werden soll.

During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Ich glaube, diese Stelle im Scrum Guide ist eine der am wenigsten wahrgenommenen Stellen überhaupt. Der Kern eines Sprintziels liegt nicht im Was oder Wie des Sprints, sondern im Warum. (Gut möglich übrigens, dass in vielen Scrum Teams der Fokus sehr viel häufiger auf dem Was und Wie liegen.) Doch durch den Fokus auf das Warum eines Sprints verändern die Ziele, Pläne und einzelnen Schritte, Aufgaben oder Tasks, die während der Planung entwickelt werden, ihre Bedeutung. Es geht nicht mehr darum, Dinge zu tun, damit man ein (von irgendwem) gesetztes Ziel erreicht. Das Scrum Team verständigt sich gemeinsam auf einen Wert und verwirklicht diesen, indem es den Sprint umsetzt.

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 bestimmte Aufgaben und Tasks genauso wie früher. Aber der Grund, warum es die Aufgaben erledigt, ist ein vollkommen anderer.

Wenn Du mehr über dieses Thema wissen möchtest, empfehle ich Dir folgende Artikel:

Unmittelbares Feedback

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

Scrum baut auf die drei Säulen Transparency, Inspection und Adaption. Nahezu alles, was im Scrum Guide zu finden ist, legt den Fokus darauf, Dinge sichtbar zu machen – und zwar stets so schnell wie möglich. Wenn man Scrum aus dieser Perspektive betrachtet, erkennt man leicht, dass dem Daily Scrum eine besondere Rolle zukommt. Es ist eine regelmäßige Schleife für das Entwicklerteam, die ihm Feedback darüber gibt, wo es gerade steht.

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. (Scrum Guide, Seite 12)

Auch das Sprintbacklog sorgt für ein permanentes Feedback über den aktuellen Stand und darüber, was als nächstes zu tun ist.

The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. (Scrum Guide, Seite 16)

Es gibt natürlich noch eine ganze Menge mehr Stellen, an denen Feedback eine wichtige Rolle spielt. Aber zu Demonstrationszwecken mögen diese beiden Zitate genügen.

Außerdem wird an dieser Stelle auch klar, warum Scrum einen so starken Fokus auf Time-Boxing legt. (Im letzten Artikel über Scrum und Autonomie hatte ich ja gesagt, dass ich noch genauer erläutern werde, warum Scrum Freiheiten durch feste Zeiteinheiten bewusst beschränkt.) Der Grund für Time-Boxing ist eben der, dass es notwendig ist, um Transparenz zu erzeugen. Wenn Zeiträume schwammig und undefiniert sind, mal verlängert und mal verkürzt werden, dann geht das stets zu lasten 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. Velocity ist zum Beispiel keine Kennzahl, die dazu dienen soll, sich Maßnahmen zu überlegen, wie man diese steigern kann. Genauso wie Time-Boxing dient Velocity dazu, präzises Feedback zu erzeugen. Ein Sprintbacklog misst keine Performance, sondern zeigt den aktuellen Fortschritt darüber, was bereits geschafft wurde. Feedback-Events in Scrum (Daily Scrum, Sprint Review, Sprint Retro) sollen helfen, Dinge zu verbessern und dazuzulernen. Nur heißt es eben im Scrum Guide nicht lernen, sondern Adaption.

Mehr zum Unterschied zwischen Performance-Feedback und Progressive-Feedback findest Du in meinem Leitartikel über Key Learning Indicators of Progress.

Klare Ziele

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, reicht nicht aus. Die Transparenz muss auch in Richtung Zukunft vorhanden sein. Dazu nutzt Scrum das sogenannte Sprintbacklog:

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. (Scrum Guide, Seite 16)

Einer der wichtigsten Zwecke des Sprintbacklogs ist es also (möglichst) präzise festzuhalten, was genau (als nächstes) zu tun ist, damit das Ziel erreicht wird. Damit ist die Vorgehensweise bei Scrum den vielen Quests oder Aufgaben, die wir aus Computerspielen kennen, ganz ähnlich. Eine epische Mission wird aufgesplittet in viele kleine Aufgaben, die wir nacheinander abarbeiten können. Die kurzen Zeiträume eines Sprints und die Priorisierung des Productbacklogs 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 Äußerungen, die wir so oder ähnlich auch im Scrum Guide finden könn(t)en. Wie Quests aus Computerspielen kennt Scrum ebenfalls ein Element, das als concrete measure of proof dient: Die definition of done. Diese Definition dient einem Scrum Team dazu, genau erkennen zu können, wann es eine bestimmte Aufgabe erledigt hat und das Ziel erreicht wurde. Wenn ein Scrum Team sich Ziele setzt, aber zeitgleich nicht genau definiert, was zutreffen muss, damit als erreicht zählt, wird das Ziel unscharf.

Fazit

Abschließend können wir also festhalten, dass Scrum Flow in allen wichtigen Punkten (Einklang von Herausforderung und Fähigkeiten, intrinsische Motivation, unmittelbares Feedback und klare Ziele) möglich macht. 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“, eliminieren wir wichtige Funktionen dieses Rahmenwerkes!

Nächste Woche wenden wir uns dann der dritten Säule für Motivation – Gemeinschaft – zu und betrachten, welche Rolle sie in Scrum spielt. Bis dahin freu ich mich natürlich, wenn Du mir einen Kommentar hinterlässt und mit mir in Kontakt trittst!

Mehr Infos

Scrum & Agiles Projektmanagement

Du möchtest Scrum in Deinem Unternehmen oder Deiner Abteilung einführen, weißt aber nicht wie Du vorgehen sollst? Ich berate Dich gerne!

Mehr Infos
Von |2018-09-23T20:15:49+00:009. Juli 2018|Kategorien: Motivation, Scrum|Schlagworte: , , |0 Kommentare

Über den Autoren:

Ich glaube an eine Arbeitswelt, in der Menschen darauf brennen, am Montag endlich wieder zur Arbeit gehen zu dürfen. Deshalb helfe ich Menschen, Unternehmen und Organisationen, Arbeitsumgebungen so zu gestalten, dass sich Motivation und Engagement entfalten können.

Hinterlasse einen Kommentar

Newsletter

Diese Website benutzt Cookies und anderes Teufelswerk. Näheres dazu findest Du auf unserer Datenschutz-Seite. Verwalte hier Deine Einstellungen Einverstanden

Angebote von Drittanbietern

Hier kannst Du auswählen, welche Angebote von Drittanbietern Du während Deines Besuches auf dieser Webseite erlauben möchtest und welche nicht.