Scrum in der Medizintechnik –
Dürfen wir das überhaupt?
Frank Lange, PM Forum Nürnberg 30.10.2013
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...
Verständnis-Konflikte
u Symptome: „Die Norm fordert das V-Modell!“
„Wir haben schon immer das V-Modell benutzt!“
u Ursac...
Rollenkonflikte
u Symptom: „In Scrum macht doch jeder was er will,
keiner achtet mehr auf Qualität!“
u Ursache: Rollen-U...
Wertekonflikte
u Symptom: „In Scrum wird nichts dokumentiert,
obwohl die Normen das fordern!“
u Ursache: Fehlinterpretat...
Konfliktpotential: Verunsicherte Stakeholder
u Symptom: „Scrum ist rein technisch,
Kunden werden nicht eingebunden!“
u U...
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
×

Scrum in der Medizintechnik - dürfen wir das überhaupt? (Consanis)

2.417 Aufrufe

Veröffentlicht am

Scrum in der Medizintechnik - dürfen wir das überhaupt? (Consanis)

Veröffentlicht in: Gesundheit & Medizin
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
2.417
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
722
Aktionen
Geteilt
0
Downloads
3
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. Scrum in der Medizintechnik – Dürfen wir das überhaupt? Frank Lange, PM Forum Nürnberg 30.10.2013
  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. 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 zu verstehen, heißt bereits ihn zu lösen.” Theory of Constraints .
  10. 10. 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. Software-Lebenszyklus-Prozess-Norm (EN 62304) .
  11. 11. 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. Qualitätsmanagement-Norm (ISO 13485) .
  12. 12. 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. Risikomanagement-Norm (ISO 14971) .
  13. 13. 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. Gebrauchstauglichkeitsnorm (EN 62366) .
  14. 14. Agiles V-Modell
  15. 15. 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 .
  16. 16. 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 .
  17. 17. 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 .
  18. 18. Vielen Dank für Ihre Aufmerksamkeit! consanis.de frank.lange@consanis.de

×