.st0{fill:#FFFFFF;}

Scrum Toolbox

Das Flow Board (5 Schritte für schnelleres Scrum)

 April 17, 2021

von  Sebastian

Schnelleres Scrum ist im Grunde ein Mythos - denn Schnelligkeit ist nicht das primäre Ziel von Scrum. Doch warum nicht etwas mit Scrum verbinden, was die Geschwindigkeit steigert und gute Reflexionsmöglichkeiten bietet? Ich zeige dir ein einfaches Tool, das Flow Board, mit dem du mehr aus deinem Scrum Team holen kannst. 

Schnelleres Scrum?

Viele sehen es als Mythos: Wenn Scrum angewendet wird, geht es in erster Linie nicht um Schnelligkeit. Auch das wird von vielen Seiten diskutiert und unterschiedlich gesehen. Es geht in erster Linie aber um den Kundenmehrwert und nicht schnelleres Scrum. 

Ich möchte diesen Punkt auch nicht stressen, aber ich denke es ist einleuchtend, wenn ich das richtige, richtig tue und dabei schnell bin, dann ist das eine kraftvolle Kombination. Und genau diese Kombination für schnelleres Scrum werden wir uns ganz genau ansehen.

Was ist das Flow Board?

Vor schon ewig langer Zeit, habe ich gemeinsam mit Wolfram Müller mal ein Projekt durchführen können, in dem das Flow Board Gegenstand war. Wolfram und Hannah Nowak haben dann einen Artikel dazu im Projektmagazin veröffentlicht, die Basis legte das Buch von Wolfram und Steve Tendon "Hyper-Productive Knowledge Work Performance: The Tameflow Approach and Its Application to Scrum and Kanban (The Tameflow Hyper-productivity)".

Wer Wolfram und Steve kennt weiß, bei beiden geht nichts ohne die Theory of Constraints. Und so ist es auch nicht verwunderlich, dass es hier um genau dieses Thema geht. Wir verbinden Scrum mit der Theory of Constraints. Darum gehts:

  • Das Flow Board ist ein Kanban Board, welches mit fünf Spalten arbeitet.
  • Es setzt ein hartes Single-Piece-Flow Konzept um - es wird nur eine Aufgabe zu einer Zeit bearbeitet.
  • Blocker werden besonders betrachtet und proaktiv einer Lösung zugeführt.
  • Wer mit dem Prozess arbeitet und diesen dann konkret umsetzt hat perfekte Möglichkeiten zur Reflexion.
Das Flow Board

Ich habe mit dem Flow Board nun auch unterschiedliche Ergebnisse in Projekten gemacht und beschreibe folglich hier meine Anwendung und Sichtweise.

Ziel des Flowboards

Schauen wir uns zunächst einmal die Ziele des Flow Boards an. Diese solltest du natürlich im Kopf behalten, wenn du über einen Einsatz nachdenkst, denn die Ziele sollten natürlich mit deinen übereinstimmen.

  • Schnellere Erledigung von den Aufgaben, an denen ein Team oder eine Gruppe arbeitet.
  • Transparenz über die Arbeit im System
  • Fokus auf die wichtigsten Dinge im System

Was spricht dafür, was dageben?

Pros

  • Super einfacher Einstieg möglich, wenig Vorkenntnisse nötig
  • Wenig Zeit für das Aufsetzen, schneller Start möglich
  • Erzeugt schnell Vertrauen durch regelmäßige Lieferungen

Cons

  • Tool und Abhängigkeitsfragen löst das Board selbst erstmal nicht
  • Größere Reports oder Übersichten über Themen liefert das Board nicht
  • Fokus liegt zunächst nur auf der Effizienz eines Teams

Das Flow Board für schnelleres Scrum erstellen

Im Folgenden werde ich nun mit dir die einzelnen Schritte Stück für Stück durchgehen, damit du weißt, wie du dein Flow Board selbst erstellen und anwenden kannst.

Rahmenbedingungen klären

Das Schöne ist, das Flow Board für schnelleres Scrum kann sowohl mit analog wie auch praktisch jedem digitalen Tool umgehen. Ich beschreibe hier einen sehr einfachen Fall und zeige dir im Anschluss noch ein paar Ausblicke und Erfahrungswerte. Es gibt auch ein paar Themen, die ich bewusst ausklammere. Damit bleiben wir wie gesagt sehr einfach und fokussiert.

Schritt 1: Das Board aufsetzen

Zu Beginn steht immer ein Aufsetzen des Flow Boards. Dazu nutzt du typischerweise einfach einen Workshop mit dem Team. Es geht darum, gemeinsam ein solches Board zu erstellen. Daraus folgt in der Regel eine höhere Akzeptanz, als wenn du so etwas den Teams vor gibst.

Ein leeres Flow Board

Wer sich mit Scrum auskennt, der wird natürlich aufschreien: "Das Review gehört da nicht rein, das ist eine Dysfunktion". Dem gebe ich prinzipiell recht, aber warte noch etwas ab. Dieses Flow Board kommt von einem universellen Ansatz und das kannst du praktisch überall verwenden. In Scrum wissen wir, dass solche extra Schritte wie Review (oder auch noch weitere) in einem Sprint Backlog in der Regel immer zu mehr Kommunikation, größerem tailoristischen Denken und starken Rollenausprägungen führen. Stelle diesen Gedanken trotzdem bitte etwas hinten an.

Jeder, der schon mal ein Scrum Board / Sprint Backlog gesehen hat damit gearbeitet hat oder gar eines aufgesetzt hat, kennt genau so Board. Ja, im Grunde auch nichts anderes als ein Kanban Board. Und das passt grundsätzlich auch erstmal so.

Den Workshop für das Flow Board für schnelleres Scrum kannst du übrigens auch so durchführen, wie ich es am Ende beschrieben haben. Du kannst nämlich zwei Ansätze ausprobieren

Erarbeitung des Boards durch das Team

Dieser Ansatz dauert etwas länger, hat aber den Vorteil, dass sich das Team anhand einer Fragestellung den Aufbau des Boards selbst überlegt und diesen herleitet, ohne zu Beginn zu wissen, was eigentlich auf so einem Board existiert.

Vorgabe des Boards und Diskussion darüber im Team

Wenn du diesen Ansatz wählst, dann hast du das Board schon vorgegeben, es ist damit fertig und die wirst die Teilnehmer dann direkt bitte mit oder an diesem Board bitte das Vorgehen zu reflektieren und Fragen zu stellen.

Schritt 2: Vorhandene Arbeit aufnehmen

Ein guter und sehr wichtiger Aspekt des Flow Boards ist es, dass du dort beginnen kannst, wo du aktuell stehst. Konkret: anstatt erst viele Events, Artefakte und Co zu diskutieren, fokussiert sich das Team auf die Arbeit, die aktuell im System ist und stellt diese auf dem Board dar. Das ist grundsätzlich immer einfach und verständlich, die wenigsten Widerstände entstehen bei so einer Art der Aufnahme. Sollte jemand an dieser Stelle bereits meckern, dass das "zu lange dauern würde", prüfe noch mal, ob die Ziele verstanden sind.

Arbeit am Flow Board aufnehmen

Die folgenden Schritte helfen dir, die aktuelle Arbeit aufzunehmen:

  1. 1
    Lass alle Mitglieder aktuelle Aufgaben aufschreiben, die sie im Moment in der Bearbeitung haben. Lasse sie auch unterscheiden, ob die Arbeit noch in Bearbeitung ist oder im Review.
  2. 2
    Fasse größere Blöcke an Arbeit zusammen. So etwas können zum Beispiel User Stories sein, eine Art Container wie "Tagesgeschäft" oder auch Projekte.  
  3. 3
    Meistens gibt es schon Planungen für die nächste Zeit, auch diese kannst du und das Team natürlich aufnehmen. Lässt sich das zuordnen prima, wenn nicht arbeite da auch erstmal mit einem "Sammler"
  4. 4
    Die weiteren Bezeichnungen an dem Flow Board darfst du hier noch ignorieren. Dabei geht es erstmal hier nur darum, die Arbeit sichtbar zu machen. WIP, Mitglieder und Datum werden noch frei gelassen.

Um die aktuelle Arbeit aufzunehmen, lässt du die Teilnehmer die Arbeit auf Zettel oder ins Tool schreiben. Jetzt gehen wir mal einen Schritt von Scrum zurück und betrachten nur das Flow Board. Dann geht es jetzt gar nicht um die besten User Stories oder besonders gute Tasks. Nein, es geht grundsätzlich die Arbeit sichtbar zu machen.

Auch wer jetzt zurückschreckt und sagt, ich habe viel zu viel Arbeit, das klappt nie, der nutzt erstmal die Arbeit auf dem Flow Board, an der er unmittelbar arbeitet. Einen Tag schafft jeder und meistens sogar spielend noch etwas mehr.

Schritt 3: Blockierte Arbeit finden

Wir wollen eine gewisse Transparenz auf dem Board. Und die ist gnadenlos 🙂 Und wer Arbeit kennt, der kennt natürlich auch den Fall, dass man an der einen oder anderen Aufgabe einfach hängt und nicht weiterkommt.

Flow Board Blocker

Das ist nicht schlimm und auch das Flow Board nimmt diese Hürde auf dem Weg zum schnelleren Scrum mit Leichtigkeit. Wir machen dabei noch eine kleine Unterscheidung. Wir nutzen blaue und rote Blocker, dabei ist blau

Blocker, die das Team selbst lösen kann

Alle Blocker, die ein Team selbst lösen kann, werden mit einem blauen Punkt markiert.

Blocker, die das Team nicht selbst lösen kann

Alle Blocker, die ein Team nicht selbst lösen kann, werden mit einem roten Punkt markiert.

In dem Flow Board bekommen die Aufgaben, die blockieren und durch das Team lösbar sind sogenannte "De-Blocker-Aufgaben". Diese zählen natürlich auch zum WIP und zeigen an, dass bestimmte Aufgaben getan werden müssen, um diesen Blocker zu lösen. Kein Drama, das Team kann das selbstorganisiert lösen.

Anders sieht es aus, wenn wir auf dem Flow Board Aufgaben haben, die eben nicht durch das Team gelöst werden können. Diese "blocken" natürlich auch, zählen auch zum WIP, bekommen aber keine "De-Blocker-Aufgaben". Solche Aufgaben müssen durch z.B. den Scrum Master oder dem Product Owner gelöst bzw adressiert werden.

Schritt 4: Check vom Flow Board und WIP Infos

Jetzt kann man noch die Anzahl der Teammitglieder eintragen und zusätzlich das WIP und dann fehlt dem Flow Board nicht mehr viel. Ein Datum hilft immer, um die Aktualität und den Tag auch wirklich zu erkennen und zu fokussieren. Ich nutze dieses bei einem täglichen Blick allerdings nicht - es hilft je nach Umfeld aber trotzdem.

Schritt 5: Regeln und Prozess vom Flow Board festlegen

Wenn du das Flow Board für schnelleres Scrum nutzen möchtest, dann hast du natürlich schon einen prima Rahmen: Scrum! Hast du das nicht, dann ist jeder der richtige Zeitpunkt dir zu überlegen, was du für einen Prozess und Regeln brauchst.

Regel

Scrum

Kein Scrum

Nur fertige Arbeit ins System

Wir durch das Backlog Refinement sichergestellt

Muss Projektleiter / Teamleiter sicherstellen

Zerteilen von Aufgaben in kleinere

Wird in der Sprint Planung 2 durch das Team vorgenommen

Enter your text here...

Verantwortlichkeit der Aufgaben

Legt das Team gemeinschaftlich fest (Sprint Planung 2)

Bei der Bewegung in die Bearbeitung wird der Name festgehalten

One-Piece-Flow sicherstellen

Kontrolle im Flow Board bzw. Sprint Backlog

Kontrolle im Flow Board

WIP Limit zu jeder Zeit sicherstellen

Kontrolle im Flow Board bzw. Sprint Backlog

Kontrolle im Flow Board

Keine Termine an den Karten selbst

Ist durch die Priorisierung im Sprint Backlog vorgegeben

Projektleiter unterstützt, dass dieses nur durch Priorität sichergestellt wird

Größe der Aufgaben

Größe sollte einen Tag nicht übersteigen

Größe sollte einen Tag nicht übersteigen

Steuerung

Scrum wie gehabt, nur Anpassungen am Board und ggf. nicht Fokus auf drei Fragen

Stand-Up mit 30-60 Sekunden pro Teammitglied mit Abstimmung wie Aufgaben schnell abgeschlossen werden können und ggf. Bericht rote Blocker

Exkurs "Herleitung guter Arbeitsbedingungen"

Es gibt tatsächlichen einen generellen Ansatz der oft sehr gut funktioniert. Und diesen möchte ich dir hier im Detail einmal genau vorstellen. Dazu gibt es im Grunde nur eine zentrale Fragestellung:

Was brauchst du an Rahmenbedingungen um gute Arbeit zu liefern? 

Je nach Team solltest du etwas darauf achten, dass es nicht so ist, dass dort versucht wird das System zu challengen oder Trivialitäten genannt werden. 

Wenn wir uns ehrlich im Team überlegen, was wir wollen, um gut Arbeit erledigen können, dann kommen wir oft auf die gleichen, wichtigen Dinge. Wenn du mit der obigen Frage startest und dann die Teammitglieder einmal erkunden lässt, dann kommt ihr oft auch gleiche oder ähnliche Gedanken. Einige Beispiele:

  • Ich möchte störungsfrei an meinen Aufgaben arbeiten können
  • Ich möchte nicht an zu vielen Aufgaben gleichzeitig arbeiten
  • Ich brauche Austausch mit Kollegen
  • Ich möchte von meiner Führungskraft unterstützt werden
  • ...

Es gehört auch immer etwas Mut dazu, sich als Moderator / Scrum Master darauf einzulassen, aber ich kann dir versichern, du kannst meistens die Dinge immer und immer wieder auf das Flow Board mappen. Und das macht auch richtig Spaß.  Ich nutze dann zu Beginn das Flow Board und jeden "Wunsch" verarbeite ich dann gleich so, dass er auf das Board passt.

Ein leeres Flow Board

Wenn jemand also über störungsfreie Arbeit spricht, kann ich mit One-Piece-Flow argumentieren und platziere dann die Karte / den Wunsch auf dem Board. Und zwar immer in die Nähe von der Stelle, wo das auf dem Board erfolgt. Wenn jemand Multitasking sagt, dann hänge ich so etwas zum Beispiel zum WIP.

Sei da wirklich gerne mutig und glaube mir, die meisten Themen, die durch die Teilnehmer genannt werden, kannst du mappen.

Exkurs "Challange des Flow Boards"

Wenn ich nicht die Variante bei der Herleitung des Flow Boards nutze, bei dem das Team sich das Board herleitet, dann verwende ich einfach eine Präsentation des Flows Boards, erkläre die Schritte und gebe dann die Möglichkeit, das System richtig zu hinterfragen und alle Dinge auf den Tisch bzw. auf die Klebezettel zu bringen.

In einem zweiten Schritt, nachdem alle ihre Ideen ausgespeichert haben (10 Minuten ist oft eine gute Zeit), lasse ich diese Punkte gerne noch in zwei Kategorien aufteilen:

  • Welche dieser Punkte betrifft das eben vorgestellte Flow Board
  • Welche dieser Punkte betreffen eure (sowie existierenden) Arbeitsweisen, Probleme und ähnliches

Nach einer kurzen Konsolidierung solltest du dann einen Überblick darüber haben, dass die meisten Punkte eben genau nicht ein Problem des Flow Boards darstellen. Im Zweifelsfall lass natürlich dem Team die Entscheidung, hier darf man als Moderator aber schon mal etwas energischer nachfragen und etwas bohren.

Aus der Erfahrung: hier passiert recht wenig und es kommt kaum etwas "überraschendes" mit dem du dich als Moderator herumschlagen musst.

Ausblicke und Erfahrungswerte

Zu Beginn steht immer ein Aufsetzen des Flow Boards. Dazu nutzt du typischerweise einfach einen Workshop mit dem Team. 

  • Aufsetzen gemeinsam mit dem Team ist besser, als ohne das Team.
  • Es ist häufiger sehr viel einfacher mit so einem Board zu starten, und dann zu reflektieren, was dir noch zu Scrum fehlt - als andersherum. Um Widerstände abzubauen eignet sich das ausgesprochen gut.
  • Auch ein guter Startpunkt, wenn "Scrum" bereits verbrannt ist oder aber eine Einführung oder einen Start als schwierig erweist.
  • Wenn du digital starten möchtest, versuche am besten mit solchen Tools wie Miro, Mural oder Conceptboard zu beginnen und eine analoge Variante nachstellst. Zu Beginn ist das deutlich schneller als ein finales Tools zu suchen (Jira, Trello, Redmine, ...)

Sebastian

Ein paar Worte über den Autor

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt. Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben. Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen. Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

Sebastian Schneider CSP-PO
Sebastian Schneider CSP
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Sei auch mit dabei: Der Newsletter zu Scrum aus Augsburg.

>