Das Scrum-Projekt-Planspiel 2018 – Teil 2: Die Vorbereitung

Blog – Technik und Methoden
Verfasst von Christian Seedig am 29. Mai 2018

In der Woche vor dem Projektstart wurde das Planspiel von den Coaches, den Trainern und den teilnehmenden Product Ownern und Scrum Mastern vorbereitet, um die Anforderungen an die Produkte und die Rahmenbedingungen für die Projekte festzulegen.

Das Projekt beginnt

Das Projekt startete mit der Einteilung der Teams und einer kurzen Einführung in die jeweils zu entwickelnden Applikationen. Nach Monaten theoretischen Unterrichts standen die Umschüler dem unbekanntes Projekt-Planspiel zunächst verhalten begeistert gegenüber: In den Gesichtern jedenfalls konnte man Skepsis, Neugierde, Vorfreude und leichte Abneigung gegenüber dem Experiment finden. Diese Gefühlsmischung harmonisierte sich später im postitiven Sinne.

Scrum Master und Product Owner brachten den Teams als nächstes die theoretischen Grundlagen von Agilität und Scrum sowie die Bedeutung von Backlog, User Stories, Produktvision und Co. näher. Und zwar mit agilen Methoden, deren Konzepte Scrum Master und Product Owner selbst ausgearbeitet (und dabei schon etwas gelernt!) hatten.

Die Teams mussten beispielsweise die Agilen Werte und den Scrum Flow, den sie vor einigen Monaten im Unterricht bereits kennengelernt hatten, selbstständig erneut mit Leben füllen. Die dabei gemachten Fehler führten zu ausgeprägten Diskussionen untereinander und auch mit den Scrum Mastern und Product Owner. Ergebnis: Es leuchtete allen viel besser ein, als nach einer klassischen Theoriestunde.

Teambuilding

Obwohl alle Teammitglieder sich schon aus der gemeinsamen Ausbildungsklasse kannten, hatten sie noch nie als Entwicklerteam in einem Scrum Umfeld zusammengearbeitet. Arbeit im Team ist keine evolutionär geprägte Fähigkeit (leider), kann aber erlernt werden. Die Scrum Master und Product Owner in unserem Projekt hatten zwei Tage Zeit, um sich und ihren Teams einen möglichst guten Start zu ermöglichen und die ersten Pflöcke für die spätere Entwicklungsarbeit einzuschlagen. Ein Team zu formen, das produktiv zusammenarbeiten kann und sich dabei gegenseitig ergänzt und unterstützt, war nun die Herausforderung für die ScrumMaster. Und sie benutzten das mächtigste Tool im Teambildungs-Prozess ein: Spaß!

Erst einmal: Kennenlernen

Der Kreativität waren keine Grenzen gesetzt: Anstelle von „Ball werfen“ oder „Jeder stellt seinen linken Nachbarn vor“ wurden „Social Media Steckbriefe“ erstellt, „Walk of Fames“ produziert, “Candy Love“ gespielt oder „Was ihr sicher nicht über mich wusstet – Käfer“ verwendet, um allen auch privatere Informationen zu entlocken. Es ist erstaunlich, was man, obwohl man schon so viel über seine Kollegen weiß, alles noch nicht weiß. Viele neu entdeckte Gemeinsamkeiten fördern Vertrauen und schaffen eine neue Kommunikationsbasis.

Weiter geht es: Wir fokussieren ein gemeinsames Ziel – und erreichen es

IT-Bildungshaus Scrum Projekt Planspiel

Papierflieger Basteln

Diese Teambuilding-Spiele haben einen pädagogisch ausgereiften Hintergrund, das schon mal vornweg. Während zwei Teams eine Stadtrallye durch Bremen machten und nur im Team zu lösende Aufgaben lösten, wurden andernorts große Mengen an Papierfliegern mit dem Scrum-Rahmenwerk hergestellt, getestet und von Sprint zu Sprint die Produktion verbessert.

Bei dem Mobilitätsmachern wurden getreu dem Teamnamen Flugmaschinen für Eier hergestellt, um, (als Ei) aus unterschiedlichen Höhen geworfen, unbeschadet anzukommen. Das Material war streng limitiert auf ein paar Strohhalme, etwas Papier und Klebeband. Alle hatten überraschend gute Ideen, um das Ziel zu erreichen, und viel Spaß an dieser Art zu arbeiten. Alles das kann ihnen in ihrer späteren Arbeit als Software-Entwickler in einem agilen Team nützen.

Es wird ernst: Theoretische Praxis am Nachmittag

Mit der Erstellung einer Definition of Ready (DoR) und einer Definition of Done (DoD) geht die Entwicklerarbeit schon richtig ins Detail – wenn sie korrekt erstellt werden. Hier legten die Teams individuell für sich fest, wann eine User-Story fertig für die Bearbeitung ist und was das Team gemeinsam alles erledigen muss, um diese zur Zufriedenheit des Product Owners und der Anwender Ihrer Lösung als „Fertig“ zu definieren. Insbesondere bei der DoD wurde den Entwicklern schnell bewusst, dass Aspekte wie die Bedeutung einer gemeinsamen Code-Ownership, Qualitätssicherung durch Testautomatisierung und das gemeinsame Arbeiten an einer Funktion im Pair Programming wichtig sind wenn man die Definition von „wirklich Fertig“ erstellen möchte.

Enspurt: Fast fertig mit der Planung

In den meisten Teams wurde auch noch ein Backlog Refinement durchgeführt. Dabei lernten die Teilnehmer, wie im agilen Arbeiten über Story Points nicht der Aufwand einer Funktion, sondern die Komplexität geschätzt wird und was eigentlich genau Komplexität ist. Durch das folgende Sprint-Planning wurde dann der Startschuss gegeben für die tatsächliche Umsetzung der geforderten Funktionen im kommenden Sprint. Obwohl noch keinerlei Erfahrungen vorlagen, wie leistungsfähig das Team wirklich ist und wie viele Story Points sie in einem Sprint fertigstellen können, wurde ein Forecast abgegeben: das Team schätzt, was es gemäß seiner eigenen DoD fertigstellen kann. Wie gut das geklappt hat, steht im nächsten Teil der Blog-Reihe.

Aus dem Trainingslager für Scrum Master und Product Owner

Auch für unsere HEC Scrum Master und Product Owner, die sich in dem Projekt beweisen dürfen, war bereits die eigenständige  Vorbereitung und Durchführung der ersten Tage lehrreich. Dabei konnten sie im eigenen Team erleben, wie schwierig es ist, einen trockenen Stoff wie den Scrum Prozess anschaulich in einem Workshop-Format nachhaltig zu vermitteln. Es ist ja nicht sicher,  ob die gewählte Methode bei den Teilnehmern gut ankommen wird und alle aktiv mitarbeiten. Glücklicherweise haben alle Umschüler sehr gut auf das interaktive Format angesprochen. Bei dieser Vorbereitung wurde schnell klar, wie viel Mehrwert es bietet, die Ideen kurz im kleineren Team mit anderen Scrum Mastern und Product Owner zu diskutieren. So entstand gemeinsam ein Konzept,  das von allen mit getragen wird.

Das Team der HEC Scrum Master und Product Owner hat sich bereits jetzt zu einem eigenen Netzwerk zusammengefunden welches sich selbst organisiert, gegenseitig ergänzt und unterstützt. In diesem Netzwerk wurden schnell diverse Quellen gefunden und geteilt, aus denen man Ideen für die Teambildungsspiele ziehen kann. Davon können natürlich auch die bereits etablierten Agilen Berater der HEC in Zukunft profitieren.

Das positive Feedback der Teams nach den ersten Tagen war natürlich für alle Scrum Master und Product Owner ein wohlverdienter Lohn und tolle Entschädigung für die Anstrengungen der Ausarbeitung der ersten Tage.