Unser Vortrag Scrum im Maschinen & Anlagenbau

Aufgrund der Überredungskünste diverser Personen, haben wir Martin und ich, zugesagt einen Vortrag auf dem ICT - Agile Breakfast in  St. Gallen zu halten. Wir werden vorstellen wie man auch in der Hardware Entwicklung Agil sein kann.
Wir freuen uns auf viele Teilnehmer und spannende Diskussionen.

Vorzeigesprint

Keine Schulungsunterlagen sondern "real scrum life":

Wir haben den perfekten Sprint geschafft!

not NO = YES

Klingt so einfach Bedarf aber einer Umstellung der Denkeweise die wir Jahre gelernt haben.
So ist viel mehr YES in den Projekten vorhanden. Das bringt Optimierungspotenzial, Handlungsspielraum, Freiheiten, ...

Danke an Andreas Scheerer für diesen Gedanken.

Agile Bodensee Konferenz 2014 #abkon

Es war spektakulär!

Danke an die Vortragenden und an die Organisation!

Ich hatte einen tollen Tag und habe viele neue Ideen und Erfahrungen mitgenommen. Auch konnte ich viel agilen spirit für den Projektalltag tanken.

Danke für den spannenden, abwechslungsreichen und erfrischenden Tag! Link Abkon

Projektende = Projektstart

Mein erstes agiles Projekt als scrum Master (oder doch PO?) neigt sich dem Ende zu.
Die letzten Monate haben wir damit verbracht unser Baby aus den Kinderschuhen zu heben. Inzwischen haben wir 8 jugendliche Maschinen ausgeliefert und weitere sind auf dem Weg dazu.

War das Projekt ein Erfolg - JA!
Und das in vielerlei Hinsicht. Der Kunde hat genau bekommen was er braucht, Vertrauen des Kunden gewonnen, sehr gute Qualität ab der 1. Maschine, Anlage in der Software Elektrik und Mechanik tief miteinander verwachsen sind, wenig Überstunden und viel Spass.

Haben wir alles richtig gemacht und waren bis in die Zehenspitzen agil - NEIN!
Wir haben vieles besser gemacht als in vorangegangen Projekten aber haben gleichzeitig auch gesehen das es immer noch Vieles gibt das besser gemacht werden könnte.

Werde ich das nächste Projekt wieder mit einer agilen Methode machen - JA.
Es wird auch eine Art scrum sein. Aber was genau ist scrum denn? Es geht uns vor allem um den "agilen spirit" das ist es, was ein erfolgreiches Team ausmacht.

Ich bin dankbar für die vielen Erfahrungen die wir im Team machen konnten. Manchmal war es ganz schön hart konsequent auf der agilen Linie zu bleiben aber meistens ist es uns gelungen.
Und ich freue mich schon heute auf unser neues Projekt.

Find ich immer wieder gut...

„Wenn Du entdeckst, dass Du ein totes Pferd reitest, steig ab!”

oder…

·    Wir besorgen uns eine stärkere Peitsche.

·    Wir sagen: „So haben wir das Pferd schon immer geritten”.

·    Wir gründen einen Arbeitskreis, um das Pferd zu analysieren.

·    Wir besuchen andere Orte, um zu sehen, wie man dort tote Pferde reitet.

·    Wir erhöhen die Qualitätsstandards für den Beritt toter Pferde.

·    Wir bilden eine Task-Force, um das Pferd wiederzubeleben.

·    Wir kaufen Leute von außerhalb ein, die angeblich tote Pferde reiten können.

·    Wir schieben eine Trainingseinheit ein um besser reiten zu können.

·    Wir stellen Vergleiche unterschiedlicher toter Pferde an.

·    Wir ändern die Kriterien, die besagen, dass ein Pferd tot ist.

·    Wir schirren mehrere tote Pferde gemeinsam an, damit wir schneller werden.

·    Wir erklären: „Kein Pferd kann so tot sein, das wir es nicht mehr reiten können.”

·    Wir machen eine Studie, um zu sehen, ob es bessere oder billigere Pferde gibt.

·    Wir erklären, dass unser Pferd besser, schneller und billiger tot ist als andere Pferde.

·    Wir bilden einen Qualitätszirkel, um eine Verwendung von toten Pferden zu finden.

·    Wir richten eine unabhängige Kostenstelle für tote Pferde ein.

·    Wir vergrößern den Verantwortungsbereich für tote Pferde.

·    Wir entwickeln ein Motivationsprogramm für tote Pferde.

·    Wir erstellen eine Präsentation in der wir aufzeigen, was das Pferd könnte, wenn es noch leben würde.

·    Wir strukturieren um damit ein anderer Bereich das tote Pferd bekommt.

·    Wir senden jemandem das tote Pferd als Geschenk. Geschenke darf man nicht zurücksenden.

 

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.