Das Eisberg-Prinzip



Die 4 Ebenen des Widerstands bei der Einführung
von Scrum in der Medizintechnik





Frank Lange

C...
Herausforderungen im Gesundheitswesen
u Steigender Kostendruck
u Komplexe Gesamtsysteme (integrierte Workflows statt Ein...
Konflikt: Sicherheit oder Wandel?
Konflikt: Sicherheit oder Wandel?
Konflikt: Sicherheit oder Wandel?
Konflikt: Sicherheit oder Wandel?
Konflikt: Sicherheit oder Wandel?
Konflikt: Sicherheit oder Wandel?
Normen zur Softwareentwicklung in der Medizintechnik
Konfliktlösungen durch ein tieferes Verständnis…
u … der Normen und ihrer Freiheiten
u … der Rollen von Scrum
u … der W...
Software-Lebenszyklus-Prozess-Norm (EN 62304)
u Vorurteil: „Die Norm fordert das V-Modell!“
„Das haben wir schon immer so...
Qualitätsmanagement-Norm (ISO 13485)
u Vorurteil: „In Scrum macht doch jeder was er will,
keiner achtet mehr auf Qualität...
Risikomanagement-Norm (ISO 14971)
u Vorurteil: „In Scrum wird nichts dokumentiert,
obwohl die Norm das fordert!“
u Ursac...
Gebrauchstauglichkeitsnorm (EN 62366)
u Vorurteil: „Scrum ist rein technisch,
Kunden werden nicht eingebunden!“
u Ursach...
Agiles V-Modell
Phase 1: Chaos (mehrere Monate)
u Hohe Aufwände für Teamfindung
u Unklare Rollenaufteilung
u Instabile Velocity
u Flac...
Phase 2: Quick Wins
u Sichtbare Ergebnisse am Sprintende
u Sprintziele werden erreicht
u Stakeholder besuchen öffentlic...
Phase 3: Langfristiger Erfolg
u Konsequente Lösung von Impediments
u Zusammenwachsen mehrerer Teams
u Etablierter konti...
Vielen Dank für
Ihre Aufmerksamkeit!
consanis.de
frank.lange@consanis.de
Nächste SlideShare
Wird geladen in …5
×

Das Eisberg Prinzip - die 4 Ebenen des Widerstands bei der Einführung von Scrum in der Medizintechnik

1.334 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Leadership & Management
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.334
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
73
Aktionen
Geteilt
0
Downloads
3
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Das Eisberg Prinzip - die 4 Ebenen des Widerstands bei der Einführung von Scrum in der Medizintechnik

  1. 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. 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)
  3. 3. Konflikt: Sicherheit oder Wandel?
  4. 4. Konflikt: Sicherheit oder Wandel?
  5. 5. Konflikt: Sicherheit oder Wandel?
  6. 6. Konflikt: Sicherheit oder Wandel?
  7. 7. Konflikt: Sicherheit oder Wandel?
  8. 8. Konflikt: Sicherheit oder Wandel?
  9. 9. Normen zur Softwareentwicklung in der Medizintechnik
  10. 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. 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. 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. 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. 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 .
  15. 15. Agiles V-Modell
  16. 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. 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. 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 .
  19. 19. Vielen Dank für Ihre Aufmerksamkeit! consanis.de frank.lange@consanis.de

×