Direkt zum Hauptbereich

Ubongo Flow Game Catering Simulation - Erfahrungsbericht

"Vernissage, mittel, 21 Personen, gerne Sekt" oder:

Wie versorge ich im Team als virtueller Caterer möglichst viele (virtuelle) hungrige Menschen in möglichst kurzer Zeit, und wie fühlen sich die einzenen Runden an?

 

Kürzlich hatte ich das Glück, endlich einmal als Teilnehmerin beim legendären "Ubongo Flow Game" dabeizusein. Meine Erfahrungen möchte ich gerne hier teilen.

Die Veranstalter Holger Lotter und Jan Fischbach hatten in Trello ein einfaches, aber ansprechendes Board eingerichtet, um in "Team ROT" und "Team BLAU" das Spiel spielen zu lassen. (Je nach Anzahl der angemeldeten Gäste kann zusätzlich mit einem dritten farblichen Team gespielt werden.) Nach einer lockeren Einführungsrunde mt allen Gästen ging es auch gleich los.

Kaminabend, mittlerer Auftrag, 13 Personen, keine Nüsse

Auf dem Board eingeloggt, fanden wir in der ganz linken Spalte viele Catering-Aufträge vor, z. B. "Kaminabend", "Hochzeit", "Kommunion" oder "Junggesellenabschied". Unterschiedliche Personenanzahlen sollten mit unterschiedlichem Catering-Angebot versorgt werden. Ein Beispiel für einen einfachen Catering-Auftrag: eine Art von Snack, ein alkoholfreies Getränk, das war's. Ein mittlerer Auftrag umfasste Fingerfood und sowohl alkoholfreie als auch alkoholhaltige Getränke. Die Königsvariante, der große Auftrag: Snack, Fingerfood, alkoholfreie und alkoholhaltige Getränke. Damit aber nicht genug, es wurden auch noch Sonderwünsche eingestreut ("kein Gorgonzola"...nein, das ist erfunden :-), "vegan",...), die es ebenfalls zu berücksichtigen galt.

Die Rollen und ihre Aufgaben

Der Einfachheit halber benutze ich hier immer die männliche Form der Rolle, gemeint sind aber immer beide Geschlechter, und so haben wir das Spiel natürlich auch gespielt. Verfügbare Rollen: Auftraggeber (Aufträge nach Vorgabe raussuchen, bei uns: 2 Aufträge für 8 Personen, zwei für 13 Personen und zwei für 21 Personen, keine Vorgaben für die jeweilige Größe des Catering-Auftrags), Analyst (passende Vorlage erstellen, d. h. in die Karte eintragen, welche Produkte zu liefern sind, etwa "Fingerfood, alkoholfreies Getränk, alkoholhaltiges Getränk" bei einem mittleren Auftrag), Lieferant (diese arme Person musste die Vorlage mit Leben füllen, d. h. ausfüllen, welche konkreten Speisen und Getränke für den vorliegenden Aufrag genommen werden sollten und dabei z. B. auch darauf achten, wie sich z. B. Snack [Tütenfraß wie Gummibärchen oder Flips] von Fingerfood unterscheidet), Preisermittler (für jede Kategorie wurden Preise vorgegeben, etwa der Snack für 1€, und bei der Preisermittlung mussten die Preise für die einzelnen Artikel des Auftrags zusammengerechnet und mit der Anzahl der zu beliefernden Personen multipliziert werden, um den Gesamtwert des Auftrags zu erhalten) und schließlich Tester (dies war die Qualitätssicherung, d. h. alles im Auftrag wurde noch einmal auf Richtigkeit geprüft). Sollten mehr Personen pro Team vorhanden sein, kann auch noch ein Manager installiert werden, der sein Team im Wesentlichen durch klassische Managersprüche ("Warum geht das nicht schneller?") unterhält, aber auch auf Regeleinhaltung achtet, einen Beobachter, der sein Augenmerk auf Auffälligkeiten richtet und dessen Eindruck später mit den Eindrücken der Spieler:innen abgemischt wird, sowie einen Zeitmesser, der die Zeit für die jeweiligen Runden nimmt.

Silos und Losgrößen à la Ford

In der ersten Runde wurden Personen aus den Teams diesen Rollen klassisch-bestimmend durch die Spielleitung zugeordnet. Diese Runde wird auch "Wasserfall" genannt, man kann sich denken, warum. In die jeweilige Arbeitsspalte im Trello-Board wurde der Name der zugeordneten Person eingetragen. Wir hatten 6 Minuten Zeit, um eine Mindestanzahl von Personen (die ich vergessen habe) mit Essen zu beliefern. Dies natürlich als kleines Schmankerl, damit wir es uns nicht zu bequem machten. Jede der Rollen durfte ihre Arbeit aber nur in einem einzigen fertigen Block weitergeben, d. h. alle fertiggestellten Arbeitspakete gleichzeitig in die nächste Spalte auf dem Trello-Board schieben. Ich hatte Glück, denn ich wurde als Auftraggeber auserkoren. Das ist die Person, die ganz vorne links arbeitet und das System mit Arbeit vollpumpt. Ich suchte also alle Catering-Auftragskarten mit den angegebenen Personenanzahlen zusammen, schob sie in meiner Spalte nach ganz oben und untereinander und dann einzeln in die nächste Spalte, wo schon der Vorlagenersteller/Analyst wartete - fertig. Danach konnte ich gemütlich abgammeln und zugucken, wie die anderen weiterschwitzten. Am Schluss wurden wir nach unseren Eindrücken gefragt, und ich meldete großzügig zurück, dass die Arbeitslast der verschiedenen Rollen ja dezent unausgewogen sei. Die heftigste Rolle war nach meinem Dafürhalten einmal die des Lieferanten, der sich überlegen musste, welche konkreten Speisen und Getränke zu der Auftragsvorlage passten, und zum zweiten der Preisermittler, der möglichst blitzschnell den Auftragswert berechnen muss. (Ja, man muss nur mit 1, 2, 3 und 4 als Operanden arbeiten und noch eine kleine Multiplikation durchführen, aber unter Zeitdruck und mit gefüllter Arbeitsspalte sieht das dann schon anders aus - erst recht für Leute, die schlecht im Kopfrechnen sind...)

Arbeitsfluss und WIP-Limit

In der zweiten Runde (das "Kanban"-Äquivalent) gab es eine kleine Modifikation: Wir durften unsere Arbeitspakete auch bröckchenweise in die nächste Spalte schieben (also z. B. jede fertige Vorlage sofort zum Lieferanten durchschieben), allerdings gab es eine kleine Einschränkung: In jeder Folgespalte durften maximal zwei in Arbeit befindliche "Werkstücke"/Aufträge vorhanden sein. Waren in der Folgespalte also bereits zwei items, musste man warten, bis man seine eigene Arbeit weiterschieben durfte. Wenn Teammitglieder sahen, dass es in irgendeiner Arbeitsspalte einen Stau gab, durften sie dieses Mal auch helfend eingreifen. Leicht gesagt, aber schwer getan, denn natürlich stürzten sich auch mal zwei oder mehr Personen auf die gleichen Aufträge, um deren Abarbeitung zu beschleunigen ("Ach, da bist du jetzt schon drin..."). Das passierte eigentlich ständig, bis uns ein Trick verraten wurde, wie man bereits von außen erkennen kann (ohne einen Auftrag zu öffnen), dass jemand anderes den Auftrag bereits bearbeitet. In dieser Runde war ich der Analyst, der die Vorlagen für die Belieferung erstellte. Über meine Idee eines Textblocks in der Zwischenablage, der mir die Arbeit erleichterte, war ich so begeistert, dass ich das Limit von nur zwei erlaubten Arbeitspaketen in der Folgespalte vergaß und die Nachbarin zu meiner Rechten (auf dem Trello-Board) völlig zumüllte - zack, copy und paste, anpassen, weiter, geht doch prima. Nachdem der Abpriff für diese Runde kam, erinnerte Holger auf trockene Art nochmals an das Limit, was mich jäh aus meinem Rausch holte, und meine überschüssigen Auftragskarten wurden unerbittlich aus der Lieferantenspalte wieder zurückgeschoben. (Ja, andere kommentierten das als "streng", aber wat mutt dat mutt.)

Auch hier erstmal Stille in der Retrospektive...

Nach jeder Runde wurde von der Spielleitung geguckt, wieviele Menschen jedes Team bereits mit Essen versorgt hatte, sprich, wieviele Aufträge für je wieviele Personen komplett abgearbeitet waren. Zwischendurch, etwa zu jeder Hälfte der jeweiligen Runde, konnten sich die Teams übrigens für (sehr) kurze Zeit in einen eigenen Breakout-Raum zurückziehen, um sich zu organisieren, d. h. sich auszutauschen und z. B. Verbesserungen für die eigene Team-Arbeit zu ermitteln. Ja, da dämmert dumpf die Ahnung herauf, dass es sich dabei um eine Retrospektive handeln könnte, und obwohl wir uns in unseren Teams gerne über das Erlebte austauschen wollten, das merkte man allen an, war es wie im echten Leben: Erstmal Stille, und jede/r guckt, ob jemand anderes eine bessere Idee als die eigene hat, da war dann meist gefühlt die Hälfte der gegebenen Zeit schon wieder herum...

Das selbstorganisierte, crossfunktionale Team - oder?

Die absolute Krönung war dann aber die dritte Runde. Hier gab es nämlich plötzlich auch keine festgelegten Rollen mehr, die zog man uns unter dem Hintern weg, und die einzige Einschränkung bestand darin, dass ein Auftrag immer von jemand anderem als den Bearbeitern davor getestet werden musste, man sich also nicht selbst testen durfte. Wie wir uns hierzu organisieren sollten - tja, das wurde uns überlassen. Hilfloses Geblöke im Stimmengewirr der zwei Teams, ich selbst hatte dazu zwischenzeitlich noch meinen ursprünglichen physischen Arbeitsplatz verlassen müssen und alle Notizen, sprich: Arbeitsanleitung und damit Spickzettel für Auftragsgestaltung und einzelne Produktpreise, im anderen Zimmer zurückgelassen. Spätestens ab diesem Zeitpunkt, da bin ich sicher, lieferte ich keinen Wert mehr für mein Team, aber egal. Manchmal preschte auch jemand aus seinem Kästelchen hervor, um festzustellen, dass genau in dem Moment, als er jemandem helfend zur Seite springen wollte, plötzlich Aufträge in seinem eigenen Arbeitsbereich landeten.

Die Arbeitsleistung verbessert sich, auch wenn es sich nicht so anfühlt

Zwischendurch bekamen wir einmal noch eine einzige lächerliche Minute Zeit - ja, der blanke Hohn - um blitzschnell irgendwelche Verbesserungen herbeizuführen oder uns anders zu organisieren, aber zumindest mein Team wurde bereits wieder in den Hauptraum gewischt, bevor der erste sinnvolle Satz zuendegesprochen war. Erstaunlicherweise steigerte sich aber die Performance beider Teams mit jeder Runde - die Spielleitung zählte jedes Mal die Anzahl der virtuell belieferten Menschen. Eine Teilnehmerin äußerte mutig das, was ich selbst dachte: "Können wir nicht wieder zu den Rollen zurückkehren?" Gefühlt ging es da alles viel besser. Holger kommentierte süffisant, ja, das sei dann post-agile Entwicklung.

Walk the talk

Man muss also durch dieses Szenario durch, nichts anderes hilft. In diesem Moment dämmerte wahrscheinlich nicht nur mir, sondern vielleicht auch anderen Teilnehmenden (aber das ist eine infame Unterstellung, die durch nichts außer jeweils persönliches Interview gestützt werden könnte), dass es sich mit Scrum Mastern und Coaches manchmal ähnlich verhält wie in der Textzeile von Genesis' Lied "Jesus he knows me": "Just do as I say, don't do as I do." Ich als Scrum Master stelle mich vor ein Team und labere die Menschen damit zu, dass sie doch gefälligst mal selbstorganisiert arbeiten sollen, ohne mir vorstellen zu können, wie bodenlos sich das erstmal anfühlen kann und wie essentiell es dabei ist, sich regelmäßig auszutauschen und Verbesserungen zu suchen, damit man als Team nicht untergeht in Chaos.

Zeitdruck extrem überzeichnet

Auch das Setting mit dem Zeitdruck ist gar nicht mal so unrealistisch, wenn man bedenkt, dass in wahrscheinlich vielen dieser SAFe-Initiativen da draußen ein grässlicher Zeitdruck wegen eines extern gesetzten Go-Live-Termins besteht, nach eigener Erfahrung so groß, dass die Protagonisten oft gar nicht in die Verlegenheit kommen, einander helfen zu müssen, weil sie kaum mit ihrem eigenen Kram fertigwerden, den sie pro Sprint schnüren mussten (so ganz selbstorganisiert halt), um die Arbeit zwischen heute und GoLive gleichmäßig aufzuteilen. (So, jetzt ist es mir auch noch gelungen, einen kleinen Seitenhieb auf skaliertes Irgendwas, in vielen Konzernen rufmordtechnisch "Scrum" genannt, unterzubringen. :-)) Der Zeitdruck in unserem Spiel musste natürlich extrem sein, damit wir ihn auch spüren konnten.

Übrigens habe ich die Erlaubnis eigeholt, meine Erfahrungen hier zu teilen. Zunächst dachte ich, dass es Ubongo Leaks ist, wenn ich hier alles ausbreite. Es macht nichts, meinte Jan, denn man begreift das, was da vor sich geht, ohnehin erst, wenn man es selbst einmal durchspielt und auf diese Weise selbst erfährt.

Also: ran an das Ubongo Flow Game. Es ist in meinen Augen sehr lehrreich für alle Scrum Master, Coaches, Berater, Facilitatoren und ähnliche Berufe im agilen Umfeld, und obendrein macht es noch Spaß, es mit den anderen Gästen zu spielen. 


Weiterführende Information

Hier ist eine Dokumentation für das Ubongo Flow Game als Catering-Simulation: https://www.teamworkblog.de/2020/05/die-ufg-catering-simulation-k-ubongo.html

Hier geht's zum frei verfügbaren Google Doc mit der Anleitung für die Catering-Variante des Spiels: https://docs.google.com/presentation/d/1qbOjt4o4z26DhvDZHmfvLP_4A6orzbW78RdFK0y09-g/edit#slide=id.p1





Kommentare

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Den passenden Job finden

Hier teile ich, wie ich daran arbeite, endlich den richtigen Job zu finden. Kleingedrucktes: Dieser Artikel richtet sich (natürlich) an jene, die gerade in der luxuriösen Position sind, dass sie nicht jedes Angebot annehmen müssen. Anstatt von Engagement zu Engagement zu hetzen und frustriert zu sein über Konzernstrukturen, fehlende Ausrichtung und die Erkenntnis, dass in einem selbst beständig die Hintergrundfrage nagt, ob es das ist, womit man seine immer knapper werdende Lebenszeit wirklich verbringen möchte, gibt es manchmal auch die Möglichkeit, die nächste berufliche Station etwas nachhaltiger auszusuchen - auch, um tatsächlich (etwas) mehr beitragen zu können.

Die Microsoft Teams-Not-To-Do-Liste

Viele hoffen, dass es  für die Einrichtung von Microsoft Teams  den Königsweg gibt, den perfekten Plan – doch den gibt es leider (oder glücklicherweise?) nicht. Genauso wenig, wie es jemals einen Masterplan für die Organisation von Gruppenlaufwerken gab, gibt oder je geben wird. Was gut und vernünftig ist hängt von vielen Faktoren und ganz besonders den Unternehmensprozessen ab. Sicher ist nur eines: Von alleine entsteht keine vernünftige Struktur und schon gar keine Ordnung. Dafür braucht es klare Entscheidungen.

Agilität ist tot. Ausgerechnet jetzt?

Agilität wird zurückgefahren, Hierarchien kehren zurück. Doch ist das wirklich der richtige Weg in einer Welt, die immer unberechenbarer wird? Oder erleben wir gerade eine riskante Rolle rückwärts?

Wie beschreibt man einen Workshop für eine Konferenz?

Konferenzen bieten immer ein gutes Forum, um sein Wissen und seine Erfahrungen zu teilen. Was für die Vortragenden selbstverständlich scheint, ist für die Besucher:innen oft unverständlich. Wie können Vortragende ihren Workshop in 2-3 Sätzen beschreiben, damit die Besucher:innen schnell einschätzen können, er sich für sie lohnt?

Gemeinsam eine Anwenderdokumentation erstellen

Unternehmenssoftware ist ein wichtiges Bindeglied zwischen Anwenderinnen und Anwendern, den Unternehmensprozessen und den Ergebnissen. Normalerweise schreibt der Hersteller der Software die Dokumentation für diejenigen, die die Software benutzen. Wenn die Software allerdings stark angepasst wurde, muss die Dokumentation von denen kommen, die die Prozessmaschine am besten verstehen - den Anwenderinnen und Anwendern. Wie könnte man das praktisch machen?

Scrum und Hardware: Es kommt auf die Basics an

Man kann Hardwareprodukte agil entwickeln. Zum einen kommt Scrum aus der Hardwareentwicklung. Die Softwerker haben die Hardwarekonzepte auf ihre Situation übertragen. Zum anderen hat Hardwareentwicklung heute ganz viel mit Software zu tun. Gerade in frühen Phasen kann man sich mit Simulationen noch viele Wege offen halten und mehrere Pfade parallel verfolgen. In diesem Beitrag empfehle ich eine Podcastfolge und ein Buch, für alle, die mit der Geschwindigkeit ihrer Hardwareentwicklung nicht zufrieden sind.