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.
Frank Lange, PM Forum Nürnberg 30.10.2013 
Scrum in der Medizintechnik – 
Dürfen wir das überhaupt?
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
. 
“Einen Konflikt zu verstehen, heißt bereits ihn zu lösen.” Theory of Constraints 
Konfliktlösungen durch ein tieferes V...
. 
Software-Lebenszyklus-Prozess-Norm (EN 62304) 
Verständnis-Konflikte 
u Symptome: „Die Norm fordert das V-Modell!“ 
„W...
Qualitätsmanagement-Norm (ISO 13485) 
Rollenkonflikte 
u Symptom: „In Scrum macht doch jeder was er will, 
keiner achtet ...
. 
Risikomanagement-Norm (ISO 14971) 
Wertekonflikte 
u Symptom: „In Scrum wird nichts dokumentiert, 
obwohl die Normen d...
. 
Gebrauchstauglichkeitsnorm (EN 62366) 
Konfliktpotential: Verunsicherte Stakeholder 
u Symptom: „Scrum ist rein techni...
Agiles V-Modell
Zeitlicher Verlauf der Scrum-Einführung 
Phase 1: Chaos (mehrere Monate) 
u Hohe Aufwände für Teamfindung 
u Unklare Rol...
Zeitlicher Verlauf der Scrum-Einführung 
Phase 2: Quick Wins 
u Sichtbare Ergebnisse am Sprintende 
u Sprintziele werden...
Zeitlicher Verlauf der Scrum-Einführung 
Phase 3: Langfristiger Erfolg 
u Konsequente Lösung von Impediments 
u Zusammen...
Vielen Dank für 
Ihre Aufmerksamkeit! 
consanis.de 
frank.lange@consanis.de
Nächste SlideShare
Wird geladen in …5
×

Scrum in der Medizintechnik - Dürfen wir das überhaupt? (CONSANIS)

631 Aufrufe

Veröffentlicht am

Scrum in der Medizintechnik - Dürfen wir das überhaupt? (CONSANIS)

Consanis - die Nr. 1 für Agile Methoden in der Medizintechnik
http://www.consanis.de

Veröffentlicht in: Business
  • Als Erste(r) kommentieren

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

Scrum in der Medizintechnik - Dürfen wir das überhaupt? (CONSANIS)

  1. 1. Frank Lange, PM Forum Nürnberg 30.10.2013 Scrum in der Medizintechnik – Dürfen wir das überhaupt?
  2. 2. Konflikt: Sicherheit oder Wandel?
  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. Normen zur Softwareentwicklung in der Medizintechnik
  9. 9. . “Einen Konflikt zu verstehen, heißt bereits ihn zu lösen.” Theory of Constraints 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
  10. 10. . Software-Lebenszyklus-Prozess-Norm (EN 62304) Verständnis-Konflikte u Symptome: „Die Norm fordert das V-Modell!“ „Wir haben schon immer das V-Modell benutzt!“ u Ursache: Unsicherheit bzgl. der „mächtigen“ Normen à Fehlinterpretation. (Die Norm fordert 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.
  11. 11. Qualitätsmanagement-Norm (ISO 13485) Rollenkonflikte u Symptom: „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ösungsansatz: 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. .
  12. 12. . Risikomanagement-Norm (ISO 14971) Wertekonflikte u Symptom: „In Scrum wird nichts dokumentiert, obwohl die Normen das fordern!“ u Ursache: Fehlinterpretation des zweiten Punkts des agilen Manifests. à Verteidigungshaltung in beiden „Lagern“ Lösungsansatz: 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.
  13. 13. . Gebrauchstauglichkeitsnorm (EN 62366) Konfliktpotential: Verunsicherte Stakeholder u Symptom: „Scrum ist rein technisch, Kunden werden nicht eingebunden!“ u Ursache: Entwickler lieben Scrum UND Technik à Stakeholder halten Scrum für 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.
  14. 14. Agiles V-Modell
  15. 15. Zeitlicher Verlauf der Scrum-Einführung 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 .
  16. 16. Zeitlicher Verlauf der Scrum-Einführung 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 .
  17. 17. Zeitlicher Verlauf der Scrum-Einführung 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! .
  18. 18. Vielen Dank für Ihre Aufmerksamkeit! consanis.de frank.lange@consanis.de

×