Irgendwann hat das ständige sortieren der Poker Karten genervt. So einfach ist besser:
Kann Scrum, als agile Methode, in der Hardware Entwicklung funktionieren? Wir arbeiten mit scrum an einem interdisziplinären Hardware Projekt welches Mechanik, Software und Elektronik beinhaltet. Wir verwenden das agile Vorgehen für alle Projektschritte: Grobkonzept, Detailkonzept, Inbetriebnahme, Qualifizierung, Startup beim Kunden, Entwicklung der Releases für die Seriemaschinen.
Freitag, 29. November 2013
Pimp my poker cards
Irgendwann hat das ständige sortieren der Poker Karten genervt. So einfach ist besser:
Dienstag, 15. Oktober 2013
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"
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"
Freitag, 27. September 2013
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.
Donnerstag, 26. September 2013
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.
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.
Freitag, 12. Juli 2013
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.
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.
Samstag, 6. Juli 2013
Freitag, 5. Juli 2013
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.
Donnerstag, 4. Juli 2013
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.
Montag, 17. Juni 2013
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.
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.
Dienstag, 11. Juni 2013
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.
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 |
Donnerstag, 16. Mai 2013
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.
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.
Freitag, 3. Mai 2013
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:
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! |
Abonnieren
Posts (Atom)