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:
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.
Was spricht dafür, was dageben?
Pros
Cons
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.
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.
Die folgenden Schritte helfen dir, die aktuelle Arbeit aufzunehmen:
- 1Lass 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.
- 2Fasse 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.
- 3Meistens 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"
- 4Die 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.
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:
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.
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:
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.
