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.
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.781 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Gesundheit & Medizin
  • 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. 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

×