Shipable in der Hardware Entwicklung

Herr Vitalji, der eine Diplomarbeit über das agile Entwicklungsvorgehen schreibt, hat sich mit 4 Fragen an mich gewandt. Die 1. davon ist:

In der agilen Entwicklung wird ein potentiell auslieferbares Produktinkrement nach jeder Iteration verlangt. In der Hardwareentwicklung ist das Fertigstellen von auslieferbaren Produktinkrementen in kurzen Iterationen problematisch und gegebenenfalls mit hohen Kosten verbunden. Wie sieht ein Produktinkrement in ihrer agilen Hardwareentwicklung aus und was ist in dem Fall der auslieferfähige Zustand des Produktinkrements? 

Das ist eine Frage die wir lange und oft diskutiert haben bevor wir mit scrum gestartet haben. Wir sahen das auch lange als schwierig an.

Wir haben das "shipable" gegen "reviewable" getauscht. Das heisst nach einem Sprint ist die Konstruktion der betreffenden Einheit auf einem Stand das Stakeholder sich eine Meinung bilden können. Somit ist sichergestellt das in die nächste Interration alle erforderlichen Punkte einfliessen können. Die Stakeholder mit denen wir diese Reviews abhalten können aus den unterschiedlichsten Bereichen kommen. Je nach Projektstatus kann das der zukünftige Betreiber einer Maschine oder auch unser Monteur sein der die Anlage später zusammenbauen muss. Bei allen Reviews ist der Product Owner eingeladen. Mit unseren 3D Zeichensystemen sind wir in der Lage etwas so darzustellen das es für jeden verständlich ist. Komplexere Abläufe können wir animieren. Die Animationen gehen ohne grossen Aufwand soweit das wir die Bewegunskurven aus dem Programm Antrieb ins CAD einlesen und dort die Abläufe in "Echtzeit" darstellen.

Also der auslieferfähige Zustand ist für uns der Zustand in dem wir Bilder, 3D Daten, Animationen, Analysen etc so darstellen können das wir Feedback bekommen. Ich denke das ist auch der Grundgedanke von shipable.

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.