Wenn ich in ein Unternehmen komme, höre ich von den Entwicklern oft Sätze wie “Ich bin nur zu 50% in dem Projekt” oder “Wenn es im Produktionssystem brennt, muss ich mich drum kümmern, das kann sonst keiner”. Auch aus meiner Zeit als Projektportfoliomanager einer Versicherung erinnere ich mich an Vorstandsentscheidungen der Art “Das ist aber wichtig und muss dann eben parallel zu den anderen Projekten laufen” oder “Dann müssen die Leute eben mal 120% geben”. Mal ganz abgesehen davon, dass hier Organisationen ihre Hausaufgaben nicht gemacht haben, kann man aus diesen wenigen Sätzen sicher Diskussionen ableiten, die Bücher füllen würden. Aber ich möchte auf etwas ganz Bestimmtes hinaus. Letzte Woche war ich auf der AgileEE 2010 in Kiew und habe dort an Mary Poppendiecks Master Class “Lean Software Development” teilgenommen. Mary hat uns ein Spiel vorgestellt, mit dem man Linienführungskräften hervorragend aufzeigen kann, wie unsinnig es ist, Entwickler mehreren Projekten gleichzeitig zuzuweisen, in der Hoffnung, so alles gleichzeitig und schnell abarbeiten zu können. Das Spiel heißt “Multitasking Name Game” und es stammt ursprünglich von Henrik Kniberg.

Setup

• Formt gleichgroße Gruppen aus sechs bis acht Teilnehmern
• Eine Person aus jeder Gruppe ist ein Entwickler, die anderen sind Auftraggeber
• Jede Person benötigt einen Stift, jeder Auftraggeber benötigt zwei Blätter Papier
• Jeder Auftraggeber hat ein Projekt “Schreibe meinen Namen auf”, das von dem Entwickler bearbeitet werden soll
• Ein Timer ist für alle sichtbar und steht auf 0

Szenario 1

Alle Gruppen beginnen zur gleichen Zeit, der Timer wird gestartet

• Der erste Auftraggeber notiert die Startzeit auf dem Zettel und gibt ihn dem Entwickler
• Der Entwickler schreibt den ersten Buchstaben des Vornamens des Auftraggebers auf und gibt den Zettel zurück.
• Weiter geht es mit dem zweiten Auftraggeber und so weiter.
• Wenn die Runde durch ist, geht es mit dem zweiten Buchstaben des Vornamens weiter
• Wenn der Name eine Auftraggebers komplett ist, schreibt er die Endzeit auf den Zettel
• Das Spiel ist vorbei, wenn die Namen aller Auftraggeber auf den jeweiligen Zetteln stehen.

Die folgende Abbildung zeigt ein typisches Ergebnis dieses Szenarios:

Anschließend wird das Spiel mit dem folgenden Szenario gespielt:

Szenario 2

Alle Gruppen beginnen zur gleichen Zeit, der Timer wird gestartet

• Der erste Auftraggeber notiert die Startzeit auf dem Zettel und gibt ihn dem Entwickler
• Der Entwickler schreibt den Vornamen des Auftraggebers auf und gibt den Zettel zurück.
• Der Auftraggeber schreibt die Endzeit auf den Zettel
• Weiter geht es mit dem zweiten Auftraggeber und so weiter.
• Das Spiel ist vorbei, wenn die Namen aller Auftraggeber auf den jeweiligen Zetteln stehen.

Die folgende Abbildung zeigt ein typisches Ergebnis dieses Szenarios:

Wie man sieht, liegt die Durchlaufzeit für ein einzelnes Projekt im ersten Szenario zwischen 63 und 95 Sekunden, während sie im zweiten Szenario zwischen 4 und 6 Sekunden liegt.

Im ersten Szenario liegt die Gesamt-Durchlaufzeit für alle Projekte bei 101 Sekunden, bei 25 Sekunden im zweiten.

Wie man leicht erkennt, muss der Entwickler im ersten Szenario 5 Projekte mehr oder weniger gleichzeitig bedienen. Allein die Übergabe des Papiers dauert ewig, weil mal ein Blatt wegrutscht, der Stift runterfällt, die Reihenfolge durcheinanderkommt, gestückelte Information (Buchstaben) fließen muss usw. Im zweiten Szenario wurde der Projekt-Durchfluss (Flow) auf genau ein Projekt zur Zeit reduziert. Es gibt keine großen Rüstzeiten, kein Task-Switching. Besonders beeindruckend ist die Tatsache, dass alle Projekte sehr viel früher fertig geworden sind als in Szenario 1, obwohl einige später angefangen haben als vorher.

Alles in allem eine sehr beindruckende Argumentation dafür, dass man mehr auf den Flow achten sollte als zu versuchen, alle Auftraggeber gleichzeitig glücklich zu machen.

Kennt Ihr ähnliche Spiele oder Demonstrationen? Immer her damit.