Responsibility Game

Sitzen Sie gerade in einem langweiligen Meeting? Oder arbeiten Sie an etwas, dessen Inhaltslosigkeit mit Vakuum vergleichbar ist?

Der Responsibility Process* von Christopher Avery hilft dabei, Probleme auf positive Art zu lösen, indem wir unsere natürlichen inneren Barrieren erkennen und überwinden:

Stoßen wir auf ein Problem durchlaufen wir bis zu 7 Phasen, manchmal innerhalb von Sekunden, aber oft stecken wir Tage, Wochen oder gar Jahre in einer Phase fest.

Beispiele helfen, um den Prozess plastisch zu machen. Nehmen wir hier also an wir hätten ein wichtiges Vorstellungsgespräch und müssten um 7 Uhr morgens aufstehen um pünktlich zu kommen.

Problem: Wir wachen auf, blicken auf den Wecker und sehen die leuchtenden Ziffern: 08:00 – eine Stunde vorher wollten wir spätestens aufstehen …

DENIAL: Der erste Impuls ist in der Regel das Leugnen der Situation: “8 Uhr? Das kann nicht richtig sein!” Wahrscheinlich stehen wir trotzdem senkrecht im Bett und das Herz schlägt 180.

LAY BLAME: “Schaaatz! Du hast den Wecker falsch gestellt!” Avery vermutet, dass die Schuldzuweisung an andere in unseren Gehirnen fest verdrahtet ist. Vielleicht brachte das in Urzeiten die entscheidende Millisekunde bei der Abwehr von Feinden?

JUSTIFY: In dieser Stufe gibt man nicht mehr anderen Personen die Schuld, sondern den Umständen. “Der Wecker ist kaputt.” oder “Es war wohl wieder Stromausfall.”

SHAME: Wenn man beginnt den Fehler bei sich selbst zu suchen ist man einen wichtigen Schritt weiter, die Stufen bauen aufeinander auf. Der Fokus der Gefühlswallungen verlagert sich von externen Verursachern auf interne. “Ich Idiot hab den Klingelton abgestellt.”

OBLIGATION: Ab dieser Phase kommt man schließlich ins Handeln. Man springt auf, macht Katzenwäsche, hüpft in den Anzug und rast erst zum und dann mit dem Auto, überschreitet die Geschwindigkeitsbegrenzung, parkt im Halteverbot und versucht irgendwie doch noch pünktlich zu kommen. Zeichen dieser Phase ist, dass es einem dabei schlecht geht. Man versucht seiner Verpflichtung nachzukommen, weil man den Erwartungen anderer entsprechen will. Wahrscheinlich hadert man noch im Vorstellungsgespräch mit sich und kann sich nicht zu 100% einbringen.

QUIT: In diese Phase flüchtet man sich, um Shame und Obligation aus dem Weg zu gehen. Man nimmt den Wecker vom Strom und verkriecht sich unter sein Kopfkissen und versteckt sich vor dem Problem.

RESPONSIBILITY: Erst in dieser Phase übernimmt man nach Averys Modell aktiv Verantwortung. Man lotet Optionen aus und entscheidet sich für die Option, mit der man das beste Gefühl hat. Die Last fällt von einem ab und man kann sich wieder zu 100% engagieren. Je nach Person und Situation kann die Lösung sehr unterschiedlich aussehen, in unserem Fall entschuldigt man sich vielleicht telefonisch und vereinbart einen neuen Termin.

Auf dem it-agile Partnertag schlug Ute vor, sich Gedanken zu machen, wie man den Prozess spielerisch erlernen könnte. Hier das Regelwerk (mit ein paar eigenen Ergänzungen):

Spieler: 4-8
Material:

• 2 Sets mit 7 Karten auf denen jeweils der Name einer der sieben Phasen des Prozesses steht.
• Klebe-Zettel oder Karteikarten und Stifte

Ablauf:

1. Einer der Spieler übernimmt die Rolle des “Verantwortlichen”. Er mischt das erste Set der 7 Karten und teilt sie verdeckt an seine Mitspieler aus. Jeder kriegt eine Karte. Bleiben Karten über, werden diese verdeckt zur Seite gelegt.
2. Jetzt denkt sich der “Verantwortliche” ein Problem aus oder nimmt am Anfang einfach das oben beschriebene und schildert es den Mitspielern.
3. Die Mitspieler denken sich einen Kommentar oder Gedanken aus, der zu dem geschilderten Problem und der auf ihrer Karte beschriebenen Phase passt und schreibt diesen auf einen Klebe-Zettel. Beispiel: Steht auf der Karte LAY BLAME und das Problem ist “Du stehst vor dem Auto und hast keinen Autoschlüssel” könnte der Spieler auf seinen Klebe-Zettel schreiben “Meine blöde Schwester hat mir den Autoschlüssel nicht wiedergegeben.” Jeder legt nun seinen Zettel für die anderen lesbar vor sich aus.
4. Der “Verantwortliche” muss nun erraten, in welche Phasen die Kommentare gehören. Dazu kriegt er das zweite Set an Phasen-Karten und ordnet jedem Mitspieler eine Karte zu. Dabei sollte er seine Gedanken laut aussprechen, damit die anderen nachvollziehen können was und warum er eine Zuordnung macht.
5. Hat der “Verantwortliche” alle Karten Zetteln zugeordnet drehen die Mitspieler ihre verdeckten Karten um. Diskutiert Abweichungen und die Gedanken dahinter.
6. Für jede richtige Zuordnung kriegt der “Verantwortliche” einen Punkt.
7. Jetzt wird der nächste Spieler “Verantwortlicher” und denkt sich ein neues Problem aus. Es geht wieder bei Schritt 1 los.

Wer die meisten Punkte hat ist Sieger. Wer den Prozess durch das Spiel besser versteht hat gewonnen ;-).

Das Buch von Christopher Avery wurde mittlerweile auch auf Deutsch übersetzt (LINK)*. Es gibt einen historischen Abriss und erklärt die einzelnen Phasen ausführlich und mit vielen Beispielen.

Holger Tewis ist Agile Enterprise Coach (Freiberufler)

Pipeline – ein Teambuilding Spiel

Letztes Jahr konnte ich leider nicht dabei sein, aber dieses Jahr habe ich ihn mir nicht entgehen lassen: Der Agile by Nature Play Day will für die tägliche Arbeit spielerische Formen finden und fördern, um beim Lernen zu helfen. 24 Spielwillige trafen sich in den Räumen von sitegeist in Hamburg, stellten sich gegenseitig Spiele vor und networkten über kalten Getränken. Bilder von dem Tag gibt es auf der Webseite von Agile by Nature zu sehen.
Von den vielen interessanten Sessions stelle ich hier als erstes ein Spiel aus der Session „Teambuilding Spiele“ von Hendrik vor.

Pipeline
Bei Pipeline geht es darum, im Team eine rollende Kugel in ein Ziel zu befördern. Dazu bekommt jedes Team einige Rinnen. Die Anzahl variiert mit der Anzahl der Teammitglieder. Es sind immer deutlich weniger Rinnen als Mitspieler. Das Team muss schnell und geschickt Rinne an Rinne reihen, während die Kugel durch diese rollt. Leider ist die Gesamtlänge aller Rinnen kürzer als die zu überwindende Strecke …

Es gibt die folgenden einfachen Grundregeln:

• Die Kugel muss jederzeit vorwärts durch eine Rinne rollen.
• Kein Teilnehmer darf die Kugel berühren.
• Eine Rinne darf nur von genau einem Team-Mitglied gehalten werden.
• Wenn jemand eine Rinne mit der Kugel in der Hand hat, dann darf diese Person sich nicht mit der Rinne im Raum bewegen.

Material:

• Mehrere Rinnen (z.B. Regenrinnen aus dem Baumarkt)
• Eine Kugel, die in die Rinne passt

Lernziel ist es, dass sich das Team koordinieren muss, um die Kugel ins Ziel zu bringen. Die Kugel kann alles mögliche repräsentieren, z.B. ein Software-Artefakt, das erstellt und deployed werden soll.
Das Spiel lässt sich leicht an den jeweiligen Kontext anpassen, z.B. durch Hinzufügen oder Anpassen von neuen Regeln oder durch Aufteilung in mehrere Teams, die gegeneinander antreten müssen. Auch die Aufgabe kann angepasst werden, z.B. indem ein Team mehrere Kugeln ins Ziel bringen und deren Durchlaufzeit kontinuierlich reduzieren muss.
Eine weitere Variationsmöglichkeit ergibt sich durch die Art des Zielbehälters. In unserem Fall war dies eine flache Plastikbox. Das hat den Schwierigkeitsgrad erhöht, da die Kugel leicht über das Ziel hinausschießen kann. Eine breite Tonne oder ein Eimer als Ziel wäre meiner Meinung nach einfacher gewesen.

Hier eine Aufnahme von einem unserer grandiosen (Fehl-) Versuche:

Mein Fazit zum Play Day

Der Play Day ist eine super Veranstaltung, auf der man viel lernt und neue Bekanntschaften macht.

Besonders empfehlenswert ist er für Agile Coaches und solche, die es werden wollen. Im kommen Jahr will ich unbedingt wieder dabei sein und möglichst ein eigenes Spiel vorstellen. So kann man in freundlicher Umgebung die Moderation eines Spiels üben, bevor man es am eigenen Team ausprobiert.

Also, einen Daumen hoch für die Veranstaltung!

Ich werde in ein, zwei Blog Posts noch weitere Spiele vorstellen, die ich kennenlernen durfte.

Lean/Kanban Games – Teil 2

Neben dem Push & Pull Game hat die Limited WIP Society Hamburg einige weitere Lean/Kanban Games gespielt, darunter das Name Game, das die Nachteile von Multitasking und Context Switches sichtbar macht:

Hier nur das Executive Summary:

1. Schreibe 5 Namen auf, alle gleichzeitig, d.h. erst alle ersten Buchstaben, dann alle zweiten usw. Miss wie lange es pro Name dauert und die Gesamtzeit.
2. Dann schreibe die 5 Namen nacheinander und miss wieder die Zeit.
3. Vergleiche die Ergebnisse und diskutiere

Ein ausführliche Beschreibung gibt es z.B. hier: LINK

Das Sixes Game soll die Auswirkungen von übertriebenen Sicherheitspuffern in Schätzungen von Projekten sichtbar machen. Auch dieses Spiel skizziere ich hier nur grob. Es gibt ein ausführliches Paper dazu: LINK

Jeder Teilnehmer übernimmt ein Teilprojekt, dessen Dauer davon abhängt, wann er mit einem 6-seitigen Würfel eine 6 würfelt. Für jeden Wurf dauert das Projekt einen Tag. In einem Testprojekt lässt der Moderator alle ein paar Mal würfeln, um ein Gefühl für die Wahrscheinlichkeiten zu kriegen.

Dann geht es los. Ein wichtiges Projekt für den besten Kunden steht an und die Spieler sollen sich auf eine Anzahl Tage einigen, die jedes Teilprojekt maximal dauert (MAX TAGE). Die dem Kunden kommunizierte Gesamtdauer beträgt dann:

PROJEKT GESAMTDAUER = ANZAHL TEILPROJEKTE * MAX TAGE

In dieser Runde dauert jedes Teilprojekt also mindestens MAX TAGE. Wenn nur ein Teilprojekt länger braucht, verlängert sich auch die Gesamtdauer.

In der Diskussion danach sollte die Gruppe feststellen, dass viele Spieler wesentlich früher fertig sind und Zeit geblockt haben, die sie eigentlich nicht brauchen. Die Frage ist, wie man die Projekte organisiert, damit einerseits genügend Puffer da ist, aber andererseits zuviel Pufferzeit nicht die Gesamtdauer übertrieben aufbläst.

Eine Lösung des Problems, mit 25% kürzerer Projektdauer bei 95% Erfolgswahrscheinlichkeit, kommt aus der Theory of Constraints: Die geschätzten Sicherheitspuffer werden für jedes Teilprojekt halbiert und die Hälfte der gestrichenen Summe für länger laufende Teilprojekte am Ende des Gesamtprojekts hinzugefügt. Wenn also die Schätzung mit Sicherheitspuffer für 10 Teilprojekte bei 16 Tagen liegt, gibt man den Projekten nur 8 Tage und fügt dafür am Ende (10*8)/2=40 Tage als Puffer für Teilprojekte im Verzug hinzu.

Die statistischen Hintergründe dazu findet man in dem genannten Paper.

Bei der Durchführung mit der Limited WIP Society, haben wir natürlich auch dieses 95% sichere Projekt gerissen – Murphy lässt grüßen ;-).

Push & Pull Game – Lean/Kanban Games Teil 1

Hafenblick, kühle Getränke, schöne Menschen – die limited WIP Society traf sich diesmal bei IT-Agile.

Das Thema waren Lean/Kanban Games und die möglichen Spiele füllten schnell das Board. Da die Beschreibung etwas länger geworden ist, teile ich sie in zwei Beiträge auf (Teil 2 HIER).

Papierboote falten als Push/Pull-Game 

Beim Push/Pull-Game geht es darum die Unterschiede von Push und Pull-Systemen sichtbar und fühlbar zu machen. Dabei übernimmt jeder Teilnehmer unterschiedliche Verarbeitungsschritte auf einer Art Fließband. Wir haben Papierboote gefaltet, aber beliebige Varianten sind denkbar (z.B. Cup Assembly).

Als Material braucht man:

• Einen großen Tisch
• einen großen Stapel weiße DINA4-Zettel
• ein paar gelbe DINA4-Zettel
• zwei Stoppuhren bzw. Smartphones mit Stoppfunktion

Wir waren 5 Spieler mit folgenden Schritten (bei mehr oder weniger Spielern, einfach die Schritte weiter aufteilen bzw. zusammenfassen):

1. Spieler: Papier vom Stapel nehmen, einmal in der Mitte falten und für den nächsten in der Mitte anfalzen
2. Beide Ecken umknicken, als würde man einen Flieger bauen wollen.
3. Unterkanten auf beiden Seiten nach oben klappen und die überstehende Ecke auf einer Seite nach innen umklappen, so dass ein Hut entsteht.
4. In den Hut greifen und zum Quadrat umklappen. Dann die unteren Ecken hochklappen und zum Schiff auseinanderziehen.
5. Der fünfte Spieler nummeriert die Boote und schreibt die Ankunftszeit auf. Achtung: Spieler 5 und der Moderator müssen zu Beginn synchron eine Stoppuhr starten.

Wem das zu wenig visuell ist, möge sich folgendes Video zu Gemüte führen:

Es lohnt sich übrigens, die Spieler einen Probelauf durchführen zu lassen, bevor es richtig losgeht!

Als erstes haben wir im Push-System gearbeitet, d.h. jeder Spieler hatte einen beliebig großen Puffer vor bzw. hinter sich. Nach wenigen Minuten hatten sich so zwischen einigen Spielern große Warteschlangen gebildet.

Nach 2:30 Minuten gibt der Moderator einen gelben Zettel in die Queue. Achtung: Wenn sich die Puffer sehr schnell füllen, lieber etwas früher den gelben Zettel hineingeben.

Ist der gelbe Zettel durch den Prozess durch, kann das Spiel gestoppt werden.

Am Ende sollte Spieler 5 eine Übersicht über die Ankunftszeiten erstellt haben:

In unserer Gruppe entwickelte sich der Durchsatz in Richtung 4 Schiffe pro Minute. Ich selbst war an Position 4 und hatte eine recht komplexe Aufgabe, so dass sich mit der vor mir anwachsenden Queue auch der gefühlte Druck erhöhte. Gerne gesehene Kommentare von den Spielern links und rechts waren: “Ach bei dem staut es sich ja wieder mal” oder “Den müssen wir auswechseln.” Sowas kommt in realen Projekten natürlich niemals vor ;-).

Als das Spiel gestoppt wurde hatten wir etwa ein Dutzend unfertige Schiffe als Waste in den Puffern liegen.

Dann haben wir die Pull-Variante gespielt. Hier ist der einzige Unterschied, dass jeder Spieler ein Pufferlimit von 1 hat, d.h. er darf erst mit dem nächsten Papier anfangen, wenn der auf ihn folgende Spieler seinen Zettel angenommen hat.

Nach kurzer Zeit wartete die gesamte Prozesskette darauf, dass ich mit meinem Schritt fertig wurde, was gefühlt noch schlimmer war, als nur die Queue anwachsen zu sehen.

Auch bei der Pull-Variante ging der Durchsatz auf ca. 4 Schiffe pro Minute zu.

Der Waste waren die 4 unfertigen Schiffe bei den vier Faltern.

Nun betrachteten wir die Durchlaufzeit anhand des gelben Schiffes in beiden Varianten. In der Push-Variante hatte das Schiff eine Durchlaufzeit von 1:53 Minuten, in der Pull-Variante nur 1:07, da es nicht in vollen Queues warten musste.

In der anschließenden Diskussion sprachen wir darüber, dass man im Pull-System die Slacktime natürlich statt für Nörgeleien dafür nutzen sollte den Teammitglieder zu helfen bzw. kreative Verbesserungsvorschläge zu erarbeiten, die den Engpass verringern.

Variante: einen zweiten gelben Zettel reingeben um zu zeigen, dass sich die Durchlaufzeit im Push-System mit der Zeit vergrößert.

Dank an Frank und Florian für Fotos und Ergänzungsvorschläge!

Das derzeit beste deutsche Kanban-Buch* wurde übrigens von Florian übersetzt.

Kurzbeschreibungen für Name Game und Sixes Game in Teil 2.