Leserfrage: Modulare Maschine sinnvoll?

Frage:

5. Ein Grund, warum späte Veränderungen an Software nicht so kostspielig sind wie an Hardware, ist die geringere Abhängigkeit der Systemkomponenten.

- Sollte man da bei der Entwicklung von Hardware auch ansetzen und versuchen, Produkte so zu konzipieren, dass Bauteile möglichst unabhängig voneinander austauschbar sind?

- Ist das überhaupt möglich?

 

Eine fein granular modulare Maschine zu bauen ist immer wieder ein Thema. 

Die gesamt Anlage ist modular (vom Granulat – Palette mit Flaschen). Die eigentliche Maschine nicht. Es gibt aus meiner Sicht mehrere Gründe dafür.

1.         Eine Modulare Maschine ist ca. 20-30% teurer da viele Schnittstellen und zum Teil auch zusätzliche Antriebe notwendig sind.

2.         … ist es schwieriger hochdynamische Prozesse zu fahren.

3.         … ist mehr Installationsaufwand erforderlich – bis die Maschine produziert – da mehrere Einheiten aufeinander abgestimmt/ eingestellt werden müssen.

4.         … erfordert mehr Entwicklungszeit da die Schnittstellen zwischen den Modulen auch entwickelt werden müssen.

5.         … die Maschine wird grösser – und Platz ist sehr teuer.

6.         …

Ich denke hochspezialisierte Systeme sind modular nicht sinnvoll.

...schwierige Frage…, denn modular ist so ein Schlagwort unter dem man viel verstehen kann. Denn anders betrachtet ist auch unsere Maschine modular. Denn wann immer spezial Lösungen in der Maschine erforderlich sind, finden wir ein Modul das wir „reinschrauben“ können und es funktioniert. Also ich würde sagen, wir haben einen Baukasten und keine Module.

Die Frage stammt von Steffen Berreth, er schreibt seine Bachelorarbeit über das Thema "Agiles Projektmanagement in der physischen Produktentwicklung"

Leserfrage: Hardware nach ROI priorisieren?

Frage:

Inwieweit reicht es bei der Entwicklung von Hardware aus, Anforderungen nach ROI zu priorisieren, ohne deren Abhängigkeiten durch klassische Sequenzierungsmodelle wie z.B. Gantt- Charts abzubilden und zu planen?

ROI ist die Priorisierungsmethode für uns. Allerdings muss ROI richtig verstanden werden – vor allem das Return – für uns gehört da mehr dazu als nur Euro zB Kundenzufriedenheit welche sich zusammensetzt aus Personalbindung, Energieverbrauch, Umrüstzeit, und einigen anderen Punkten.

Du siehst für uns ist ROI nicht so „flach“ bewertet wie für manch andere.

Auch eine Form der Gantt Charts verwenden wir – es gibt Meilensteine zB wenn eine Produktion mit der neuen Maschine starten muss. Der Umfang bis zu diesen Meilensteinen ist veränderbar. Unter Umständen lassen wir gewisse Features weg, die für einen Produktionsstart nicht zwingend erforderlich sind – und haben dadurch mehr Zeit für die wirklich wichtigen Features.

Zwingend erforderlich dafür ist, dass der PO versteht, was der Kunde braucht – noch besser das Projektteam versteht es.

Gibt es keine Features die verschoben werden können müssen wir die Meilensteine verschieben. Eigentlich sind unsere Meilensteine im Release Burndown implementiert. Storys werden immer dem spätest möglichen Meilenstein zugeordnet. Somit haben wir ein dynamisches Gantt Chart im Release burn down. Um genau zu sein machen wir das nicht mehr sehr ausführlich da unser Kunde nicht mehr den Bedarf an Meilensteinen hat. Das kommt daher das wir permanent mit ihm abgestimmt sind und er jederzeit weiss wie der Projektstand ist und auch immer wieder nachsteuern und eingreifen kann.

Die Frage stammt von Steffen Berreth, er schreibt seine Bachelorarbeit über das Thema "Agiles Projektmanagement in der physischen Produktentwicklung"

Inspirierendes agiles Zeugs!

Was hat mich die letzten Monate inspiriert?

Niels Pfläging mit seinem Vortrag "Das Ende des Managements. Wenn alle führen und alle verantworten"

Augenhöhe der crowdfunding Film über eine existierende neue Arbeitswelt. Es macht Sinn die erwähnten Unternehmen auch noch im Detail zu googeln!

 Mein wunderbarer Arbeitsplatz ...Dokumentation stellt innovative Konzepte vor, die es sich zur Aufgabe gemacht haben, die Arbeitswelt angenehmer zu gestalten... (arte) Leider nur noch auf youtube verfügbar.

Buch Management 3.0 von Jürgen Appelo - sehr lesenswert.

Luis Gonçalves spannender Blog mit kreativen Ansichten

Impulsvortrag beim Innovations Netzwerk Bodensee

Eine spannende Runde zu einem spannenden Thema. Es hat mir viel Spass gemacht den Vortrag zu halten. Ich bedanke mich hiermit nochmals für diese Möglichkeit.
Ich habe mal wieder gemerkt agil ist in aller Munde! Und dabei reduziert sich das Ganze nicht mehr auf ein einzelnes Scrum Team das irgendwo in einer riesen tayloristischen Organisation arbeitet sondern es beginnt ein Umdenken was grosse Strukturen anbelangt. Ich freue mich auf die Veränderung!
 
Was bringt es einen Vortrag zu halten?
Ich empfinde es persönlich immer als einen "agile Methode Entwicklungssprint". Es fängt mit der Vorbereitung an die sehr viel Selbstreflektion erfordert. Das versuchen wir auch immer im "pair programming" zu machen, denn 2 kommen immer auf die bessere Idee als Einer. Mit dem shipable gehen wir dann ins Review - dem eigentlichen Vortrag.
Aus dem Feedback / den Fragen zum Vortrag entstehen immer gute Anregungen für das weitere agile Arbeiten.

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.