Das Dysfunctional Team Game

dysfunctional team game

Update: Eine Beta der Dokumentation des Dysfunctional Team Game findet sich jetzt hier: Dysfunctional Team Game Dokumentation (PDF Download)

Jürgen ist sichtlich nervös. Ich möchte wissen ob ihm nicht klar gewesen sei, dass wenn ich den Termin mit meinem Chef 2 mal verschieben muss weil sein Team partout nicht fertig wird, ich selbst unter Druck gerate. Ob er fertig ist, wie er es bereits für heute Mittag zugesagt hatte. Ob er eine Vorstellung habe, was diese ständigen leeren Versprechungen auch meinem Standing antun. Das ich nicht garantieren kann, dass wir langfristig weiter miteinander arbeiten können. Jürgen druckst etwas herum, die Anforderungen wären unklar gewesen und man hätte ja so wenig Zeit gehabt. Ich lasse nicht locker. Denn ich möchte Jürgen ablenken, damit sein Team die wichtigen Fragen die er eigentlich mit mir klären sollte möglichst nicht mehr heute beantwortet bekommt. Und da geht auch schon der Wecker. Der vorletzte Tag ist um, und die Chancen stehen schlecht, dass das Team am letzten “Tag” überhaupt etwas zuwege bringt. Und das ist gut so.

Das Dysfunctional Team Game ist eine Simulation eines Projektablaufs, die ich vor allem bei der Einführung von agilen Methoden nutze, um ein Bewusstsein zu wecken für die Dinge die in Teams und Projekten schief laufen können, egal ob agil oder nicht. Die Teilnehmer versuchen gemeinsam eine von mir als Kunde definierte Anzahl an Aufgaben zu erledigen und werden dabei aufgrund der Kürze der Zeit (und meiner heimlichen Sabotage) mit einer Reihe von Problemen konfrontiert, die wir im anschließenden Workshop zu agiler Softwareentwicklung mit Methoden wie Scrum zu lösen versuchen. Selbst wenn wie auf der Agile Cologne gestandene Professionals mit dieser Aufgabe konfrontiert werden, entstehen zwar mehr und schnellere Erkenntnisse, aber mehr umgesetzt wird trotzdem nicht. Dies beweist aus meiner Sicht, wie eng agile und nicht-agile Welt unter Druck zusammenwachsen, denn die Probleme lassen sich nicht nur übertragen, sondern auch auf einen Mangel bei den selben Werten zurückführen.

1 Kunde (Workshopleiter)
1 Projektleiter
1 Team

Das Team erhält eine Reihe von Aufgaben die in 5 “Tagen” zu je 4 Minuten abgearbeitet werden sollen. Jeder Tag wird von einer 1-minütigen Nachtruhe gefolgt, in der das Team seine Gefühle zur Arbeit ausdrücken darf aber nicht über die Arbeit selbst sprechen. Der Kunde nimmt erledigte Aufgaben ab und beantwortet Fragen des Projektleiters. Widerwillig, und mit vielen Rückfragen.

Als Kunde spiele ich eine zentrale Rolle in dieser Simulation. Nicht nur bestimme ich durch die Art der Aufgabenstellung was überhaupt schaffbar ist, sondern steuere über die Wahl und den Umgang mit dem Projektleiter den Fluss von Informationen – und von Druck. Neben den perfiden Fehlern die in den Anforderungen enthalten sind ist es der Druck den ich auf Projektleiter und durch ihn auf das Team ausübe mein bestes Werkzeug um dafür zu sorgen, dass das Team möglichste viele Antipatterns produziert. Denn diese sind die wahren Punkte bei diesem Spiel: Was für Probleme haben wir identifiziert? Und wie können wir Agile Methoden nutzen um diese Probleme zu beheben?

Versteckte Probleme (kein Anspruch auf Vollständigkeit):

– Aufgaben nicht in der korrekten Reihenfolge/Priorität (ändert sich in jedem Fall, wenn das Team das erste Mal nachfragt; idealerweise auf Sachen die aufwändig und bisher unbearbeitet sind)
– einige Aufgaben nicht lösbar mit bestehendem Team (z.B. weil auf Finnisch, Dänisch -> werden auf Nachfrage runter priorisiert, vor allem wenn das Team versucht sie trotzdem zu lösen)
– Aufgaben die nicht als solche formuliert sind (Frei nach dem Motto “Mach das geht”, auf Nachfrage wird aber eine vage Aufgabenstellung genannt)
– Aufgaben doppelt (“Ja, hab ich doppelt gesendet, das sieht man doch”; und wenn sie aussortiert werden; “nein, natürlich brauche ich das zwei mal; einmal auf Deutsch, einmal auf Englisch”)
– Aufgaben die doppelt aussehen, aber unterschiedliche versteckte Anforderungen haben (s.o.) oder bei genauer Betrachtung doch leicht voneinander abweichen
– Aufgaben die ein anderes Ziel suggerieren als tatsächlich gefordert oder verschiedene Antworten zulassen (bei der Abnahme ist der Teamansatz dann grundsätzlich der Falsche)
– Aufgaben bei denen offensichtlich Anforderungen fehlen (und die man frei natürlich erfinden kann, wenn nachgefragt wird; am Besten vergisst man hier noch mal was)
– Material das fehlerhaft ist (veraltete oder komplett falsche Daten; fällt natürlich erst bei der Abnahme auf)
– Material das schlecht erklärt ist (bspw. eine Broschüre die in 2 Sprachen vorliegt und mit der Englischen Seite nach oben; die Deutsche Seite ist aber Grundlage für die Aufgaben)
– Nicht genug Material das alle im Team arbeiten können
– Schneller Termindruck bei einer Aufgabe
– Kunde am ersten Tag nicht erreichbar (um sicherzustellen, dass das Team ohne Prio in eine Richtung los laufen kann die nachher falsch “wird”)

Probleme decke ich dem PL gegenüber auf Nachfrage auf, aber auch wirklich nur die konkret nachgefragten!

Im Anschluss an das Dysfunctional Team Geame verwende ich eine halbe Stunde darauf, das Team zu fragen welche Probleme ihnen bewusst geworden sind. Bei den Anfängern schließt ein Workshop an, an dessen Ende ich noch mal auf die selbst erarbeiteten Antipatterns zurückkomme und Punkt für Punkt das Team bitte, innerhalb der vorgestellten agilen Methoden Lösungen zu finden. Damit habe ich die agilen Methoden, aber auch die entsprechenden Werte vermittelt.

Welche Antipatterns kennt Ihr noch? In meiner Sammlung fehlen aktuell noch Dinge wie Wissensinseln (zeit zu kurz, jemand wird aus dem Team genommen) oder direkten Durchgriff durch Kunden. Freue mich über Feedback und Fragen!

 

1 Gedanke zu “Das Dysfunctional Team Game”

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.