Schwankende Teamstärke

Für uns inzwischen Standard das die Teamstärke laufend schwankt. Wir rechnen deshalb auch nicht mit dem speed des ganzen Teams sondern mit Storypoints pro Teammitglied.
In jedem Sprint planning gibt jeder an wie viel er da sein kann für dieses Projekt. Personen die unter 50% fallen werden werden oft den kommenden Sprint ganz freigegeben damit sie die anderen Aufgaben erledigen können und im nächsten Sprint wieder voll dabei sind.
Schön zu sehen das es andere auf ähnliche Lösungen kommen wie wir:

Is ScrumMaster Time Tracked in Sprints? von Hubert Smits,  
ursprünglich geteilt von Martin Hammerle.

Wie man sieht arbeitet bei uns der ScrumMaster (ich) auch mit deshalb bin ich fast der Einzige der immer wieder unter die 50% Marke fällt.

Hardware

Aus sehr vielen Reviews, daily scrums und Sprints wurde nun endlich Hardware.
Unsere Anlage ist mechanisch so gut wie fertig zusammengebaut. Wenn auch noch die Elektrik installiert ist rückt die Inbetriebnahme in greifbare Nähe.

Bis jetzt sehen wir eine noch nie dagewesene Qualität des Prototypen. Bis jetzt hat jedes Teil seinen Platz ohne Flex und Schweissgerät gefunden. Der Reifegrad ist wie schon vermutet sehr sehr hoch. Die Abrechnung des gesamten Entwicklungsaufwandes wird zeigen ob wir diesen Level mit einem viel höheren Aufwand bezahlt haben. Oder ob sich die momentanen Hochrechnungen bewahrheiten, das wir mit weniger Aufwand, eine gute Maschine gebaut haben.

Es bleibt spannend.

Hardware

Retrospektive Software Mechanik interdisziplinär

Die letzte Retrospektive hat Stefan, einer unserer Programmierer im Team, organisiert und moderiert. Für mich war es toll mal unvorbereitet kommen zu können. Auch mal nicht der Moderator zu sein habe ich sehr genossen.
Zum Thema der Retro gemacht wurde die Zusammenarbeit im Team zwischen den Mechanischen Mitgliedern und den Software Members. Es haben sich doch einige Potentiale ergeben die wir versuchen werden zu nutzen. Z.B. wird es vor dem Start der Programmierung einer Einheit ein gemeinsames Preview Software und Mechanik geben.
Was wir auch feststellen konnten ist das die Mechaniker sehr wenig Vorstellung davon haben was SW ist und wie so was entsteht. Auch Begriffe wie UML, PLC, HMI, usw. sind oft gehört und nie verstanden. Um hier noch weiter zusammenzuwachsen werden wir eine "SW für Engineers(Dummys?)" Training teamintern organisieren. Ich freu mich schon darauf.
Wir haben am Ende noch verglichen wie die Zusammenarbeit vor 5 Jahren zu heute ist. Wir könnten uns nicht mehr vorstellen jemals wieder so räumlich und abteilungsmässig getrennt zu arbeiten wie früher. Das interdisziplinäre Team ist sehr viel schneller und dabei ist die gelieferte Qualität massgeblich besser. Abgesehen davon macht es viel mehr Spass und jeder kann sich mit dem entwickelten Produkt identifizieren.

Srum tief gesunken!

Wir sind umgezogen von Hausnummer 3 zu 1. Unser neues Büro bietet perfekte Aussicht über das Rheintal und einen tollen scrum Teambereich.
Wer Scrum kennt weiss das man immer mit inpediments kämpft. Unser Aktuellstes beschäftigt sich mit 2 fehlenden Schrauben. Aber das Team hat selbstbestimmt und schnell eine Lösung geschaffen.
Kommt das Board nicht auf unsere Höhe kommen wir auf die Höhe des Boards:

Variante für junge Teammitglieder!

Variante für die Weisen unter uns!

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.