Wesentlicher Treiber agiler Denk- und Vorgehensweisen ist die immer wettbewerbsorientiertere Marktsituation vieler Unternehmen. Geschwindigkeit, Flexibilität und Agilität am Markt sind wichtige und kritische Erfolgsfaktoren. Für Unternehmen bedeutet dies hoher Zeitdruck in Entwicklungsprojekten und kürzere Entwicklungsloops. Damit verbunden wird die Notwendigkeit von frühzeitigen Kundenfeedbacks obligatorisch. Gleichzeitig steigen die Aufwände durch die Regulierung der Behörden stetig.

Anfang der 90er Jahre erstmals angewandt, haben sich agile Prinzipien vorwiegend in der Softwareentwicklung etabliert. Im Fachgebiet Mechatronik gelten zwar Methoden wie «Lean-Production» oder «Just-In-Time» als „state-of-the-art Methods“. Die Produktentwicklung selbst – der eigentliche Innovationsprozess – bedient sich aber weitgehend alteingesessener Hilfsmittel und Denkweisen.

Welche Chancen und Risiken birgt der agile Ansatz in der Entwicklung eines mechatronischen Systems?

Es folgt ein Erfahrungsbericht unseres Mitarbeiters David Huber, Projektleiter / Mechanical Engineer, am Beispiel einer Medizinprodukteentwicklung. Die Erfahrungen basieren auf einem Projekt zur Neuentwicklung eines Instruments innerhalb eines interdisziplinären Entwicklungsteams. Dieses Entwicklungsteam hatte vor dem Projekt keine Erfahrungen mit agilen Entwicklungsmethoden.

Scrum – Erfahrungsbericht zur Implementierung

Das Projekt startete mit einer zweitägigen Schulung über die agilen Prinzipien und Grundsätze der Scrum-Methodik. Die Inhalte: Arbeitsprozesse und -Methoden ändern, Rollen und Verantwortlichkeiten neu vergeben.

Abbildung 1: Scrum-Method Overview

Eine gründliche Schulung aller involvierten Mitarbeiter des Scrum-Konzepts ist unabdingbar. Die Mitarbeitenden müssen ihre neue Rolle, ihre neue Verantwortlichkeit und den Sinn der neuen Arbeitsweise nicht nur verstehen, sondern respektieren und aktiv mitgestalten. Auch ich benötigte  Zeit, das neu Gelernte umzusetzen und mich von gewohnten Mustern, Prozessen und Strukturen zu lösen. Nicht nur die Arbeitweise des Teams wird verändert. Auch die bestehende Prozesslandschaft wird der Scrum-Philosophie angepasst. Zentral ist dabei die Klärung der Schnittstellen zu anderen Stakeholdern des Projektes, damit der fortwährende Informationsaustausch sichergestellt werden kann. Nur unter diesen Voraussetzungen lassen sich die neuen Methoden und Prozesse effizient umsetzen und anwenden.

Essentiell: klare Rollenverteilung in der agilen Systementwicklung

Im Sprint Planning werden die zu erledigenden Arbeitspakete, die sogenannten Backlog-Items, in Form von Stories auf das Team verteilt. Wir schätzen gemeinsam im Team ein, wie lange ein Backlog-Item benötigt, entscheiden ob es als Story abzuarbeiten ist oder ob es ein Epic ist. Ein Epic ist zu umfangreich, um den zeitlichen Aufwand genau abschätzen zu können. Daher muss es in kleinere Teile, welche sich wiederum als Story eignen, aufgesplittet werden. Schlussendlich verpflichtet sich jedes Teammitglied, die ausgewählten Stories innerhalb eines Sprints abzuarbeiten.

Ich finde es spannend, dass das Entwicklungsteam regelmäßig in die Planungstätigkeiten eingebunden wird. Allerdings fällt es einigen Teammitgliedern schwer, sich für die Menge an Arbeit in einem zeitlichen Rahmen eines Sprints zu verpflichten. Dies kann soweit führen, dass sich Ingenieure dem Scrum komplett verweigern. Oder langwierige Diskussionen während der Scrum Meetings entstehen. In diesen Fällen fällt dem Scrum Master die wichtige Aufgabe zu, mit viel Fingerspitzengefühl geeignete Lösungen zu finden. Auch muss er sicherstellen, dass das Team keine kurzfristigen dringenden Aufgaben aus anderen Projekten oder Bereichen bearbeiten muss. Andernfalls können die Sprints nicht termingerecht abgeschlossen werden.

Zur Bestandsaufnahme gibt es das Daily Scrum. Dies ist der Informationsaustausch und der Abgleich innerhalb des Teams. Das Meeting soll allerdings nicht der Problemlösung dienen. Auch hier muss der Scrum Master gelegentlich intervenieren, damit der Fokus während der kurzen 15 Minuten nicht verloren geht.

Die einzelnen Sprints werden auf dem elektronischen Scrum-Board festgehalten, terminiert und den zuvor vereinbarten Personen zugeteilt. Die Arbeit mit einem elektronischen Scrum-Board bietet den Vorteil, dass der Projektfortschritt in Echtzeit ausgewertet wird. Zum Beispiel mit Hilfe eines „Burn-Down-Charts“. Somit kann ich die aktuellen Sprints, die Backlogs und die bereits erreichten Product Increments bequem von meinem Arbeitsplatz aus einsehen.

Der Product Owner setzt Prioritäten

Dem Projektleiter fällt die Rolle des Product Owners zu. Dieser ist für die Definition und Priorisierung des Backlogs (Arbeitsvorrat) und der Sprints zuständig. Jedem Sprint fügt unser Product Owner die bereits erwähnte Story hinzu, welche den Inhalt und die Ziele des entsprechenden Arbeitspakets definiert. Dies ist jedoch in der Mechanikentwicklung – im Gegensatz zur Softwareentwicklung – oft schwierig. Komplexe Konstruktionsarbeiten beispielsweise lassen sich nicht auf einen zeitlich eng begrenzten Sprint runterbrechen. Genauso schwierig wird es mit dem Determinieren von Lieferterminen von Bauteilen und Elektronikkomponenten. Lange Lieferzeiten und Lieferverzögerungen können auch in einer agilen Welt nicht ausgeschlossen werden.

Besonderheit: Das Erstellen eines Prototypen

Eine weitere Herausforderung zeigt sich beim Aufbau der Prototypen. Während bei einem Software-Produkt Änderungen oft sehr gezielt und zeitnah durchführbar sind, sind Nacharbeiten bei einem mechanischen Aufbau oft mit einem massiv höheren Arbeits- und Zeitaufwand verbunden. Schließlich kann ein Bauteil durch ein anderes Bauteil oft erst nach aufwendiger Demontage- und Nacharbeit ausgetauscht werden. Hier sind die agilen Prinzipien und Arbeitsweisen bei der Softwareentwicklung deutlich praktikabler anwendbar, als bei einem mechanischen Produkt.

Informationsfluss von zentraler Bedeutung

Ein wichtiges Element der Arbeit mit Scrum ist der regelmäßige Informationsaustausch zwischen den verschiedenen Abteilungen, sowie dem Kunden. In unserem Fall hat besonders das Requirements Management zu ausgiebigen internen Diskussionen geführt. Typischerweise werden in der klassischen Vorgehensweise Requirements klar definiert und dokumentiert. In der Scrum Methodik jedoch, entstehen mit jedem Sprint neue Erkenntnisse, welche zu Änderungen an den bestehenden Anforderungen führen. Dadurch entstand ein intensiver Dialog mit angrenzenden Disziplinen wie Regulatory Affairs und Quality.

Neben der interdisziplinären Kommunikation ist auch der Informationsfluss zum Management von zentraler Bedeutung. Trotz agiler Freiheiten im Team, werden Zahlen und Fakten bezüglich Projektfortschritt, Ressourcenbedarf und Budget eingefordert. Aufgrund der Scrum-Methodik sind hier klare Antworten aber nicht immer wie gewünscht lieferbar.

Fazit: Herausforderungen durch Scrum

Ich habe für mich aus der agilen Systementwicklung mitgenommen, Funktionen so früh wie möglich zu testen, damit ich direkt Feedback zu meinen erarbeiteten Product Increments erhalte. Auch erlaubt mir die Scrum Methodik, mich besser auf die inhaltlichen Entwicklungsziele während eines Sprints zu fokussieren. Die Planung der Ressourcen und übergeordneten Meilensteine gestalten sich jedoch schwieriger als ich es aus dem klassischen Entwicklungsprozess gewohnt bin. Auch die konforme Einbindung des Vorgehens im regulierten Umfeld ist vorab gut zu organisieren und mit den entsprechenden Abteilungen wie Regulatory Affairs und Quality festzulegen. Weiterhin ist das Schreiben von sinnvollen Stories anspruchsvoll und sollte von erfahrenen Product Ownern geschrieben werden. Durch die klaren Ziele eines Sprints, können Kunden und sonstige Stakeholder schnell anhand der erarbeiteten Product Increments Feedback geben, welches sofort wieder in den Entwicklungsprozess einfließt.

Sie wollen sich mit uns zum Thema Scrum austauschen? Oder haben Sie selbst ein Projekt, das Sie mit unserer Unterstützung auf den Weg bringen wollen? Dann melden Sie sich bei uns:

David Huber

Projektleiter / Mechanical Engineer

konplan systemhaus ag

gemeinsames entwickeln! Wir setzen Ihre Ideen in die Tat um und begleiten Ihre Vorhaben bis zur Marktreife. Nehmen Sie jetzt Kontakt mit unseren Experten auf.