Für die Weiterentwicklung von bestehenden Geräten zu einem zusammengehörenden System sollten innerhalb der Abteilung Forschung und Entwicklung crossfunktional und übergeordnet zusammengearbeitet werden.

beteiligte Personen: 70

Zeitrahmen: 12 Monate

Ausgangslage:
Die bisherige Hardware-Entwicklung bestand darin, dass einzelne Techniker Konzepte zu Neu- und Weiterentwicklung von Geräten erstellten. Aus genehmigten Konzepten wurden Projekte, in denen Personen aus anderen Fachbereichen mit zum Teil geringer Kapazität mitarbeiteten. Dadurch waren die meisten Personen prallel in einer Vielzahl von Projekten in unterschiedlichen Stadien der Entwicklung. Eine konstate Kommunikation wurde nicht gelebt und es kam zu häufigen Missverständnissen zwischen den Fachbereichen. Eine Priorisierung von Anforderungen war nicht gegeben.

Ziele des Projekts/des Auftraggebers:
Vier Produktteams sollten aus drei bestehenden Geräten und einer Neuentwicklung ein zusammengehörendes System entwicklen, welches innerhalb eines Jahres zur Serienreife gebracht werden kann.

zentrale Fragen und Herausforderungen:
Bereits in der Vorentwicklung die beteiligten Fachbereiche von F&E zusammenzuführen, hat zu einer hohen Komplexität geführt, die nur langsam von den Teams durchdrungen wurde. Die Einbindung vom Fachbereich Design in dieser frühen Entwicklungsphase war ein vollkommenes Novum. Transparenz und regelmäßige Kommunikation zwischen den Produktteamskonnte erst nach einiger Zeit erreicht werden.

Methoden und grundsätzliches Vorgehen:

1. Zusammenstellung der Produktteams
Jedes Produktteam enthielt aus jedem notwendigen Fachbereich ein festes Teammitglied, welches mindestens 50% seiner Kapazitäten ausschließlich für dieses Team aufbringen konnte. Dies war nicht für Spezialisten gegeben, die nicht die ganze Zeit für die Entwicklung benötigt wurden. Diese Spezialisten standen in einer Supportfunktion zur Verfügung und hatten die Aufgabe, sich proaktiv kontinuierlich über den Stand der Entwicklung auf dem Laufenden zu halten.

2. Einführung eines Arbeitsmodus
Die Produktteams entschieden sich individuell für ein Vorgehen nach Scum. Die Länge der Sprints passte jedes Team seinen eigenen Bedürfnissen an, hielten aber an einem gemeinsamen Review alle 4 Wochen fest. Die Product Owner der einzelnen Teams erstellten ein gemeinsames Backlog, in dem sie Abhängigkeiten darstellten.

3. Einführung von Etappenplanung
Bereits nach zwei Sprints stellte sich heraus, dass die Anforderungen an das System aus dem Produktmanagement, dem Fachbereich Qualitätssicherung und dem Vorstand zu komplex waren, um sie unstrukturiert einzusteuern. Produktmanagement und Stakeholder wurden in agilem Arbeiten geschult und entwickelten ein priorisiertes Etappen-Backlog nach Quartalen. Gemeinsam mit den Product Ownern wurde ein Obeya Room eingerichtet.

4. Einbindung von Abteilungen
Bei voranschreitender Entwicklung und hohem Bekanntheitsgrad der übergeordneten Reviews traten zunehmend Abteilungen außerhalb von F&E an die Produkt Owner heran. So schaffte bspw. die Prototypen-Werkstatt über ein neu eingeführtes Kanban-System Transparenz über Fortschritt und Priorität der eingehenden Aufträge. Die Abteilung Logistik unterstützte die Produktteams als Berater, indem sie die Auswirkungen von Gerätegrößen auf den internationalen Transport aufzeigten. Die Abteilung Vertrieb und Marketing entwickelte und organiserte „Friendly User Tests“ für Prototypen und Design.

5. Übergang in ein anderes System
Nach Abschluss der Entwicklungsphase und Erreichung der Serienreife wurden die Produktteams aufgelöst. Im Zuge eines abschließenden Planungsmeetings zum weiteren Vorgehen mit allen Product Ownern, Produktmanagern und Stakeholdern wurde die Umsetzung der Serienfertigung mit dem bestehenden Prozessen weitergeführt. Teilweise übernahmen die Product Owner die Begleitung der Produkte durch die Serienfertigung als Projektmanager und nahmen erlernte Praktiken zu Transparenz und Kommunikation in ihre neue Aufgabe mit.