Ich finde Scrum klasse und habe bei meinen Workshops den Anspruch Scrum-Neulingen in kurzer Zeit so viel wie möglich von meiner Begeisterung für das agile Framework mitzugeben. Dafür war ich lange auf der Suche nach dem richtigen Mix zwischen Theorie und Praxis, aber vor allem nach einer Möglichkeit meinen Teilnehmern die besonderen Scrum-Momente selbst erleben zu lassen.
Scrum-Moment selbst erleben
Es war also klar, ich brauche eine Scrum-Simulation, die eine echte Projektsituation so gut wie möglich nachempfindet. Wie z.B. Lego City. Ich war schon drauf und dran tausende von Legosteinen zu kaufen, allerdings fehlte mir etwas sehr Wichtiges an dieser Simulation: das Produkt. Eine Lego City, auch wenn man noch so viel Vorstellungskraft hat, ist kein echtes Produkt, hinter dem auch kein echtes Kundenbedürfnis steht. Dabei geht es in agilen Projekten doch vor allem darum.
Mit meiner Simulation wollte ich daher näher an die Softwareentwicklung, in der Scrum seinen Ursprung hat und in der man in kurzen, iterativen Zyklen Kundenwert genieren kann. Aber natürlich kann ich von meinen Teilnehmern nicht erwarten, innerhalb eines Tages Programmcode zu schreiben, zumal nur die wenigsten tatsächlich programmieren können.
Was also simuliert die Erstellung einer Software am besten? Was muss auch analysiert, designt, entwickelt, getestet und dokumentiert werden? Und was ist dabei so bekannt und einfach, dass jeder (Nicht-) Techi es trotzdem nachvollziehen kann?
Die perfekte Basis: ein Gesellschaftsspiel
Die Prozessphasen bei der (Weiter-) Entwicklung eines Gesellschaftsspiels sind nahezu identisch mit denen aus der Softwareentwicklung und damit die perfekte Basis für eine Scrum-Simulation.
In meinen Scrum Workshops starte ich die Simulation mit der Aufgabe die Produktvision des Spiels zu formulieren. Was ist das Ziel des Spiels? Wer soll es spielen? Wie funktioniert es? Das ist wichtig, damit alle Teilnehmer das gleiche Zielbild des Produkt im Kopf haben und später nicht zu viel Zeit benötigt wird, um über Details zu sprechen, die für die Scrum-Simulation nicht relevant sind.
Danach sollen die Teilnehmer die einzelnen Funktionen bzw. Elemente des Spiels bestimmen. Braucht man zum Spielen einen Würfel/ Karten/ Figuren? Gibt es eine Verpackung? Im nächsten Schritt, der Priorisierung der Elemente nach ihrer Wichtigkeit für das Spiel, erfahren die Teilnehmer die ersten Herausforderungen, die Scrum mit sich bringt. Sind die Figuren und das Spielbrett nicht gleichermaßen wichtig? Was ist eigentlich mit der Spielanleitung? Was mache ich, wenn ich nicht genau weiß, was wichtiger ist?
Ist die Priorisierung abgeschlossen, bekommt jeder Teilnehmer die Aufgabe, ein Element des Spiels mit Hilfe einer User Story näher zu beschreiben – z.B. „Als Spieler benötige ich ein Spielbrett, damit ich mich in die Spielwelt einfühlen kann.“ Und auch die Akzeptanzkriterien, funktionale und nicht-funktionale Anforderungen an das Produkt, üben die Teilnehmer an dieser Stelle: „Angenommen ein Spieler ist Farbenblind, wenn er sich auf dem Spielbrett zurechtfinden will, muss er dennoch Kontraste erkennen können.“
Danach folgt das Schätzen der Stories mit Planning Poker, der Aufbau des Sprint Boards und die Vorbereitung des Burndown Charts, bevor wir die Aktivitäten zur Sprint Planung abschließen und in die nächste Phase übergehen. Bis hierhin fällt vielen Teilnehmern auf, dass die Vorbereitung des Sprints sehr viel Zeit in Anspruch nimmt. Die Rolle des Product Owners kann nicht mal so nebenher gemacht werden, wie oftmals angenommen wird.
Für die Simulation der Sprints, plane ich bei einem Tages-Workshop, drei Sprint-„Tage“ à 10 Minuten ein. Nach jedem „Tag“ haben die Teilnehmer 5 Minuten Zeit für ein schnelles Daily Stand Up. Der große Aha!-Effekt bei den Teilnehmer ist, dass es ihnen anfangs schwer fällt zu sagen, was sie persönlich zum Erfolg des Sprints beigetragen haben.
Für die Umsetzung des Spiels in den drei Sprint-„Tagen“ (insgesamt 30 Minuten) ist die Kreativität der Teilnehmer gefragt. Mehr als ein bisschen Pappe sowie Post Its, Klebepunkte und Markern etc. stelle ich ihnen nicht zur Verfügung. Dennoch sind bisher immer richtig gute Spiele entstanden.
Zu guter Letzt lasse ich im Sprint Review die Teams ihre Spiele vorstellen und dafür pitchen. Spaß macht es, wenn man mit mehreren Teams parallel gearbeitet hat und eine gewissen Konkurrenzsitutation entstanden ist.
Meinen Workshop schließe ich dann mit einer kleinen Retrospektive, in der ich frage, was den Teilnehmer gefallen hat, was sie mitnehmen und was man noch verbessern könnte.
Für einen Einstieg in Scrum und einen ersten Überblick reicht für die Simulation ein Tag mit 7–8 Stunden aus. Zwischen den einzelnen Aufgaben gebe ich theoretischen Input und lasse viel Platz für Fragen.
Auch Skeptiker lernen so die Vorteile
Meine Simulation ist das Resultat vieler Workshops und ich variiere diese immer wieder, um Neues auszuprobieren und so viele Selbsterkenntnisse für die Teilnehmer wie möglich zu schaffen. Es macht wirklich großen Spaß zu sehen, dass auch z.B. anfangs skeptische Manager durch eine spielerische Simulation den Mehrwert, aber auch die Erfolgsfaktoren und Knackpunkte von Scrum erkennen. Auch wenn im Nachgang nicht jeder direkt mit seinem Team Scrum einsetzt, erkennen jedoch die meisten die Vorteile und sind offener im Umgang mit agiler Arbeitsweise.
Wenn ihr meine Simulation gerne in Eurem Team anwenden möchtet und ihr noch Fragen habt, kommt gerne auf mich zu. Wer gerne mal eine Scrum-Simulation bei mir machen möchte, den lade ich herzlich zu unseren Workshops ein.
neubau 