Geschätzte Lesezeit: 8 Minuten

Der Rundgang durch die Übertragung agiler Methoden auf LARPs nähert sich seinem Ende. Im sechsten und letzten Sprint der Serie „Agiles Plotmanagement“ geht es um die Planungstreffen. Wie laufen diese normalerweise ab? Wie überträgt man diese aufs LARP? Was kann man optimieren? Und vor allem: Wie hält man sie kurz?

Die regelmäßigen Zusammenkünfte der Team-Mitglieder sind für die agile Software-Entwicklung von zentraler Bedeutung. Viele dieser Treffen sind stark formalisiert, um die verfügbare Zeit möglichst effizient zu nutzen.

Die effiziente Nutzung der vorhandenen Zeit ist natürlich auch für den Einsatz im LARP wichtig, oder besser: gerade hier, wo wir die agilen Techniken auf stark verkürzte Zeiträume anwenden.

Das Grooming

Im Backlog Grooming, kurz Grooming, manchmal auch Backlog Refinement genannt, wird das Product Backlog aktualisiert. Das heißt: Hier werden User Stories vorgestellt und hinzugefügt und nicht mehr benötigte Stories aus dem Product Backlog entfernt.

Hier werden die User Stories auch im Team besprochen und ihre Umsetzbarkeit diskutiert. Eine User Story kann dabei durchaus in mehr als einem Grooming besprochen werden, wenn zwischenzeitlich noch Informationen eingeholt oder Dinge geprüft werden müssen.

Wenn allen Beteiligten klar ist, worum es in der Story geht und wie diese umgesetzt werden soll, kann der Zeitaufwand für eine Story geschätzt werden. In der Software-Entwicklung werden dazu je nach Team unterschiedliche Systeme benutzt.

Sobald die Story geschätzt ist, kann sie in folgenden Sprintplanungen berücksichtigt werden.

Adaption für LARPs

„Richtige“ Groomings sind im LARP-Kontext ein enormer Overhead. Jedes Mal das komplette Team zusammenzurufen, ist einfach nicht praktikabel.

Stattdessen sollte der Plot Owner die meisten Stories selbst ausarbeiten. Dazu kann er gegebenenfalls Gespräche im kleinen Kreis führen, um Detailfragen mit den jeweils Verantwortlichen zu klären. Beispielsweise bietet sich ein Gespräch mit dem Techniker an, wenn es um die Machbarkeit eines bestimmten Effektes geht.

Nach einigen inzwischen entstandenen Erfahrungsberichten kristallisiert sich heraus, dass der Plot Owner auch die Schätzungen alleine durchführen sollte. Bei Themen, die er selbst schlecht einschätzen kann, kann er sich natürlich die Hilfe der zuständigen Teamkollegen holen. Bei der Technik-Frage aus dem oberen Beispiel wäre das angebracht. Ein anderes Beispiel sind logistische Dinge – wie lange dauert es, Einkaufen zu fahren oder große Teile von Kulisse X von A nach B zu bewegen?

Wie bereits am Anfang der Reihe beschrieben, ist die einfachste Schätzmethode für LARP-Umsetzung die Einschätzung der real benötigten Personenstunden.

Optimierung?

Indem der Plot Owner diese Planungen komplett übernimmt, und nur bei Bedarf weitere Personen hinzuzieht, findet dieses Meeting bei der LARP-Adaption so gut wie nie statt – kürzer geht es nicht.

Sprintplanung

In der Sprintplanung wird entschieden, welche User Stories in den aktuellen Sprint Einzug finden.

Der Product Owner kann prinzipiell beliebige User Stories in den Sprint zuweisen. In der Regel werden aber nur User Stories aufgenommen, die bereits das Grooming durchlaufen haben und eingeschätzt sind.

Was soll im nächsten Sprint erreicht werden?

Die User Stories im Product Backlog sollten schon nach Priorität geordnet sein. Im Gespräch mit dem Team wird jetzt ein letztes Mal die Priorität und die Machbarkeit durchgesprochen, dann werden die User Stories ins Sprint Backlog des kommenden Sprints verschoben – und zwar so, dass im Sprint nicht mehr User Stories zu bearbeiten sind, als das Team in der gegebenen Zeit voraussichtlich bearbeiten kann.

Des Weiteren sollte sich das Team hier klar werden, wie das Gesamt-Produkt am Ende des Sprints aussehen soll, und dies in einer „Definition of Done“ festlegen. (Es reicht allerdings meistens, dies nur einmal zu tun und die festgelegte Definition auf jeden Sprint anzuwenden.)

Wie sollen diese Ziele erreicht werden?

„Traditionell“, wenn man hier schon von einer Tradition sprechen kann, findet nach der Festlegung des Sprint Backlogs die sogenannte Work Breakdown Session statt. Hier werden für jede User Story im Sprint Backlog die dazugehörigen Einzelaufgaben formuliert.

Optimierung?

Einige Teams bevorzugen, die beiden Planungsteile zu vermischen und jede User Story, die ins Sprint Backlog gezogen wird, sofort in ihre Tasks zu zerlegen. Dies zieht die Planung der zu bearbeitenden User Stories in die Länge, kann aber trotzdem von Vorteil sein, da man beim Breakdown vielleicht Aufgaben entdeckt, die den Aufwand der User Story quasi in letzter Sekunde doch noch in die Höhe schnellen lassen.

Adaption für LARPs

Während der Plot Owner die Groomings im LARP zum größten Teil alleine durchführen kann, sollten bei der Sprintplanung weitere Teammitglieder anwesend sein. Es ist aber nicht notwendig, jedes Mal alle Orga-Mitglieder, Spielleiter und NSC zusammenzurufen.

Stattdessen ist es am besten, für jedes Betätigungsfeld einen Experten anwesend zu haben – also beispielsweise jemanden aus dem SL-Team, jemanden aus der NSC-Koordination, jemanden von der Technik etc. Dabei können bei kleineren Cons durchaus mehrere Rollen von der gleichen Person übernommen werden.

Sprint Review

In der Software-Entwicklung wird am Ende des Sprints überprüft, ob das Sprintziel erreicht wurde. Es wird zum einen geprüft, ob das Produkt dem entspricht, was in der Sprintplanung festgelegt wurde. Zum anderen wird überprüft, welche User Stories vollständig abgeschlossen wurden.

Hier wird der neue Stand des Produktes in der Regel auch dem Auftraggeber präsentiert, sei es nun ein Kunde oder die nächsthöhere Instanz in der eigenen Firma. Kommentare und Feedback werden gesammelt und für die Planung weiterer Sprints aufgehoben.

User Stories, die nicht komplett abgeschlossen wurden, wandern zurück in das Product Backlog, da die Rest-Arbeit in folgenden Sprints eingeplant werden muss. Des Weiteren kann auf Basis der Gesamtzahl der bearbeiteten User Stories die Velocity des Teams aktualisiert werden, welche angibt, wie viel das Team in einem Sprint in der Regel schafft.

Anpassung ans LARP

Im LARP werden die Stories quasi permanent den Kunden präsentiert, da sie zusammen mit den Spielern durchgespielt werden. Eine Präsentation der Ergebnisse gegenüber den Spielern kann also entfallen.

Trotzdem ist es durchaus sinnvoll, sich am Ende eines Sprints mit den gleichen Personen zu treffen, mit denen man den Sprint geplant hat, um kurz zu besprechen, wie gut sich die Planung umsetzen ließ.

Was auch entfallen sollte, ist die Einbeziehung von erhaltenem Feedback. Wenn das Team mitbekommen hat, dass den Spielern bestimmte Stories besonders gut oder besonders schlecht gefallen haben, wird diese Kritik hier noch einmal gesammelt vorgebracht und kann für den weiteren Verlauf der Veranstaltung eingeplant werden.

Sprint Retrospektive

Am Ende jedes Sprints findet in der Software-Entwicklung meist noch ein weiteres, teaminternes Treffen statt. Hier bewerten die Mitglieder des Teams ihre eigene Leistung und zeigen auf, was ihnen im Sprint gefallen hat und was nicht.

Diese „Retros“ sind in der Regel stark formalisiert und bestehen aus einer moderierten Feedback-Runde, in der jeder Beteiligte seine Meinung sagen darf. Darauf erfolgt eine, ebenfalls moderierte, Besprechung der wichtigsten Punkte. Alle Punkte können in der Regel nicht besprochen werden, da auch dieses Treffen zeitlich begrenzt ist.

Am Ende des Retros stehen Maßnahmen, die im nächsten Sprint zu Verbesserungen führen sollen. Dies sind Änderungen an der Arbeitsweise des Teams, beispielsweise „Ausführlichere Task-Karten schreiben“.

Am Anfang des nächsten Retros kann geprüft werden, welche dieser Maßnahmen durchgeführt wurden, welche zum Erfolg führten, und welche sich als unpraktisch erwiesen haben und neu diskutiert werden müssen.

Das Retro-Treffen dient also dem Verbessern der Arbeitsweise des Teams, nicht der Verbesserung des Produktes. Normalerweise wird die Arbeitsweise des Teams nur vom Team selbst beeinflusst, nicht vom Kunden.

Adaption für LARPs

Da schon das Sprint-Review ohne „Kunden“ stattfindet, können im LARP Review und Retro zusammengelegt werden – dadurch wird  eines der beiden Treffen eingespart und verbraucht keine Zeit mehr.

Natürlich findet auch dieses Treffen nicht mit dem gesamten Orga-Team statt, sondern bestenfalls mit den gleichen ausgewählten Mitgliedern, die auch schon bei der Sprintplanung mit dabei waren.

In diesem Fall kann auch das Feedback durch die Spieler die Arbeitsweise des Teams beeinflussen.

Haben wir nicht ein Meeting vergessen?

Ja. Das wichtigste Meeting, was auch Namensgeber dieser Methode wurde, wurde bewusst ausgelassen:

Der Daily Scrum.

Die Team-Mitglieder in einer agilen Software-Entwicklung treffen sich in der Regel einmal am Tag für eine Viertelstunde, um sich gegenseitig auf den neusten Stand zu bringen. Jeder im Team erzählt dabei kurz, was er seit dem letzten Treffen bearbeitet hat, was er als nächstes bearbeiten wird und welche Hindernisse ihm dabei möglicherweise im Weg stehen.

Adaption für LARPs

Im LARP ergibt eine Adaption des Daily Scrums keinen Sinn. Da die Sprints hier nicht Wochen laufen, sondern nur Stunden, müssten diese Treffen nahezu andauernd abgehalten werden – das ist nicht praktikabel und auch nicht notwendig.

Aus einem anderen Blickwinkel kann man auch die Kombination aus Review und Retro als Scrum-Meeting betrachten.

Ende

Das war er, der Rundgang durch einige Methoden der agilen Software-Entwicklung in Hinblick auf deren Verwendbarkeit für die Organisation von Live-Rollenspielen. Viele der beschriebenen Ideen wurden inzwischen in der Praxis getestet, und viel praktisches Feedback ist in die Artikelserie eingeflossen.

Wenn Ihr ein LARP mit diesen Methoden organisiert habt, oder Euch aus der Serie Inspirationen für Eure eigenen Methoden geholt habt, würde ich mich freuen, davon zu lesen.

Artikelbild: Kristina Schlemmer

LARP-Basar, das Einkaufsportal für Liverollenspieler im Internet

2 Kommentare

  1. Die Idee den Plot als Scrum Projekt laufen zu lassen finde ich nach wie vor befremdend. Möglicherweise ist die Assoziation mit meiner Arbeit als ScrumMaster und Developer einfach zu stark. Ich hege ausserdem die Befürchtung das diese Form des Agiles Plot-Management die Möglichkeit zur Improvisation vernichtet und der Plot am Schluss vom ScrumBord und nicht mehr von den Spielern bestimmt wird.
    Das Ganze hat mich aber auf die Idee gebracht Scrum in der Organisation zu verwenden. Bedenkt man die verschiedenen Aufgaben denen sich die Orga gegenüber sieht, glaube ich dort den besseren Anwendungsfall zu erkennen.

  2. Hmm, die auslösende Überlegung hinter der ganzen Serie war ja eigentlich, die Improvisations-Kapazität der Orga zu erhöhen. Also … die Planungsabstände zu verkleinern, und in den Iterationen die Geschichte mit den Spielern zusammen zu entwickeln — und wenn die Spieler in eine völlig andere Richtung laufen, dann im Extremfall (und wenn der Fundus das hergibt) auch auf einen völlig anderen Plot schwenken zu können.

    Ich sehe das Scrum-Board da als Chance, nicht als Hindernis, weil es der Orga ermöglicht, frei zu improvisieren. Das Board sorgt bei der Orga ja nur dafür, daß die NSC nicht doppelt aufgestellt oder anderweitig überlastet werden.

Kommentieren Sie den Artikel

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein