Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
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.556 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
  • Als Erste(r) kommentieren

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

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

×