Neulich durften wir bei der DB Systel im Frankfurter Silberturm zu Gast sein und ein paar neue Spiele ausprobieren. Es hat allen viel Spaß gemacht, und wir haben wieder Einiges gelernt, was sich bei der Vermittlung von agilen Denkweisen verwenden lässt.
Ein Spiel war Magic Maze, ein kooperatives Spiel gegen die Uhr, bei dem sich die Spieler nur in kurzen Pausen absprechen dürfen. Hoher Spaßfaktor, sehr empfehlenswert! (Die seriösen Inhalte des Spiels sind Teamwork, Retrospektiven und kontinuierliche Verbesserung.)
Dabei fiel mir etwas auf, worüber ich noch nie nachgedacht hatte: Wir spielen ein neues Spiel, obwohl die meisten die Spielregeln nicht gelesen haben. Regeln lesen ist ja auch langweilig, genau so wie Handbücher lesen.
Zum Beginn gab es ein kurzes Demo von Kirsten und schon ging’s los. Am Anfang waren wir natürlich ganz schlecht, nach mehreren Spielrunden wurde es allmählich besser. Außer ein paar freundlichen Tipps gab eigentlich nur learning by doing; ich machte irgendwas und merkte später, dass das nicht ganz so gut war (um es vorsichtig auszudrücken). OK, manchmal mussten meine MitspielerInnen es mir auch direkt sagen :-)
Alles, was wir über das Spiel dazugelernt haben, stand nicht in der Anleitung. Die Spielanleitung brauchten wir vielleicht, um die Spielregeln für ein paar Grenzfälle nachzusehen. Unsere Strategien und Tricks aber entwickelten sich im Laufe des Spielens vor allem während der “Nachbesprechungen”, wenn wir mal wieder gegen die Uhr verloren hatten.
Das kam mir von irgendwoher bekannt vor: so trocken und langweilig wie die Spielregeln für ein Brettspiel sind auch die Spezifikationen für eine neue Software. Hier ein Auszug aus den Spielregeln von Magic Maze, klingt das nicht original wie Spezifikations-Prosa?
Hat ein Spieler eine Aktion durchgeführt, die den Regeln entspricht, aber nicht hinreichend dem Spielziel dient (z. B. eine Heldenfigur zu weit nach Norden zu setzen), kann nur ein Spieler mit dem entsprechend entgegengesetztem Aktionsplättchen (in diesem Fall der Spieler mit dem Aktionsplättchen „Bewegung nach Süden“) diesen „Fehler“ korrigieren.
Die Spezifikationen sind wertvoll, keine Frage. Aber was sich im Laufe des Spiels, also der immer wieder mit leichten Variationen ausgeführten Geschäftsprozesse, entfaltet, ist nur begrenzt vorhersehbar.
Oft wird der Fachabteilung zugemutet, im Voraus an alle Sonderfälle zu denken, und sich widerspruchsfrei festzulegen. Das ist ungefähr so, wie ein Spiel zu erfinden, indem man das Spielfeld skizziert und die Spielregeln schreibt, aber ohne es ein einziges Mal auszuprobieren. Schwierig allemal und eine undankbare Aufgabe.
Im Vorfeld mehr nachzudenken hilft nicht. Spielen hilft, also funktionierende Software ausliefern und im Produktivbetrieb einsetzen.
Matthias Berth