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

Wie lassen sich Ergebnisse definieren? - Drei Beispiele (WBS, CBP und BDN)

Ich habe schon darüber geschrieben, warum das Definieren von Ergebnissen so wichtig ist. Es lenkt die Aufmerksamkeit des Projektteams auf die eigentlichen Ziele. Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich drei Methoden vor, um leichter an Ergebnisse zu kommen.

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.

Microsoft Copilot - Notebook, Pages, Agents und mehr

Es tut sich sehr viel an der Copilot Front. Gefühlt entwickelt Microsoft mit aller Kraft die KI-Anwendung weiter. Mit dem letzten Update hat sich die Microsoft-Startseite stark verändert. Hier zeige ich, was sich hinter all den Begrifflichkeiten verbirgt und was davon alltagstauglich ist.

Schätzungen sind schätzungsweise überschätzte Schätze

"Wer viel misst, misst viel Mist." Zumindest ist diese Gefahr gegeben. Entweder misst man z. B. Mist, weil man zu früh zu KPIs zur Messung von Ergebnissen greift, oder aber man greift zu den falschen KPIs, die gar nicht das messen, was man wissen möchte. Einst war agiles Arbeiten der alternative Ansatz, aber inzwischen gibt es auch für einige Details dessen, was in Konzernen als "agil" praktiziert wird, einleuchtende alternative Ideen, die bis heute noch nicht so richtig auf die große Bühne vorgedrungen zu sein scheinen. 

Wenn es mal gerade etwas schwierig bei Kund:innen wird… Zwei Fragen, die uns helfen, unsere Strategie mit unseren Kund:innen abzusprechen.

Seit 2024 organisieren Bob Galen und ich eine Masterclass für agile Coaches. Wir möchten die Ausbildung von agilen Coaches verbessern und ihnen Techniken mitgeben, mit denen sie bei ihren Kund:innen etwas einfacher haben. Bisher haben wir in vier Durchgängen mit jeweils 14 Modulen ungefähr 70 Extraordinarily Badass Agile Coaches ausgebildet (/1/). In diesem Blogpost möchte ich ein paar Erfahrungen und simple Techniken aus der Masterclass teilen, wie wir unsere Strategie besser abstimmen können. Sie beschränken sich nicht auf agiles Coaching – das ist nur das Setting.

Teamleitungen gesucht

Was macht Teams erfolgreich? Kann man das lernen? Ab Herbst starten unsere Kurse für aktuelle und künftige Teamleitungen. Jetzt gibt es die Gelegenheit, den Kurs zu testen.

Wie überprüft man den aktuellen Stand einer neuen gemeinsamen Ablage?

Ihr habt in eurem Team die individuellen, unordentlichen Ablagen auf eine gemeinsame Ablage, die nach Vorgängen und Prozessen geordnet ist, umgestellt. Woher wisst ihr, ob das wirklich funktioniert? In diesem Beitrag gibt es 10 Auditfragen.

Nachschau zum Lean Coffee-Spezial "Agil einfach machen" (Interaktive Buchvorstellung)

Bei unserem Lean Coffee-Spezial Ende Mai waren wir von Lean Coffee Karlsruhe/Frankfurt Zeugen einer Buchvorstellung, doch nicht nur das – natürlich gab es auch einen nicht unbeträchtlichen Anteil an eigener Aktion, denn bei unseren Spezialterminen ist traditionell „Teilgabe“ angesagt. Das Autorenduo Christian Baron und Janick Oswald zeigte uns, was es mit „Agil einfach machen“ auf sich hat.  

Wie läuft ein Projekt zum Entwickeln von Szenarien ab?

Seit 2016 beschäftigen Edgar und ich uns intensiv mit der Szenariotechnik. Szenarien sind ein wirkungsvolles Werkzeug, um Projekte oder ganze Geschäftsmodelle auf ihre Zukunftstauglichkeit zu testen.

A simple project filing structure

Are there too many documents? But which ones are important? Project teams are drowning in information. There's no shortage of tools: emails, Slack channels, JIRA, Microsoft Teams, and Trello boards. But who can keep track of them all? A few simple rules can get a project team on track. I'll present the simplest project filing system here.