Produkt
Optoelektronisches Messgerät
Ausgangslage / Ziele
Für ein gängiges Messprinzip sollte durch eine deutlich verfeinerte Sensorik ein komplett neuer Anwendungsfall erschlossen werden. Das Unternehmen hatte viel Erfahrung mit der Messtechnik, für das spezielle Vorhaben wurde jedoch hinsichtlich der erforderlichen Auswertung der Messdaten mit externen Wissenschaftlern zusammengearbeitet. Mit Messungen an der Grenze physikalischen Machbarkeit und wenig interner Erfahrung mit der Datenauswertung sollte SCRUM für die Entwicklung eines solchen physischen Produkts erprobt werden. Ziel war es, einen funktionsfähigen Prototyp für einen Referenzkunden zu erstellen um neben der technischen Machbarkeit auch die Marktchancen zu evaluieren.
Setting
- Crossfunktionales Team Software-Entwicklern, Elektronikern, Physikern und einem Konstrukteur
- Alle Teammitglieder zu 80% (4 Tage pro Woche) für das Scrum Team abgestellt (harte Trennung auf Tagesebene, keine Durchmischung der Aufgaben pro Tag)
- Sprintlänge 2 Wochen
- Inkrement: Funktionsfähiges Messgerät
- Scrum Master und Product Owner entwickeln mit
Erkenntnisse
Die intensive zeitliche und räumliche Zusammenarbeit war zunächst ungewohnt und verursachte ein ausgeprägtes Teambuilding mit anfänglichen Konflikten; über die ersten Sprints ist jedoch ein motiviertes Team entstanden. Ziel war aufgrund der unklaren Anforderungen und Umsetzung möglichst früh ein funktionierendes System aufzubauen. Es gelang, das erste Messgerät bereits nach 5 Sprints in Betrieb zu nehmen, dieses bestand aus frei am Markt verfügbaren Komponenten, noch ohne die eigene, in Entwicklung befindliche Sensorik. So konnten die Software-Entwickler im, Team sehr früh mit der Umsetzung der Auswertelogik beginnen. Durch die modulare Systemarchitektur konnten einzelne Komponenten gegen eigene Komponenten getauscht und innerhalb der Sprints iterativ-inkrementell weiterentwickelt werden. Die Bedeutung der iterativen Entwicklung und der ständigen Verfügbarkeit eines funktionsfähigen Prototypen wurde nach einigen Monaten noch einmal unterstrichen: Durch einen Wechsel des Referenzkunden sollte das Produkt nun mit komplett anderen Anforderungen einen anderen Business-Case bedienen. Scrum, in Verbindung mit dem Fokus auf das funktionierende Inkrement, hat diesen Kurswechsel deutlich erleichtert. Die einschneidende Veränderung war letztendlich eher ein Motivationsproblem im Scrum Team als ein Herausforderung bezüglich Technologie und Zeitplan.
Edit: Leider habe ich das Ergebnis des Vorhabens nicht mehr mitbekommen. Ich weiß nur, dass nach 1,5 Jahren ein Stand für die weitere Entscheidung erreicht war. Ob daraus ein Auftrag bei den Referenzkunden entstanden ist, entzieht sich meiner Kenntnis. Meine Kontakte zum Team habe ich wie vorgesehen über ein Jahr Schritt für Schritt reduziert. Das Scrum Team ist selbständig und gut geworden. So soll es sein.
Hindernisse
Der Ansatz, alles so optimal wie möglich zu gestalten, hat sich bewährt. Hinsichtlich Team, Infrastruktur und Inkrement war das Setting recht nah an der Intention von Scrum. Leider wurde während des Projektes ein paralleles Projekt durch das Management gestartet, so dass sich einzelne Team-Mitglieder zwischen zwei Scrum Teams aufspalten mussten. Diese Veränderung der Rahmenbedingungen, hat keines der nun beiden Teams im Optimum belassen. Das Vorkommnis hat bestätigt, wie wichtig es ist, das Verständnis von Fokus und WIP-Limitierung nicht nur auf der operativen Ebene umzusetzen, sondern den Ebenen über der Entwicklung zu vermitteln.