This entry is part 1 of 1 in the series Hardware Scrum
  • Ein Hardware Scrum Hackathon

Natürlich funktioniert Scrum auch für Hardware- und Systementwicklung. Dafür gibt es inzwischen genügend erfolgreiche Beispiele, viele an denen HOOD aktiv mitgearbeitet hat. Klar, es gibt ein paar Besonderheiten und einige Herausforderungen sind anders gelagert als in reinen Softwareentwicklungen, aber der Methoden-Bauchladen ist inzwischen voll genug um für unterschiedlichste Domänen passende Praktiken anbieten zu können. Einen signifikanten Unterschied gibt es aber nach wie vor in der Menge an Skepsis, die uns entgegen schlägt, wenn wir HW- und Systemingenieure in der agilen Transformation begleiten. Dabei ist der Wunsch, in kürzeren Zyklen risikoärmer auf Kundenfeedback reagieren zu können, durchaus genauso stark ausgeprägt wie bei den Softwareentwicklern.

Wie können wir Entwicklern, die gern Hardware-Scrum einsetzen wollen das nötige argumentative Rüstzeug mit auf den Weg geben, mit dem sie den Bedenkenträgern in ihrer Organisation den Wind aus den Segeln nehmen können?

Diese Frage habe ich mir gestellt, als ich über meinen Beitrag zur Agile Systems Konferenz (ASK) nachgedacht habe.

Nun, nichts ist überzeugender als eigene positive praktische Erfahrung. Die Idee des Hardware-Scrum Hackathons war geboren.

Ziel ist es also, im Rahmen eines Workshop-Tages den Teilnehmern die eigene Anwendung der Methodik an einem realitätsnahen Beispiel-Entwicklungsgegenstand zu ermöglichen. Nun ist ein Tag (der erste Tag der ASK ist für Impuls-Vorträge und Open-Space reserviert) schon extrem wenig Zeit, um nicht nur die Besonderheiten des Hardware-Scrum Setups zu üben, sondern nebenher auch noch eine echte kleine Entwicklung durchzuführen, die aber trotzdem genügend Facetten besitzt, um die Transferleistung auf reale Systeme leicht zu machen. Natürlich kann es in 8 Stunden nicht gelingen, alle Aspekte agiler Systementwicklung zu adressieren. Der Scope muss begrenzt bleiben. Selbstorganisation, Teamentwicklung, Umgang mit Änderungen und Führungskultur sollen in diesem Workshop nicht im Vordergrund stehen, denn hierzu gibt es so gut wie keine grundsätzlichen Unterschiede zu reinem Software-Scrum, und wir haben zu diesen Themen bei HOOD bereits sehr gute Formate im Angebot, z.B. den Agile Sandbox Workshop.

Obwohl auch gerade in der Systementwicklung hochgradig relevant, so muss aufgrund von Zeit und Rahmen das Thema Large-Scale-Scrum dennoch leider außen vor bleiben. Auch dazu haben wir aber andere Angebote, wie Leading SAFe und unser Fortgeschrittenen-Training, in dem speziell auch agiles Vorgehen bei Arbeitsteiligkeit zwischen OEM und Lieferanten Tiers adressiert wird.

Was soll also in unserem Hackathon im Fokus sein?

Unsere Beispiel-Entwicklung soll aufzeigen und erlebbar machen, dass

  • sich auch für Hardware Anforderungen so schneiden lassen, dass End-to-End Features bzw. User-Stories mit realem Kundenwert sichtbar werden
  • Safety-Aspekte nicht im Widerspruch zum agilen Vorgehen stehen
  • die (z.B. für die Zulassung) erforderliche Dokumentation im Rahmen der Sprints erstellt werden kann und muss
  • am Ende eines Sprints potenziell lieferbare Systeme demonstriert werden können.

Die Teilnehmer werden im Hackathon in 3er Teams ein Beispiel-Produkt aus Elektronik, etwas Mechanik und Software selbst entwickeln. In 3 bis 4 Sprints werden im Laufe des Tages Features realisiert und die zugehörige Safety-Betrachtung (angelehnt an ISO61508, leicht übertragbar z.B. auf ISO26262) durchgeführt und kompakt dokumentiert.

Als Product Owner werden wir die Vision und den Backlog vorstellen und den Teilnehmern helfen, daraus passende Stories für den nächsten Sprint abzuleiten. Wie viele Features umgesetzt werden können, hängt natürlich stark vom Vorwissen der Teilnehmer ab – wir sind schon sehr neugierig und freuen uns auf eine diverse, crossfunktionale Gruppe. Die Teilnahmevoraussetzungen halten wir bewusst gering, lediglich etwas Mut zum Ausprobieren und keine Abneigung gegen etwas elektronische Bastelei, und ein paar Zeilen Software-Code sollten vorhanden sein. Alle erforderlichen Bauteile und Funktionsaufrufe werden wir erklären. Die Gesamtzahl der Teilnehmer werden wir aber begrenzen, damit die Betreuung durch unsere Coaches und Scrum Master gewährleistet ist. Nicht zuletzt soll der Hackathon auch Spaß machen – spielerische Aspekte kommen nicht zu kurz und wir freuen uns auch auf unkonventionelle und überraschende Lösungsmöglichkeiten der Teilnehmer-Teams.

Es war nicht leicht ein passendes Beispiel zu finden. Inzwischen sind unsere Vorbereitungen aber in vollem Gange.

In die Vision des Produkt-Beispiels und den Verlauf unserer Hackathon Vorbereitung gebe ich in einem weiteren Blogartikel an dieser Stelle einen Einblick.