Retrospektive mit Product Owner

Das Projektleiter Abstimmungsmeeting wurde aufgrund mangelndem Teilnehmerinteresse abgeschafft. Als scrum Master und ehemaliger Projektleiter gehörte ich auch zum Kreis Teilnehmer die zu wenig Interesse daran haben -ich geb's ja zu.  Es war vielfach nur ein Projektstatus Runterlesen und weniger ein Austausch Richtung inspect und (vielleicht) adapt.
Jetzt war unser Head of Development, der gleichzeitig PO unseres einzigen scrum Projektes ist,  auf der Suche nach einer spannenderen Alternative. Mein Vorschlag war klar "Projektleiter Retrospektive".
Um unserem PO eine Vorstellung zu geben wie so etwas ausschauen könnte haben wir ihn auf unsere Retro eingeladen. Ich habe das Gefühl es ist sehr gut angekommen.
Neben einer Timeline und +/- haben wir auf das "agile ball game" gespielt. Das hat sehr viel Spass gebracht und gleichzeitig auf sehr einfache Weise veranschaulicht wie agile Prozesse funktionieren können.
An dieser Stelle noch vielen Dank an meine Kinder die freundlicherweise das Spielmaterial zur Verfügung gestellt haben.

Timeline

Srum -- aber!

Wo liegt euer Wert? Ich freu mich über einen Kommentar.

scrumbutt.me

Kopfmonopol...

ein nicht zu unterschätzendes Thema. 

Einige haben Angst davor nicht mehr "Der Experte" zu sein. Am meisten jene die jammern das sie überlastet sind.
Guter Beitrag dazu: Kopfmonopol ade?

shippable & definition of done

Ein grosses Thema, wenn theoretisch über Scrum in der Hardware Entwicklung diskutiert wird, ist shippable. Eine Software ist nach jedem Sprint lauffähig das wird mit einer Maschine selten so sein. Die Inhalte in den ersten Sprints sind Grobkonzepte, Wirtschaftlichkeitsanalysen, Kostenabschätzungen und vieles anderes das nicht im eigentlichen Sinne shippable ist.
Das hat uns nicht daran gehindert Scrum zu verwenden.

Denn eigentlich geht es nur um eine Definition welches die geforderten Inhalte einer Story sind. Dies wird im DoD festgehalten. Sind die Punkte abgehandelt wird ein Review über das Ergebnis abgehalten und im Team (oft mit PO) entschieden OK oder NOK.
So haben wir für die unterschiedlichsten Aufgaben done's. So gibt es DoD's für Grobkonzepte, für Detailkonzepte oder für Finalize. Und eben auch DoD's die nur zu einer Story passen.
Spezielle DoD's schreiben sich praktisch von selbst wenn im Sprint planning die Story diskutiert und geschätzt wird. Im "Streitgespräch" über die Aufgabe wird immer über den Umfang verhandelt. Und ein detaillierter Umfang ist gleichzeitig das DoD.

Das wirklich wichtige ist ein gemeinsames Verständnis für das Ergebnis einer Story. Dies wird im Sprint planning durch planning Poker, und die daraus resultierenden Diskussionen,  sichergestellt.

1 Jahr "Hardscrum" DONE

Wir sind inzwischen im 13. Sprint und somit ein Jahr mit Scrum unterwegs. Wir befinden uns in der Bestellfase. Das heisst, es geht um reale Hardware. Abgeschlossene Storys bedeuten jetzt bestellte Teile und damit Stahl und Kosten.

Es ist jetzt soweit das wir die ersten Früchte unseres Scrum Projektes sehen. Die Retrospektiven, mit dem Ziel der permanenten Verbesserung, haben mehr gebracht als ich mir erwartet hätte. Die Stimmung im Team ist sehr gut keiner verfällt in den früher üblichen "Bestellstress" - auch 100 Stunden Wochen sind nicht nötig um das Projektziel zu erreichen.

Der Reifegrad des jetzt bestellfertigen Prototypes ist sehr hoch. Höher als bei jedem anderen Vorgängerprojekt. Beispiele dafür sind:

Es gibt heute schon eine durchgeplante Transportvorrichtung inklusive Anleitung.
Für Sachen wie diese war früher erst kurz vor der Auslieferung, notgedrungen, Zeit. Durch das frühe Einplanen sind alle nötigen Gewinde, Ösen etc. bereits platziert und vorbereitet. Keine aufwendigen Nacharbeiten oder gefährliche Notlösungen werden zum Versenden notwendig sein. Die Maschine passt nicht in eine CD Hülle sondern hat 9.000kg!

Die Energieführung ist komplett durchgeplant, erfasst und bestellt.
Früher wurde bei der Erstmontage definiert wo was wie verlegt wird, welche Halter dazu benötigt werden und wie lange die Schläuche zu sein haben. Dies führte zu riesigen unübersichtlichen Änderungen. Erschwerend war das diese Anpassungen in einer Zeit anfallen, in der sehr viel Arbeit und Umtrieb aufgrund der Inbetriebnahme herrscht. Der heutige Stand ist das alle Teile bis auf die letzte Schraube und das dazugehörende Gewinde konstruiert, und auch mit der Montage abgestimmt sind. Das gibt uns die Sicherheit die Inbetriebnahme des Prototyps konzentrierter vorantreiben zu können. Was eine frühe Freigabe der Serie Maschinen zur Folge hat.

Man könnte meinen der hohe Reifegrad führt dazu das die Entwicklung länger gegangen ist oder mehr Stunden verbraucht hat, aber das Gegenteil ist der Fall. Ein Jahr von Projektstart bis zur Bestellung der Maschine liegt unter unserer Durchschnitt.

Ja wir können die ersten Früchte schon sehen und freuen uns auf die Ernte, die vom heutigen Standpunkt aus, sehr vielversprechend aussieht.

Retro Sprint 12

Um die Retrospektiven spannend zu halten habe ich mir für diese etwas Besonderes ausgedacht.
Anstatt der Timeline habe ich ein Scrum Quiz organisiert. Es geht darum Aufgaben und Verantwortungen in einem Projekt der jeweiligen Scrum Rolle zuzuordnen. Es war interessant zu sehen wo die Unterschiede in unserem Verständnis von Scrum und der "Lehrmeinung" liegt.

 Das Ergebnis der drei Teams war fast gleich. Ergebnis:

Die Karten für dieses Quiz stammen aus meinem Scrum Training bei das Scrum Team.

Scrumnerds

"Inglorious Scrumnerds - Deutsch" auf YouTube

DOD 2012

DoD für 2012 ist done. 

Denn heute ist der 21.12.2012 und damit der letzte Arbeitstag in diesem Jahr für unser Team.

Ich wünsche allen frohe Weihnachten und einen guten Rutsch ins neue Jahr.

 

Ich freue mich schon auf ein weiteres spannendes Jahr mit Scrum in der Hardware!

Retrospektive Sprint 10 Timeline

Kaum zu glauben aber wir haben unseren 10. Sprint abgeschlossen.
Wie immer machen wir am Anfang der Retro eine Timeline. Jeder schreibt auf was ihm aus den letzten 4 Wochen in Erinnerung geblieben ist. Es kann projektbezogen sein muss aber nicht. Es fällt auf das unser Gedächtnis sehr kurzlebig ist (agil?!). Die Erinnerungen an den Sprintanfang liegen meist ein wenig im Dunkeln. Gegen Sprintende werden die gespeicherten Ereignisse mehr.
Die Timline ist ein lockerer Einstieg in die Retrospektive mit einem gewissen Spassfaktor vor allem bei den nicht geschäftlichen PostIt's. Beispiel gefällig:

- Kartoffelkanone mit Sohn gebastelt und getestet
- neue Motorsäge gekauft
- Fasching

Je unscheinbarer das Kärtchen umso besser ist meist die Geschichte dahinter.

DOD definiton of done

Die im Grobkonzept verwendeten scrum done meetings haben wir seit den Detailkonzepten umgestellt auf DOD. Für jede Phase des Detailkonzeptes sieht dieses DOD anders aus. Der Inhalt dieser Listen ist in Zusammenarbeit mit den unterschiedlichsten Abteilungen und Stakeholdern entstanden. Neben den Punkten die sich das Team selbst auferlegt hat gibt es die Aufgaben aus anderen Geschäftsbereichen. Einfaches Beispiel dafür ist das wir schon im Detailkonzept sauber im System definieren welche Teile Verschleissteile sind. Bis anhin wurde das erst gemacht wenn die ersten Maschinen ausgeliefert waren. Dies war mit viel Aufwand verbunden da meistens eine "projektfremde" Person alle Berechnung zusammensuchen musste dann nachfragen welche denn die aktuell gültige ist bevor ein Paket definiert werden konnte.

Quick input

 SCRUM FUNKTIONIERT NICHT IN DER HARDWARE ENTWICKLUNG

Gegenbeweis?

Sprint Burndown chart neu

die Ecken und Kanten unseres Burndown haben uns nicht mehr gefallen. Deshalb entwickeln eines neuen Excel burn down in dem die Wochenenden ausgeblendet sind. Hier der Vergleich:

VORHER:

NACHHER:

Wenn man den Trick kennt ist es immer einfach. Man muss die Achse umstellen von Auto auf Textachse.

Machine burndown chart

.. so heisst bei uns der Release Burn down chart. Dieser wird live aus dem product backlog generiert. Alles in Excel mit einfachen Mitteln aufgebaut.

Der machine burndown ist inzwischen ein wichtiges Instrument geworden um klar zu sehen welche Auswirkung zusätzliche Aufgaben im Backlog haben. Jetzt ist für jeden sofort ersichtlich wann mit einem Projektabschluss zu rechnen ist. Auch hilft er massgeblich bei der Priorisierung des Backlogs da viel mehr darüber nachgedacht wird was bis zum 1. Release (Test Prototyp 1) wirklich nötig ist. Bis anhin hätte man einfach alle Aufgaben auf diesen Termin gelegt und gleichzeitig die Planung nicht verändert.

Retro Sprint 9

Nach einem guten Sprint hat man oft das Gefühl das eine Retrospektive überflüssig ist. Dieses Gefühl verschwindet sobalad man im Meeting sitzt. Ich will damit sagen das ich immer mal wieder verleitet war die Retro ausfallen zu lassen und bis jetzt immer wieder gemerkt habe das sie doch notwendig und sinnvoll war. Denn neben inspect and adapt ist es eine gute Gelegenheit gemeinsam geleistetes zu "feiern".

 

Sprint 9

Nach dem letztzen sehr aufreibenden Sprint war dieser vergleichsweise ruhig und mit wenig impediments gesegnet. Der Burndown sieht sehr chaotisch aus. Das Problem ist aber ein rein optisches. Die Wochenenden und Feiertage sind nicht entfernt, deshalb diese Hacker. Stefan unser "Excel Freak" hat sich dieser Aufgabe angenommen.

 

Dies war auch der 1. Sprint in dem wir sehr intensieve Reviews mit allen möglichen Stakeholdern geführt haben. Dazu gehörten vor allem Montage, supply und sustain engineering.

Auch die in der Letzten Retro aufgestellten Regeln für das daily wurden sehr gut eingehalten.

Team beim daily scrum.

Retro Sprint 8

Diesmal war die Retrospektive sehr wichtig denn wir konnten den letzten Sprint bei weitem nicht vollständig abschliessen.
Deshalb haben wir dieses Meeting auch vor das "sprint planning" gezogen.
Die Frage die wir uns selbst gestellt haben war "kein DONE warum?"

Schnell kristallisierten sich 3 Punkte heraus 
1. das DOD war zu umfangreich für einen Schritt war
2. die Grobkonzepte waren nicht so weit gediehen das sie wirklich im Detail umgesetzt werden konnten. Es gab immer noch mehrere Varianten einer Baugruppe ohne getroffene Entscheidung
3. Kommunikation und Information im Team war nicht ideal. Die dailiy's haben an Qualität eingebüsst neue Ideen werden einfach eingebracht und in der bestehenden Story umgesetzt

Massnahmen
 
Damit die Storys in Zukunft nicht mehr zu umfangreich sind werden wir das Detailkonzept in 3 Stufen teilen (anstatt bisher 2)
Stufe 2 wird unterteilt in
"DK2" Baugruppe fertig bis zu Review mit Montage und Einkauf
"DK3 finalize" gezielt von PO bestimmte Punkte aus den Reviews umsetzen und Baugruppen bestellreif machen.

Damit der Informationsstand aller Teammitglieder auf dem selben Niveau gehalten wird, werden wir in Zukunft jeden Freitag ein internes Team Review am 3D CAD abhalten. 

Auch haben wir uns vorgenommen im Fall einer neuen Idee für eine bereits begonnene Story diese nicht mehr in der laufenden Story zu prüfen sondern einen neunen Backlogeintrag aufzunehmen.

Sprint 8 Erfolg?

Wir befinden uns gerade in Phase Umsetzung der Grobkonzepte in bestellbare Baugruppen. Schon in der Mitte des Sprints 8 mussten wir feststellen das der Burndown nicht vielversprechen aussieht. Wir entschlossen uns trotzdem nicht abzubrechen. Es wurde auch in der 2. Hälfte nicht besser.
Am Ende hatten wir nur ca. 1/3 der vorgenommenen Aufgaben erledigt! 
Woran liegts? Das wird sicher eine spannende Retrospektive.

Scrum Nachwuchs

Scrum fällt auf - alleine durch das grosse Scrum Board mitten im Grossraumbüro.
Leute die neue Projekte starten kommen neugierig fragen ob das für sie auch was wäre dieses SCRUM.
Gerne erklären wir wie es funktionieren könnte wo die Probleme liegen  aber vor allem natürlich welche Vorteile es mit sich bringt. Wir freuen uns über jeden der es versucht, denn so wird auch einen Retrospektive oder zumindest ein Austausch der scrum Master möglich.
Also Christian zeig was du kannst - wir helfen dir bei scrum.

Release burn down

Seit dem Sprint Nr.8 haben wir auch einen aussagekräftigen "release burn down chart". Es hat eine Weile gedauert da wir nicht alle Aufgaben geschätzt hatten die notwendig sind bis zum Release. 

Release im Maschinenbau? Wir mussten uns auch zuerst klar werden was denn ein Release bei mechanischen Teilen, Maschinen und Anlagen ist. Auf was haben wir uns geeinigt? :

Release 1 = 

Beta Version = Fertig konstruierte Maschine - alle Teile bestellt - Montage kann starten

Release 1.1 = 

Maschinen Prototyp produziert das gewünschte Produkt - alle wichtigen Komponenten getestet Maschine kann für einen Feldversuch ausgeliefert werden.

Release 2.0 =

Serienreife

Alle Erkenntnisse aus Feldversuch sind eingeflossen. Alle notwendigen Optimierungen des Montageablaufes sind umgesetzt. Alle erforderlichen Dokumente für einen weltweiten Betrieb sind vorhanden. 

weitere "Releases" werden wir bei Bedarf spezifizieren.

SCRUM JA/NEIN

In der letzten Retrospektive haben wir uns bewusst die Frage gestellt "Wollen wir als Team weiter mit Scrum arbeiten JA / NEIN?".
Die Frage war aus meiner Sicht als SM klar. Ich bin überzeugt dass es gut ist, aber ist es das Team auch? Es hat einiges an Umstellung für jeden gebracht und Veränderung ist immer schwierig. Langer Rede kurzer Sinn das Team hat sich klar für SCRUM entschieden - was mich riesig gefreut hat.
Es gab 25 Gründe für und 8 gegen scrum. Die Nachteile konnten wir grösstenteils als Verbesserungspotentiale identifizieren.