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

1. Scrum in der Medizintechnik –
Dürfen wir das überhaupt?
Frank Lange, PM Forum Nürnberg 30.10.2013

2. Konflikt: Sicherheit oder Wandel?

3. Konflikt: Sicherheit oder Wandel?

4. Konflikt: Sicherheit oder Wandel?

5. Konflikt: Sicherheit oder Wandel?

6. Konflikt: Sicherheit oder Wandel?

7. Konflikt: Sicherheit oder Wandel?

8. Normen zur Softwareentwicklung in der Medizintechnik

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. 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. 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. 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. 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. Agiles V-Modell

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. 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. 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. Vielen Dank für
Ihre Aufmerksamkeit!
consanis.de
frank.lange@consanis.de