Das Scrum-Projekt Planspiel 2018

HEC Blog: Technik & Methoden
Verfasst von Christian Seedig am 29. Mai 2018

In der Woche vor dem Projekt­start wurde das Plan­spiel von den Coaches, den Trai­nern und den teil­neh­men­den Product Ownern und Scrum Mastern vorbe­rei­tet, um die Anfor­de­run­gen an die Produkte und die Rahmen­be­din­gun­gen für die Projekte fest­zu­le­gen.

Das Projekt beginnt

Das Projekt star­tete mit der Eintei­lung der Teams und einer kurzen Einfüh­rung in die jeweils zu entwi­ckeln­den Appli­ka­tio­nen. Nach Mona­ten theo­re­ti­schen Unter­richts stan­den die Umschü­ler dem unbe­kann­tes Projekt-Plan­spiel zunächst verhal­ten begeis­tert gegen­über: In den Gesich­tern jeden­falls konnte man Skep­sis, Neugierde, Vorfreude und leichte Abnei­gung gegen­über dem Expe­ri­ment finden. Diese Gefühls­mi­schung harmo­ni­sierte sich später im posti­ti­ven Sinne.

Scrum Master und Product Owner brach­ten den Teams als nächs­tes die theo­re­ti­schen 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 muss­ten beispiels­weise die Agilen Werte und den Scrum Flow, den sie vor eini­gen Mona­ten im Unter­richt bereits kennen­ge­lernt hatten, selbst­stän­dig erneut mit Leben füllen. Die dabei gemach­ten Fehler führ­ten zu ausge­präg­ten Diskus­sio­nen unter­ein­an­der und auch mit den Scrum Mastern und Product Owner. Ergeb­nis: Es leuch­tete allen viel besser ein, als nach einer klas­si­schen Theo­rie­stunde.

Teambuilding

Obwohl alle Team­mit­glie­der sich schon aus der gemein­sa­men Ausbil­dungs­klasse kann­ten, hatten sie noch nie als Entwick­ler­team in einem Scrum Umfeld zusam­men­ge­ar­bei­tet. Arbeit im Team ist keine evolu­tio­när geprägte Fähig­keit (leider), kann aber erlernt werden. Die Scrum Master und Product Owner in unse­rem Projekt hatten zwei Tage Zeit, um sich und ihren Teams einen möglichst guten Start zu ermög­li­chen und die ersten Pflö­cke für die spätere Entwick­lungs­ar­beit einzu­schla­gen. Ein Team zu formen, das produk­tiv zusam­men­ar­bei­ten kann und sich dabei gegen­sei­tig ergänzt und unter­stützt, war nun die Heraus­for­de­rung für die ScrumMas­ter. Und sie benutz­ten das mäch­tigste Tool im Team­bil­dungs-Prozess ein: Spaß!

Erst einmal: Kennenlernen

Der Krea­ti­vi­tät waren keine Gren­zen gesetzt: Anstelle von „Ball werfen“ oder „Jeder stellt seinen linken Nach­barn vor“ wurden „Social Media Steck­briefe“ erstellt, „Walk of Fames“ produ­ziert, “Candy Love“ gespielt oder „Was ihr sicher nicht über mich wuss­tet – Käfer“ verwen­det, um allen auch priva­tere Infor­ma­tio­nen zu entlo­cken. Es ist erstaun­lich, was man, obwohl man schon so viel über seine Kolle­gen weiß, alles noch nicht weiß. Viele neu entdeckte Gemein­sam­kei­ten fördern Vertrauen und schaf­fen eine neue Kommu­ni­ka­ti­ons­ba­sis.

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

Diese Team­buil­ding-Spiele haben einen pädago­gisch ausge­reif­ten Hinter­grund, das schon mal vorn­weg. Während zwei Teams eine Stadtral­lye durch Bremen mach­ten und nur im Team zu lösende Aufga­ben lösten, wurden andern­orts große Mengen an Papier­flie­gern mit dem Scrum-Rahmen­werk herge­stellt, getes­tet und von Sprint zu Sprint die Produk­tion verbes­sert.

Bei dem Mobi­li­täts­ma­chern wurden getreu dem Teamna­men Flug­ma­schi­nen für Eier herge­stellt, um, (als Ei) aus unter­schied­li­chen Höhen gewor­fen, unbe­scha­det anzu­kom­men. Das Mate­rial war streng limi­tiert auf ein paar Stroh­halme, etwas Papier und Klebe­band. Alle hatten über­ra­schend gute Ideen, um das Ziel zu errei­chen, und viel Spaß an dieser Art zu arbei­ten. Alles das kann ihnen in ihrer späte­ren Arbeit als Soft­ware-Entwick­ler in einem agilen Team nützen.

Es wird ernst: Theoretische Praxis am Nachmittag

Mit der Erstel­lung 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 meis­ten 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 bewei­sen dürfen, war bereits die eigen­stän­dige  Vorbe­rei­tung und Durch­füh­rung der ersten Tage lehr­reich. Dabei konn­ten sie im eige­nen Team erle­ben, wie schwie­rig es ist, einen trockenen Stoff wie den Scrum Prozess anschau­lich in einem Work­shop-Format nach­hal­tig zu vermit­teln. Es ist ja nicht sicher,  ob die gewählte Methode bei den Teil­neh­mern gut ankom­men wird und alle aktiv mitar­bei­ten. Glück­li­cher­weise haben alle Umschü­ler sehr gut auf das inter­ak­tive Format ange­spro­chen. Bei dieser Vorbe­rei­tung wurde schnell klar, wie viel Mehr­wert es bietet, die Ideen kurz im klei­ne­ren Team mit ande­ren Scrum Mastern und Product Owner zu disku­tie­ren. So entstand gemein­sam ein Konzept,  das von allen mit getra­gen wird.

Das Team der HEC Scrum Master und Product Owner hat sich bereits jetzt zu einem eige­nen Netz­werk zusam­men­ge­fun­den welches sich selbst orga­ni­siert, gegen­sei­tig ergänzt und unter­stützt. In diesem Netz­werk wurden schnell diverse Quel­len gefun­den und geteilt, aus denen man Ideen für die Team­bil­dungs­spiele ziehen kann. Davon können natür­lich auch die bereits etablier­ten Agilen Bera­ter der HEC in Zukunft profi­tie­ren.

Das posi­tive Feed­back der Teams nach den ersten Tagen war natür­lich für alle Scrum Master und Product Owner ein wohl­ver­dien­ter Lohn und tolle Entschä­di­gung für die Anstren­gun­gen der Ausar­bei­tung der ersten Tage.