OK ... das ist das Atrium des Bürogebäudes wo das Training war. Teile des Trainings waren Übungen für die vier Teams erstellt wurden. Für die Übungen würden wir als Team herkommen, jedes Team hat sich um einen Tisch gesetzt, und wir haben die Aufgaben erledigt. Im Prinzip wurden einige Übungen gemacht, um die in Theorie erlernten Prizipien in der wirklichen Arbeit zu demonstrieren. Z.B. ...

Doggy Daycare

Wir mussten als Team eine Werbebroschüre für ein "Hotel für Hunde" erstellen. Dabei ging es darum das Prinzip der Selbstorganisation im Team zu demonstrieren mit kurzen Iterationen und dem was man in Scrum "inspect and adapt" nennt. Ich erwähne das weil ... ihr könnt euch vorstellen wie sehr ich mich mit dem Produkt Hundehotel identifizieren konnte. :-) Es sollte mit dieser Übung gezeigt werden, dass Scrum eine Management Framework ist, dass man auf jede Aufgabe anwenden kann, nicht nur auf die Programmierung von Software.

Estimation Poker

Eine hochinteressante Art der Aufwandsabschätzung. Man listet alle Aufgaben die man zu erledigen hat. Man einigt sich darauf welche die einfachste ist, und man bezeichnet diese mit Aufwand 1. Jedes Teammitglied hält Karten in der Hand mit den ersten Zahlen der Fibonacci Reihe (1, 2, 3, 5, 8, 13, 21, usw. ... wir haben nur bis 13 verwendet). Dann tut man der Reihe nach die Aufgaben die geschätzt werden müssen ansehen, jeder überlegt kurz, und spielt seine Karte. Die gespielte Karte gibt die Einschätzung des Aufwandes in Relation zu 1 ... also ... wenn ich eine 3 spiele, so sage ich damit "ich glaube man braucht dafür 3x so lange wie für die Aufgabe die wir mit 1 bemessen haben". Wenn es im Team grosse Diskrepanzen in der Schätzung gibt haben die, die nach oben oder unten abweichen, jeweils 60 Sekunden Zeit zu argumentieren warum sie das so schätzen wie sie schätzen, worauf die anderen erwidern können. Dann nehmen alle die Karten nocheinmal und spielen nocheinmal. Das wiederholt man bis alle gleich schätzen, oder bis klar wird, dass man ewig weiter diskutieren könnte und trotzdem zu keiner Eistimmigkeit kommmen wird. Im Falle, dass es zu keiner Einstimmigkeit kommt, nimmt man den Durchschnittswert als Aufwandsschätzung.

Als letztes nimmt man den mit 1 bewerteten Punkt und beziffert ihn mit Manntagen ... also z.B. ein halber Manntag. Dann wäre automatisch die 2=1MT, 3=1.5MT, 5=2.5MT, 8=4MT, usw. Man summiert auf und hat die Gesamtschätzung.

Das nette ist ... es ist lustig ... und es gibt im Rahmen der Harvard Business School Papers die belegen, das diese Art der Schätzung genauere Ergebnisse erzielt als andere bekannte Methodiken. :-)

Planung eines Sprints

Hier ging es darum wie man die anstehende Arbeit priorisiert und das auswählt was als nächstes getan wird. Dazu hat man zu den Aufgaben die Aufwandschätzung, und der "Product Owner" muss den jeweiligen "Business Value" ... also die erwartete Wertschöpfung nennen. Die Ratio Aufwand:Wertschöpfung führt zur richtigen Priorisierung, d.h. man tut zuerst die Dinge bei denen man mit dem kleinsten Aufwand die größte Wertschöpfung hat.

Wir machten mehrere Iterationen von "Dummy Aufgaben". Es ging ja nicht um die Aufgaben, sondern um das Planungsprinzip. Am Ende jeder Iteration gab es neue Aufgaben die sich inzwischen angesammelt hatten, und es wurde anhand von Aufwand und Wertschöpfung neu priorisiert und das gewählt was man in den nächsten Minuten schaffen würde. Es galt wieder Selbstorganisation, d.h. das Team wählte selbst was es tat und wie es getan wurde, anhand des beschriebenen Wertschöpfungsprinzips.

Step around the room

Das war für mich fast die beeindruckendste Übung ... vielleicht weil ich sie in den Unterlagen gelesen hatte und mir dachte "so ein Blödsinn!".

Aber das muss ich persönlich schildern. Das kann ich hier nicht widergeben ... es würde blöd klingen ... es war aber mit die beeindruckendste Übung, weil sie so klar zeigte, dass ein System "on the edge of chaos" dem Selbstorganistion gestattet wird, sich von alleine optimal ausrichtet und in den "flow-state" übergeht in dem eine Hyperproduktivität erreicht wird. Glaubt es mir, es war hoch beeindruckend.

Generell ... ich nehme viel zum lesen mit. Scrum ist keine Disziplin die eine Spinnerei von wenigen ist, sondern ein Framework um die Prinzipien die man "Agile Methodik" nennt. Dies ist ein Forschungsfeld der Harvard Business School, und all diese Leute von denen die Foundation betrieben wird - wie Jeff Sutherland, bei dem ich den Kurs gemacht habe - veröffentlichen ständig auch Papers zu diesen Themen. Es ist ein ganz klarer "field of research" im Bereich des Software Engineerings, mit Prinzipien die in jegliche andere Bereiche des Managements zur Anwendung gebracht werden können.