Die Medizintechnik steht vor neuen Herausforderungen: Produktentwicklungszyklen werden immer kürzer, Anforderungen ändern sich immer später im Projekt - ein ideales Einsatzfeld für Scrum.
Doch in Unternehmen in denen das V-Modell seit vielen Jahren stabil läuft, stößt der Change-Prozess hin zu agilen Methoden auf deutlichen Widerstand. Praxisnah zeigt dieser Vortrag an Hand eines real durchgeführten Changes 4 verschiedene Widerstandebenen auf. Zu jeder dieser Widerstandsebenen werden Symptome, Ursachen, und Lösungsansätze herausgearbeitet, die auch in anderen Medizintechnik-Unternehmen leicht erkenn- und umsetzbar sind.
Die 4 Widerstandsebenen haben einen direkten Zusammenhang zu 4 wichtigen Normen der Medizintechnik: Der SW-Lebenszyklusprozess-Norm EN 62304, der Risikomanagement-Norm ISO 14971, der Qualitätsmanagement-Norm ISO 13485 und der Gebrauchstauglichkeitsnorm EN 62366. Die oberste der 4 Ebenen ist rein sachlich, in den darunter liegenden geht es um immer tiefere gehende Konflikte: Um Rollenkonflikte, Wertekonflikte und schließlich um Urängste von Menschen - daher der Name „Eisberg-Prinzip“.
Die Konfliktebenen sind speziell in Medizintechnik-Unternehmen besonders stark ausgeprägt, da ein Wandel von V-Modell hin zu Scrum auch mit einem Wandel von „Stabilität“ hin zu mehr „Flexibilität“ einhergeht.
Agile (Software-) Prozesse - Quo Vadis? [in German]
Das Eisberg Prinzip - die 4 Ebenen des Widerstands bei der Einführung von Scrum in der Medizintechnik
1. Das Eisberg-Prinzip
Die 4 Ebenen des Widerstands bei der Einführung
von Scrum in der Medizintechnik
Frank Lange
Consanis GmbH
Agile Med 2014 , 19.02.2014 München.
2. Herausforderungen im Gesundheitswesen
u Steigender Kostendruck
u Komplexe Gesamtsysteme (integrierte Workflows statt Einzelprodukte) UND
Einfache Handhabung (Vergleich mit Consumer-Produkten)
u Hohe Dynamik (Kurze Entwicklungszyklen, häufige Anforderungsänderungen) UND
Starre Entwicklungsabläufe (regulierter Markt, hohe Qualitätsanforderungen)
10. Konfliktlösungen durch ein tieferes Verständnis…
u … der Normen und ihrer Freiheiten
u … der Rollen von Scrum
u … der Werte hinter Scrum und den Normen
u … der Wünsche und Ängste aller Stakeholder
“Einen Konflikt vollständig zu verstehen, heißt bereits ihn zu lösen.”
(Theory of Constraints)
.
11. Software-Lebenszyklus-Prozess-Norm (EN 62304)
u Vorurteil: „Die Norm fordert das V-Modell!“
„Das haben wir schon immer so gemacht!“
u Ursache: Unsicherheit bzgl. der „mächtigen“ Normen
à Fehlinterpretation (Die Norm fordert lediglich
einen „festgesetzten Entwicklungsprozess“)
Lösungsansatz: Schrittweise Umstieg auf Scrum ohne Verletzung der Normen.
u Kurzfristig: Scrum nur im unteren Teil des V-Modells einsetzen.
u Langfristig: Kompletten Entwicklungsprozess auf Scrum umstellen.
1. Ebene des Widerstands
Verständniskonflikte
.
12. Qualitätsmanagement-Norm (ISO 13485)
u Vorurteil: „In Scrum macht doch jeder was er will,
keiner achtet mehr auf Qualität!“
u Ursache: Rollen-Unsicherheit
(„Wer ist denn jetzt bei euch der Projektleiter?“)
à Alte Denkstrukturen benötigen einen „Schuldigen“
Lösung: Tieferes Verständnis der Rollen in Scrum
u Team ist verantwortlich für die Umsetzung („Wie“) à Harte Definition of Done
u Scrum Master ist verantwortlich für die Einhaltung der Regeln
u Product Owner ist verantwortlich für Produktinhalt („Was“)
à Die Verantwortung bleibt bestehen, sie ist nur auf neue Rollen verteilt.
2. Ebene des Widerstands
Rollenkonflikte
.
13. Risikomanagement-Norm (ISO 14971)
u Vorurteil: „In Scrum wird nichts dokumentiert,
obwohl die Norm das fordert!“
u Ursache: Fehlinterpretation des zweiten Punkts
des agilen Manifests.
à Verteidigungshaltung in beiden „Lagern“
Lösung: Tieferes Verständnis des agilen Manifests
u Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
u Funktionierende Software ist wichtiger als umfassende Dokumentation.
u Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
u Eingehen auf Veränderungen ist wichtiger als Festhalten an einem Plan.
3. Ebene des Widerstands:
Wertekonflikte
.
14. Gebrauchstauglichkeitsnorm (EN 62366)
u Vorurteil: „Scrum ist rein technisch,
Kunden werden nicht eingebunden!“
u Ursache: Entwickler lieben Scrum UND Technik
à Stakeholder halten Scrum für rein technisch.
à Stakeholder fühlen sich ausgegrenzt
Lösungsansatz: Scrum über professionellen Change-Prozess einführen
u Stakeholdermanagement: Für Vorteile der agilen Herangehensweise „werben“.
u Transparenz: Fehler erkennen, offenlegen und beheben.
4. Ebene des Widerstands
Tief sitzende menschliche Urängste
.
16. Phase 1: Chaos (mehrere Monate)
u Hohe Aufwände für Teamfindung
u Unklare Rollenaufteilung
u Instabile Velocity
u Flache Erfolgskurve
u Außenwahrnehmungen
• „Team schottet sich ab
(gegenüber der restlichen Organisation)“
• „Methode / Team ist wichtiger als Projekt / Produkt“
à Fehlender Erfolg ist für alle Beteiligten transparent
Zeitlicher Verlauf der Scrum-Einführung
.
17. Phase 2: Quick Wins
u Sichtbare Ergebnisse am Sprintende
u Sprintziele werden erreicht
u Stakeholder besuchen öffentliche Sprint-Demos
u Velocity weiterhin gering, aber zunehmend stabil
à Positive Außenwirkung
à Stakeholder fühlen sich abgeholt
Zeitlicher Verlauf der Scrum-Einführung
.
18. Phase 3: Langfristiger Erfolg
u Konsequente Lösung von Impediments
u Zusammenwachsen mehrerer Teams
u Etablierter kontinuierlicher Verbesserungsprozess
u Steigende Velocity, positive Feedbackschleifen
à Wachsende Begeisterung
à zufriedene Kunden!
Zeitlicher Verlauf der Scrum-Einführung
.