agil beim b2run

Team agido beim b2run in Dortmund

Team agido beim b2run Firmenlauf in Dortmund

Es ist Januar 2014 und unser Projekt ist die Teilnahme am B2Run Dortmund. Wir wollen mitlaufen!

Unser Product Backlog enthält folgendes Epic:

  • Wir möchten als Mannschaft beim Dortmunder B2Run teilnehmen. Dieses Epic teilt sich in verschiedene User Stories:
  • Ich als Läufer hätte gern ein Team­Shirt, weil wir eine Mannschaft sind und dies nach außen zeigen wollen.
  • Ich als Mitarbeiter und Läufer würde mich über ein Sponsoring des Startgeldes freuen, weil es seitens der Firma eine Wertschätzung zeigt.
  • Ich als Chef erhoffe mir, dass meine Mitarbeiter sich vorbereiten und Spaß an der Veranstaltung haben.
  • Ich als Chef erwarte, dass sich das Lauf­Team selbst organisiert und um alles Relevante kümmert.

Nun muss sich unser Scrum­Team finden. Zunächst findet sich der Product Owner in Form von Thomas und das Anfangsscrum­Team bestehend aus Angi und Marco. Thomas findet die Zielvorgabe ansprechend und Angi und Marco begeistern sich enthusiastisch für das Projekt. So bestand ihre erste Aufgabe darin, das Epic wie oben angegeben in User Stories zu zerlegen.

Das Sprint Planning Meeting 1 findet papierlos und virtuell statt und ist auch zeitlich recht anspruchslos. Die zentralen Scrum­Fragen können schnell geklärt werden:

  • Was kann im kommenden Sprint entwickelt werden?
    a) Wir streben ein Sponsoring für den Lauf an.
    b) Wir streben Team-Shirts für den Lauf an.

  • Wie wird die Arbeit im kommenden Sprint erledigt?

    a) Wir müssen unseren Chef davon überzeugen, dass es sich lohnt.

    b) Gibt es jemanden, der uns Team-Shirts sponsorn würde?

Im Sprint Review 1 wird festgestellt, dass Angi das Gespräch mit dem Chef suchte und ihn sehr leicht vom Projekt „B2Run“ überzeugen konnte. Er gesteht uns sofort das Startgeld zu und steht auch der Firmenwerbung und Mannschaftsbildung mittels Team-Shirts sehr aufgeschlossen gegenüber.

Da alles positiv lief, konnten wir recht schnell zum Sprint Planning Meeting 2 kommen:

  • Was kann im kommenden Sprint entwickelt werden?

    a) Die Teilnehmer für den Lauf müssen bis Ende März feststehen.
    
b) Entwurf von Team-Shirts und Beauftragung derselben.

  • Wie wird die Arbeit im kommenden Sprint erledigt?

    a) Wir müssen nun ein Entwicklungsteam zusammen stellen/sich finden lassen, das den Anforderungen gewachsen ist und ein gutes Ergebnis liefern kann.
    
b) Wir müssen das Management beauftragen, Shirts zu entwerfen und dann dar­über abstimmen.
Es bildet sich unser Entwicklungsteam: Simon, Marvin, Mathis, Jens, Rafael, Marco, Felix, Angi.

Da das Entwicklungsteam keine Einwände hat, wird Angi zum Scrum-Master. Sie soll alle notwendigen administrativen Aufgaben erledigen bzw. delegieren, um dem Entwicklungs­team den Rücken frei zu halten.

Unser Management stellt sich in Form von Amke dar. Sie sorgt für die Materialien: unsere Laufshirts inkl. Druck, Zahlung von Rechnungen, Verbreitung von guter Laune.

Der Sprint Review 2 ergibt, dass alles gut läuft. Wir haben ein Entwicklungsteam, Shirt-Entwürfe und alle Ter­mine gehalten. Die Kommunikation könnte jedoch etwas üppiger ausfallen.

Damit können wir zum Sprint Planning Meeting 3 kommen. Es wird nun konkreter.

  • Was kann im kommenden Sprint entwickelt werden?

    a) Lauftechnische Vorbereitung

    b) Abholung der Startunterlagen

  • Wie wird die Arbeit im kommenden Sprint erledigt?
    
a) Jeder arbeitet an sich selbst
    
b) Erledigt der Scrum-Master

Unser Entwicklungsteam ist hervorragend selbst organisiert. Jeder arbeitet an seiner per­sönlichen Fitness, motiviert die anderen etc. Zum vereinbarten Termin kann der Scrum­-Master die Startunterlagen abholen und das Entwicklungsteam per Mail über alle Rand­bedingungen des Laufs informieren.

Das Burndown Chart liegt voll in der Zeit, alles im grünen Bereich.

Der Sprint Review 3 findet knapp eine Woche vor dem Lauf statt. Wir können feststellen, dass alle motiviert sind, der Product Owner wurde über den Verlauf des Projektes infor­miert, alle Termine konnten gehalten werden.

Sprint Planning Meeting 4 sollte nun das letzte vor der endgültigen Fertigstellung sein. Es gab nur noch erfreulich wenig offene Punkte, die mit einer kurzen Fertigstellungszeit geschätzt wurden.

  • Was kann im kommenden Sprint entwickelt werden?
    
a) Lauftechnische Vorbereitung in der letzten Phase

    b) Organisation der Anfahrt

    c) Auslieferung im Startblock

  • Wie wird die Arbeit im kommenden Sprint erledigt?
    
a) Jeder arbeitet an sich selbst
    
b) Planung durch den Scrum-Master
    
c) Gemeinsame Anfahrt, Aufstellung im Startblock

Dieser letzte Sprint hatte nun doch noch einige Überraschungen für uns. Nachdem zu­nächst alles sehr gut gelaufen ist, wurde die Frage der Anfahrtsorganisation kommunikati­onstechnisch nicht ausreichend durchgeführt. Der Scrum-Master hatte auf seinen Vor­schlag, den ÖPNV zu nutzen, keinen Widerspruch erhalten. Er erschien zum verabredeten Zeitpunkt, um das Entwicklungsteam in die nächste Phase begleiten zu können. Hier stell­ten sich jetzt jedoch 2 unerwartete Probleme in den Weg, die eine Intervention seitens des Scrum-Masters notwendig machten:

  1. Die Startunterlagen waren nicht bei jedem vollständig vorhanden.
  2. Die Anreise eines Teammitgliedes verzögerte sich wegen Stau auf der A40.

Wir wären ein schlechtes Team, wenn uns das aus der Bahn geworfen hätte. Der Scrum­-Master übergab einem Teammitglied die Vor-Ort-Organisation und machte sich mit einem Teil des Entwicklungsteams auf den Weg, die vergessenen Startunterlagen abzuholen. Das verbliebene Team plante nach kurzer Besprechung um und fuhr statt mit dem ÖPNV doch lieber mit dem Auto. Damit konnte dieses Team seine Aufgabe deutlich schneller als geplant erledi­gen. Die verzögerte Anreise des letzten Teammitgliedes war ihnen jedoch entgangen, weil der Scrum-Master die Liste aller Teilnehmer nicht ausreichend kommuniziert hatte. Jedoch war dieses Teammitglied so gut organisiert, dass es sich mit seinem Problem an den Scrum-Master wandte, der wiederum schnell einen Ausweg aus der Misere fand. Der Scrum-Master beauftragte seine mit ihm durch Dortmund irrenden Teammitglieder mit dem anderen Teil des Teams Kontakt zu halten, damit man das Endziel „Gemeinsame Auslieferung im Startblock“ halten könne. Die ausgiebige und gute Kommunikation sowie Eigeninitiative und hervorragende Ideen der Teammitglieder führten dazu, dass sich die einzelnen, mittlerweile verstreuten Teams nach und nach wieder fanden und man pünktlich und vollzählig ausliefern konnte.

Der letzte Sprint-Review zeigte uns die „lessons learned“ auf: Startunterlagen verbleiben bis zur letzten Minute beim Scrum-Master und werden erst ausgeteilt, wenn sie benötigt werden. Außerdem müssen bei Aufteilungen Teilnehmerlisten ausgegeben werden, damit keiner vergessen wird.

Das Projektziel wurde erreicht: Das Produkt lief gut und bestand den Lasttest mit 02:48:19 Stunden bzw. 00:33:48 Stunden. Die einzelnen Produkt-Featu­res konnten sich ebenfalls im Test positiv ausmachen:

Auf Grund unserer Erfahrung haben wir uns zunächst für ein weiteres ähnliches Projekt bewor­ben, den A(m)OK Lauf rund um den Phoenixsee. Hierfür haben wir unser Entwicklungs­team leicht geändert, setzen aber auf die Erfahrung der Teammitglieder, die bereits beim B2Run-Projekt eingesetzt wurden.