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)

516 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
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
516
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
75
Aktionen
Geteilt
0
Downloads
2
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

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

×