Eine Methodik auf Abwegen: Agiles Plot-Management

In der Regel wird LARP in Echtzeit gespielt, wobei zur Lösung des Plots nur eine begrenzte Zeit zur Verfügung steht. Allerdings halten sich Spieler selten an den (ihnen nicht bekannten) Zeitplan: Oft brauchen sie ewig, um einen für einfach gehaltenen Plotstrang zu lösen, manchmal lösen sie aber auch einen für schwierig gehaltenen Plotstrang in kürzester Zeit und stehen danach gelangweilt herum.

Die Orga wiederum muss das Fortschreiten des Plots möglichst gut unter Kontrolle haben, damit die Spieler zum angestrebten Zeitpunkt die Lösung herbeiführen und zufrieden nach Hause fahren können.

Dieser Artikel beschreibt die Grundlagen der agilen Software-Entwicklung und deren Übertragbarkeit auf LARP-Veranstaltungen. In weiteren Artikeln werde ich tiefer in die Materie einsteigen und die einzelnen Punkte konkretisieren. Hier werden zunächst die relevanten Begriffe und das grobe Konzept eingeführt

Zeitabschnitte

Bei agilen Methoden geht es hauptsächlich um Zeitmanagement.

Genauer: Es geht darum, dass Zeitabschnitte möglichst exakt eingehalten werden und keine Handlungen länger brauchen, als eingeplant wurde. Einen solchen Zeitabschnitt nennt man Timebox.

Die wichtigste Eigenschaft einer Timebox ist, dass sie möglichst nicht überschritten wird. Beispiel: Wenn für eine kurze Status-Besprechung 15 Minuten angesetzt sind, dann dauert diese Besprechung auch nur 15 Minuten. Wenn ein Problem erkannt wird, das länger diskutiert werden muss, so wird dies sofort in eine eigene Besprechung ausgelagert, an der vielleicht noch nicht einmal alle jetzt Anwesenden teilnehmen müssen.

Geschichten und Epen

Eine Story beschreibt in der Software-Entwicklung eine Programmfunktion und deren groben Hintergrund. Dies sind meist Sätze nach dem Muster “Als [wer möchte etwas] möchte ich [Funktion], um [Begründung und Motivation]”. Ein Beispiel wäre “Als Web-Surfer möchte ich per Druck auf Backspace zur vorherigen Seite zurückgehen, damit ich schneller im Web navigieren kann.” Oder auch: “Als Magier möchte ich einen Feuerball sprechen können, um meine Feinde standesgemäß zu grillen.”

Einige dieser Stories sind wichtiger als andere.

Verwandte Stories, die inhaltlich zusammengehören, kann man zusammenfassen zu einem Epic. Ein Epic ist nur dann abgeschlossen, wenn alle darin enthaltenen Stories abgeschlossen wurden.

Stories lassen sich einfach auf LARP-Plots übertragen: Jeder Punkt, den die Spieler im Plot erreichen sollen, bekommt eine eigene Story. Plotstränge, die mehrere dieser Stories verbinden, können zu Epics zusammengefasst werden.

Der Plot Owner

In der agilen Software-Entwicklung gibt es die Rolle des Product Owners. Dies ist die Person, die mit einer Vision des Produktes an die Entwickler herantritt und versucht, diese mit den Entwicklern zusammen umzusetzen. Im LARP-Bereich heißt die Position meistens “Plot-Koordinator” oder “Head Writer”, im Rahmen dieser Reihe werde ich sie einfach “Plot Owner” nennen.

Der Plot-Owner ist auch die Person, die bei Zeitverzug entscheidet, wo der Plot gekürzt werden kann. Sind die Spieler partout nicht in der Lage, eine Aufgabe zu bewältigen, kann er auch die Aufgabe abändern, beispielsweise mit Hilfe von NSC eingreifen oder neue Informationen in die Menge streuen.

Sind die Spieler zu schnell, kann er auch zusätzliche Elemente in den Plot einbauen, um diesen spannend zu halten.

Backlogs und Prioritäten

Alles bislang Gesagte gehört natürlich eng zusammen: Damit eine LARP-Veranstaltung funktioniert, müssen alle Stories, aus denen der jeweilige Plot zusammengesetzt wird, innerhalb der vorhandenen Timebox “entwickelt”, also durchgespielt, werden. Dafür trägt der Plot Owner die Verantwortung.

Die Menge aller Stories, die zu einem Produkt gehören und noch entwickelt werden müssen, heißt Product Backlog. Analog dazu nenne ich die Menge aller Ereignisse, die noch stattfinden müssen, “Plot Backlog”. Der Herrscher über das Plot Backlog ist der Plot Owner. Niemand darf ohne sein Einverständnis weitere Stories in das Plot Backlog packen oder gar welche herausnehmen.

Einige Stories sind dabei möglicherweise wichtiger als andere. Dies kann der Plot Owner (und wiederum: nur er!) durch die Vergabe von Prioritäten ausdrücken. Eingebürgert haben sich zahlen zwischen 1 und 5, wobei grob gilt: 1-kritisch wichtig, 2-wichtig, 3-normal, 4-nicht so wichtig, 5-unwichtiges Sahnehäubchen.

“Die Spieler sollen den Erzdämon besiegen, um die Tochter des Königs zu befreien “ hätte beispielsweise Priorität 1. “Unter einem Stein am Wegesrand kann ein Heiltrank gefunden werden” hätte Priorität 5. Alles, was man nicht als wichtig oder unwichtig einstufen kann, erhält automatisch die Priorität 3-normal.

Zusätzlich hat der Plot Owner die Möglichkeit einer zeitlichen Priorisierung: Er sortiert dabei die Stories im Plot Backlog einfach in die Reihenfolge, in der er sie gerne umgesetzt haben möchte.

Sprints

Um eine genauere Kontrolle über den Verlauf der Entwicklung … Verzeihung … der Veranstaltung zu haben, wird der zur Verfügung stehende Zeitraum weiter unterteilt. Die dadurch gewonnenen Abschnitte nennt man Sprint. Während eines Sprints wird ein festgelegter Teil der vorhandenen Stories aus dem Plot Backlog umgesetzt.

Ein Sprint in der Software-Entwicklung dauert in der Regel zwei Wochen. Richtwert für eine Obergrenze sind vier Wochen, und manchmal wird auch nur eine Woche benutzt. Diese Grenzen können wir nicht verwenden, da die meisten LARP-Veranstaltungen kürzer sind. Für LARP-Veranstaltungen schlage ich Sprintlängen von sechs oder acht Stunden vor.

Zu jedem Sprint gehört eine Reihe von Besprechungen. Je länger der Zeitabschnitt ist, desto besser ist das Verhältnis zwischen produktiver Zeit und Zeit in Besprechungen. Je kürzer er ist, desto schneller kann man reagieren, falls etwas aus dem Ruder läuft.

Sprintplanung

Eine wichtige Besprechung im Rahmen eines Sprints ist die Sprintplanung. Diese findet am Anfang des Sprints statt. Der Plot Owner stellt hier zusammen mit dem Team das Sprint Backlog des aktuellen Sprints zusammen. Jeder Sprint hat ein eigenes Sprint Backlog. Darin enthalten sind alle Stories, die in diesem Sprint zu erledigen sind.

Um festzulegen, wie viele Stories in einem Sprint voraussichtlich machbar sind, hat sich in der Software-Entwicklung eine Schätzung in Story-Punkten bewährt.  Einige Teams arbeiten allerdings lieber auf Zeitbasis und schätzen die Stories auch in Zeitverbrauch pro Person ein. Beispielsweise: “Diese Story beansprucht die Entwickler 16 und den Tester 8 Stunden lang”. Dies ist die Methode, die ich auch für LARPs vorschlagen würde: “Diese Story beschäftigt 8 NSCs jeweils 3 Stunden” ist eine Größe, mit der jeder aus dem Stand arbeiten kann.

Dabei wird darauf geachtet, dass der Zeitbedarf der Stories im Sprint die verfügbare Zeit der Teammitglieder nicht überschreitet. Anders ausgedrückt: In 6 Stunden können wir maximal x NSC einsetzen, von denen jeder nur 6 Stunden übernehmen kann. Außerdem sind NSC in der Regel nicht oder nur unter starkem Protest teilbar, weshalb ein NSC zwar mehrere Aufgaben nacheinander, aber immer nur eine einzige Aufgabe gleichzeitig erledigen kann. Die Aufgaben im Sprint Backlog werden also so zusammengestellt, dass die NSC zwar möglichst effizient ausgelastet, aber nicht überlastet werden.

Hier wird der Sprint auch in Aufgaben zerlegt, siehe unten.

Normalerweise ist dies eine Aufgabe für das gesamte Entwicklungsteam. Im LARP-Einsatz schlage ich vor, dass die Sprintplanung von Plot Owner, NSC-Koordinatoren, Technikern und anderen Orga-Mitgliedern durchgeführt wird. Es bringt nichts, dafür die NSC aus ihren Aufgaben zu reißen.

Sprint Retrospective

Am Ende des Sprints findet ein kurzes “Retro” statt, in dem jeder Beteiligte sagen kann, was seiner Meinung nach gut und schlecht lief. Die meisten Retros laufen dabei nach einem vom Team festgelegten Moderationsschema ab und dauern nicht allzu lange.

Ergebnis des Retros sind Verbesserungsvorschläge, die direkt in die Planung und Durchführung der nächsten Sprints übernommen werden.

Regelmäßige kurze Retros sind auch im LARP sinnvoll, damit die Orga und der Plot Owner rechtzeitig über Probleme im Team informiert werden und diese möglichst noch auf der Veranstaltung selbst beseitigen können.

Sprint Review

In der Software-Entwicklung wird am Ende des Sprints dem Product Owner das Ergebnis präsentiert. Diese Besprechung lasse ich in der LARP-Methode fallen, denn der Plot Owner ist hier direkt involviert und hat das Ergebnis eh im Auge.

Wenn allerdings auf größeren Veranstaltungen mehrere Teams koordiniert werden müssen, kann es nützlich sein, diese Reviews zu benutzen, um seine Ergebnisse den anderen Teams vorzustellen.

Grooming

In den Groomings werden die Stories im Plot Backlog besprochen, offene Fragen geklärt, Herangehensweisen besprochen und Schätzungen für die Stories erstellt.

In der Software-Entwicklung ist dies eine Aufgabe für das gesamte Team. Im LARP schlage ich jedoch vor, dass diese Aufgabe vom Plot Owner und wenigen erfahrenen Teammitgliedern durchgeführt wird – es ist nicht nötig, die versammelten NSC alle sechs bis acht Stunden zusammenzutrommeln, um den genauen Ablauf der Stories zu besprechen.

Soviel Theorie – was bringt mir das jetzt?

Verzwickt wird ein Plot erst, wenn ein geplantes Event nicht rechtzeitig erreicht wird. Beispielsweise, wenn die Spieler nicht innerhalb der vorgesehenen Zeit in die Krypta eindringen, um dort herauszufinden, wie sie den grausamen Fürsten besiegen und die Tochter des guten Königs retten können. Denn in der Krypta braucht man acht Ritter-NSC, aber vier davon werden später schon am Hofe als Diener gebraucht.

Der entscheidende Punkt an der agilen Methode ist, dass auch Sprints eine Timebox sind. Kein Sprint wird verlängert, nur weil eine Story noch nicht abgeschlossen ist. Diese Story wird mit hoher Priorität in den nächsten Sprint gekippt. Dadurch fallen aber aus dem nächsten Sprint automatisch Stories niedrigerer Priorität heraus, denn sonst kommt der Sprint mit der Schätzung nicht hin.

Das heißt: Hier wird quasi schon automatisch einer Überlastung oder Doppelbelegung der Springer entgegengewirkt. Der Plot Owner kann im besten Fall auch rechtzeitig erkennen, welche Teile des Plots  nicht laufen, und für den nächsten Sprint weitere Stories oder Aufgaben vorsehen, beispielsweise einen irren Alten ins Rennen schicken, der zwischen seinem wirren Geseier Teile der Lösung eines Rätsels rausposaunt. Oder einen Wahrsager, der prophezeit, dass man nur noch bis Sonnenuntergang Zeit hätte, die Krypta zu durchsuchen, weil danach [schlimme Dinge hier einsetzen]. Dadurch, dass er diese Stories aber für den nächsten Sprint einplant, fällt gleichzeitig auch Personal für die ursprünglich geplanten Plot-Stories weg. Diese kann er nun entsprechend anpassen und so agil auf das Geschehen reagieren und dafür sorgen, dass wieder alles passt … oder zumindest passen müsste.

Ausblick

Dies war natürlich nur ein kurzer Abriss, was Euch im Laufe der Serie erwartet. Ich werde auf die einzelnen hier vorgestellten Konzepte natürlich im Detail eingehen, und auch noch einige Konzepte vorstellen, die hier aus Platzgründen noch keine Erwähnung fanden, wie beispielsweise das NSC-Board.

Ich würde mich freuen, wenn Ihr dabei bleibt.

Artikelbild: Kristina Schlemmer