Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

3,181 views

Published on

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

Published in: Health & Medicine
  • accessibility Books Library allowing access to top content, including thousands of title from favorite author, plus the ability to read or download a huge selection of books for your pc or smartphone within minutes DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download Full EPUB Ebook here { http://bit.ly/2m6jJ5M } ......................................................................................................................... ...................................ALL FOR EBOOKS................................................. Cookbooks, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

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

×