User Storys in der Hardware Entwicklung

Bernd Wawczyniak von Bosch Engineering hat mich gefragt ob und wie wir User Storys einsetzen:

Wir verwenden User Storys aber nicht ausschließlich. User Storys bekommen im planning oft sehr viele Story Points – meist mehr als in einem Sprint erledigt werden kann. Also werden die meisten in kleinere Storys geteilt.

Beispiel: Story mit der Nr.1

Story:

Pattern: Als <Rolle> will/kann ich <Ziel erreichen> damit/so dass ich <Begründung>. (von Ralf Wirdemann) 

Als CEO will ich dem Kunden ein neues Maschinenkonzept vorstellen, damit wir Technologieführer bleiben.

 

Umfang: (Der Umfang steht in Backlog und ist bei uns automatisch ein Teil der DOD)

- Grobe Kostenabschätzung

- Grobes Layout zur Bestimmung des Platzbedarfes

- ...

Jetzt hängt es von der Schätzung ab ob wir diese Story teilen oder nicht. Wenn wir teilen dann so das die Storys möglichst interdisziplinär bleiben.

Das heißt wir teilen nicht auf in: Konzept elektrisch / Konzept mechanisch / Konzept Software

Sondern in: Konzept Abtransport / Konzept Bedienen/ Konzept …  - somit sind immer alle Disziplinen gemeinsam im Einsatz – die Qualität der Lösung ist besser.

Was ich bei diesem Beispiel noch zeigen möchte ist das es sehr wichtig ist agiles Vorgehen möglichst schon beim Projekt Startup zu verwenden, bevor es Lastenhefte, Pflichtenhefte usw. gibt.

Wo kommen die Anforderungen wie …eine Maschine für 1 Mio. Flaschen pro Stunde…  her - könnte man sich fragen.

Diese Sachen sind Teil der Vision. Marcello Leonardi von Namics. hat das auf dem scrum breakfast in St. Gallen schön beschrieben. 

Eine Vision setzt sich zusammen aus:

- Produkt Datenblatt (grobe Spezifikation des Produktes, 1Mio Flaschen pro Stunde…)

- Produkt Schachtel (wie schaut das Ding aus? Jeder soll eine Idee davon haben wie die Verpackung / Verschalung ausschauen könnte)

- Presse Mitteilung (was hätte man gerne das über das Produkt geschrieben wird)

- Elevator Pitch (kurzes Statement über die Positionierung des Produktes und die Abgrenzung zum Mitbewerber) 

Das Erstellen der Vision ist Arbeit des Teams! Der PO muss gut vorbereitet sein und dann gemeinsam mit dem Team die Vision erstellen.

Wieso? Es ist essentiell das das Team die Vision versteht und dahinter steht damit die Umsetzung auf die Vision ausgerichtet wird.

Neben den User Storys haben wir viele ganz „normale“ Sachen die gemacht werden müssen um die Vision zu erreichen. Wichtig ist das sie im selben Backlog stehen und somit priorisiert sind. Die Priorisierung muss der PO mit dem Team abstimmen denn oft sind Abhängigkeiten der Storys untereinander gegeben – egal wie intensiv man versucht diese zu vermeiden. Das Team schreibt natürlich auch Storys und muss dann dem PO die Begründung liefern wieso das gemacht werden sollte.

Das Thema ist sehr weitläufig – man könnte eine Buch darüber schreiben wobei es nicht DIE richtige Vorgehensweise gibt. Wichtig, und immer richtig, ist die Retrospektive.

Das Team, zu dem auch der PO gehört, muss gemeinsam durch "inspect and adapt" herausfinden, welches der beste individuelle Weg ist.

Was hatte die Einführung der agilen Methode für einen Einfluss auf die Firma?

Die Beantwortung dieser Leserfrage ist nicht ganz einfach weil die Antwort sehr subjektiv ist. Ich werde versuchen es anhand zweier Zeitpunkte festzumachen.

Anfangsfase:

Als wir angefangen haben mit scrum zu arbeiten hat es niemand tangiert. Es ist höchstens ein paar wenigen aufgefallen das wir so eine Wand voll mit Zetteln haben. Der ein oder andere ist dann auch mal stehen geblieben wenn wir mitten im Büro unser daily abgehalten haben, und hat sich gewundert was da abgeht. Ein paar wenige haben schüchtern gefragt was das soll.
Also wir waren eine Insel, und haben in einem kleine Team experimentiert, ob ein neuer Weg funktionieren kann.
Einfluss auf die Firma geht gegen Null.

Erste größere Veränderungen

Ich habe ein internes Stakeholder Meeting einberufen. Der CEO, die Abteilungsleiter der Entwicklungsabteilungen und auch Projektphasen spezifische Stakeholder waren vertreten.
In dieser Besprechung gibt es mehrere Punkte die wir jedes mal durchgehen. Dazu gehört:

- Backlog: Ergebnis des letzten sprint's; Was werden wir im nächsten sprint machen;
- Offene Punkte aus tangierenden (nicht agilen) Projekten
- Stand des machine burn down chart (ReleaseBurnDownChart); Bis wann ist mit welchen Ergebnissen zu rechnen. (siehe Bild)

Dadurch war das Projekt für jeden (Stakeholder) sehr viel transparenter als die vorangegangenen.

Einfluss: Diese Transparenz wurde plötzlich auch in anderen Projekten gewünscht. Deshalb wurden mehrere Projekt und Abteilungsleiter auf scrum Kurse geschickt.
Die Kurse geben einem gute Werkzeuge in die Hand. Wir arbeiten momentan daran geschickt Umgang mit ihnen zu werden. Und wie immer gibt es Naturtalente und welche die ein wenig Übung brauchen.
Um diese Übung gemeinsam zu bekommen habe wir angefangen das wir eine Gruppe von 3 wechselnden Personen zum monatlichen scrum breakfast in St.Gallen schicken. Diese organisieren dann ein internes Frühstück bei dem alle scrum "Jünger" teilnehmen. Es wird der Vortrag des breakfast's vorgestellt und anschliessend bei Kaffee und Gipfel diskutiert.

Ich kann das allen empfehlen eine übergreifende Diskussionsrunde, oder sogar Retrospektive, für die SM und PO abzuhalten. Speziell während der Einführung von scrum in mehreren Projekten und Abteilungen.

Agile Inbetriebnahme

Wie wickeln wir eine Inbetriebnahme ab? Sollen wir auf ursprüngliche Methoden zurückgreifen oder ziehen wir das agile Vorgehen durch?

Die Entscheidung war klar - agil hat bis jetzt gut funktioniert also wird es auch in der Inbetriebnahme Vorteile bringen. Diese Entscheidung war einfach zu treffen denn allen war klar, sollte es nicht gehen werden wir das in der Retro raus finden und ändern. Diese Einstellung hat uns schon oft geholfen etwas ohne langes Diskutieren zu probieren. Jeder im Team weiss das wenn eine Entscheidung getroffen wird, diese nicht automatisch Gültigkeit "für immer" hat, sondern wenn notwendig  hinterfragt wird.

Um allen klar zu machen das wir es ernst meinen haben wir unser Scrum Board in die Montagehalle verlegt. Diese Entscheidung war gut und schlecht.
Schlecht waren die Störungen des daily scrums durch Lärm der angrenzende Produktions und Verladehalle.
Sehr positiv war das Entstehen des Team Gedankens. Durch die tägliche Abstimmung mit dem Montagepersonal konnten sehr viele Reibungsverluste vermieden werden. Im Prinzip haben wir ein daily scrum mit 2 Teams abgehalten.

Die Durchführung von 4 Wochen Sprints hat für die Montage nicht gut funktioniert deshalb haben wir für die Inbetriebnahme Arbeiten auf eine Art KANBAN umgestellt. Das Entwicklungsteam hat weiterhin mit 4 Wochen "gesprintet" allerdings haben wir uns 30% Zeit für die Betreuung der Montage reserviert.

Fazit
Eine Inbetriebnahme ist sehr gut auch agil möglich. Die Vorteile entstehen vor allem durch die Methoden wie daily scrum, Retrospektive und gemeinsame Planung. Die Sprints bzw. die Inkremente sind besser klein zu halten.

Pimp my poker cards

 "...wer hat meinen Dreier!!!"   "...ich habe 3 Fünfer!"    "...wer macht da immer so ein Saustall"
Irgendwann hat das ständige sortieren der Poker Karten genervt. So einfach ist besser:

 

Tuning Kits können bei mir bestellt werden - hoffentlich werde ich reich damit.

Retrospektive weglassen!

Was ist passiert?
Nachdem wir das Gefühl hatten das wir sehr gut unterwegs sind, und jetzt "nur noch" die Inbetriebnahme ansteht, haben wir die Retro "wegentschieden".

Wieso?
Wir dachten die Inbetriebnahme ist mehr oder weniger ein Bug fixen, welches nicht agil planbar ist. Deshalb haben wir mit dem Planning auch die Retro abgeschafft. Denn scrum ist nichts für die Inbetriebnahme Fase.

Ja jetzt beim Schreiben ist mir auch klar, dass es keine gute Idee war.

Schnell hat sich gezeigt das alle im Team nach einer Planung und nach einer Retro rufen. Es ging gar nicht um scrum ja oder nein sondern allein darum das wir nicht mehr so schnell und gut abgestimmt unterwegs waren wie zuvor. Und das war nicht befriedigend für alle Teammitglieder.

In der neuen Situation der Inbetriebnahme hatten wir eine Retrospektive dringender nötig denn je.
Nach zwei ausgefallenen Workshops haben wir dann eine NotRetro mit anschliessendem Planning durchgeführt.

Es zeigt sich, dass ein agil arbeitendes Team erkennt, dass es gut ist sich ständig zu verbessern. Und unzufrieden wird wenn das plötzlich nicht mehr geht.
Für mich ist das Ganze ein Zeichen das wir wirklich auf dem agilen Weg sind, denn sonst wären alle Team Mitglieder froh gewesen die "lästigen" scrum Meetings los zu sein anstatt zu rufen: "Wir hätten Bedarf und Potential uns zu verbessern lass uns eine Retro machen"



Agile Bodensee 2013 #abkon

DONE is better than PERFECT

Eine der vielen Aussagen die mir speziell geblieben ist. Die Agile Bodensee Konferenz war sehr spannend. Es tut gut zu hören das Andere mit ähnlichen Problemen kämpfen. Gleichzeitig erhält man viel Inspiration wie man jene Probleme angehen kann. 

Was sehr deutlich wurde, obwohl es eigentlich logisch ist, ist das ein gutes Team hauptsächlich auf Vertrauen basiert. 

"Die Bandbreite der Kommunikation steigt mit dem Vertrauen." 

Amüsant fand ich das sich Maik Pfingsten als Exot auf der Veranstaltung bezeichnet hat weil er "Embedded Programmierer" war. Was bin dann ich?

Insgesamt eine sehr empfehlenswerte Veranstaltung für jeden der mit agile zu tun hat oder es evtl. haben wird.

Herbst

So die Sommerpause ist vorbei. Ich war ein wenig faul über den Sommer. Nicht nur Zeitungen sondern auch mein Blog hat jetzt ein Sommerloch.
Dafür hab ich einen Backlog für meine nächsten Blogs:

- Agile Bodensee 2013 #abko
- Foto was aus viel Theorie für eine Hardware entstanden ist
- scrum während der Inbetriebnahme?
- scrum während der Qualifizierung der Maschine durch den Kunden?
- was passiert wenn man die Retro weglässt
- was passiert wenn man das Sprint planning weglässt.

Das sind die Themen die mich über den Sommer beschäftigt haben. Ich werde meine Erfahrungen dazu in nächster Zeit bloggen.

Kontinuierliches Testen und Integrieren

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

Das kontinuierliche Integrieren und Testen der Produktinkremente hat in der agilen Entwicklung eine große Bedeutung. Wie sieht das Integrieren und Testen der Produktinkremente in der agilen Hardwareentwicklung aus?

Das Integrieren und Testen der Baugruppen, in den ersten Inkrementen, erfolgt in der virtuellen Welt. Sehr viele Punkte können wir mittels Berechnungen oder durch Reviews mit Experten testen. Auch das Integrieren mehreren Maschinekomponenten zueinander erfolgt virtuell. Zuerst wird Baugruppe A, dann Baugruppe B geplant. Das Integrieren von A zu B wird dann oft als eigene Story aufgesetzt. 
Während der Konzepterstellung kommt es auch vor das gewisse Sachen nicht berechenbar sind oder die Berechnungen zeigen das es knapp ist. Dann wird vom Team oder vom PO vorgeschlagen ein Funktionsmuster der betreffenden Einheit zu bauen.
Später wenn reale Hardware vorhanden ist wird weiterhin "inspect and adapt" betrieben. Das heisst erkennen wir ein Teil der Maschine das nicht wie gewünscht funktioniert, oder besser wäre wenn es anders funktioniert, wird es ausgetauscht. 
Ja das kann sehr viel Geld kosten aber es wird weiterhin nach Kosten - Nutzen entschieden ob etwas angepasst wird oder nicht. (nach ROI priorisierter Backlog)
Der Vorteil der agilen Methode liegt darin das wir einen höheren Reifegrad im Prototypen erreichen und dadurch weniger oft teure "real" Hardware austauschen müssen. Für die Projektkalkulation haben wir bis dato mit ca. 100% des Preises einer ganzen Maschine gerechnet was an Versuchsteilen und Ausschussbaugruppen anfällt. Bei der aktuellen Entwicklung  werden wir nicht mal die 50% Marke erreichen.

Agile Bodensee early bird

agile bodensee early bird Ticket

Anforderungen beim Start eines Hardware Projektes

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

Die Änderung von Anforderungen ist in der Hardwareentwicklung nicht so problemlos wie im Softwarebereich. Wie detailliert müssen die Anforderungen zu Beginn eines Hardwareentwicklungsprojektes vorliegen und die Umsetzung geplant werden? 

Wenn wir für ein neues Projekt viele detaillierte Anforderungen hätten, wäre eine agile Vorgehensweise nicht sinnvoll. 

Wir haben uns für scrum entschieden da anfangs sehr wenig Anforderungen vorhanden sind. Meistens gibt es eine Idee oder eine spezielle Anfrage des Kunden die zu einer neuen Maschine führt. Wie die Idee umgesetzt werden könnte ist höchstens in groben Ansätzen vorhanden. Aus den Ideen und Vorstellungen wird gemeinsam ein Vision erstellt. Sachen wie Lastenheft, Pflichtenheft,... fallen komplett weg. Und bei einer Ausgangslage wie dieser macht es Sinn agil zu entwickeln.

Wir machen ein Inkrement und stellen es dann vor. Sobald die Stakeholder den 1. Entwurf sehen findet sofort die gewünschte Feedback Diskussion statt. " ... das ist so wie wir uns das vorstellen... , ...aber das wäre besser wenn es so funktioniert... , ...könnte man nicht...". Mit diesen Inputs erstellen wir neue user storys die dann wieder priorisiert und in den folgenden Sprints abgearbeitet werden.

Mit diesem Vorgehen beim aktuellen Projekt haben wir erreicht das jetzt die Maschine in "real hardware" in der Montagehalle steht und jeder Stakeholder findet das sie so ist wie er sich das vorgestellt hat. Wir haben, im Vergleich zu früheren Projekten, keine Diskussionen, ob das so wie es da steht so ist wie man es wollte.

Will man scrum Projekte im Hardware Bereich durchführen, muss aus meiner Sicht ab dir 1. Projektidee agil gearbeitet werden.

Änderungen an den Anforderungen sind in der Planugsphase sehr leicht umzusetzen. Durch das agile Vorgehen sind weniger Änderungen an der "real Hardware" notwendig da die Qualität der 1. Maschine in vielerlei Hinsicht besser ist als bei nicht agilem Vorgehen.

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.