SlideShare ist ein Scribd-Unternehmen logo
1 von 19
Downloaden Sie, um offline zu lesen
Das Eisberg-Prinzip



Die 4 Ebenen des Widerstands bei der Einführung
von Scrum in der Medizintechnik





Frank Lange

Consanis GmbH









Agile Med 2014 , 19.02.2014 München.

Herausforderungen im Gesundheitswesen
u Steigender Kostendruck
u Komplexe Gesamtsysteme (integrierte Workflows statt Einzelprodukte) UND
Einfache Handhabung (Vergleich mit Consumer-Produkten)
u Hohe Dynamik (Kurze Entwicklungszyklen, häufige Anforderungsänderungen) UND
Starre Entwicklungsabläufe (regulierter Markt, hohe Qualitätsanforderungen)
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 Werte hinter Scrum und den Normen
u … der Wünsche und Ängste aller Stakeholder
“Einen Konflikt vollständig zu verstehen, heißt bereits ihn zu lösen.”
(Theory of Constraints)
.
Software-Lebenszyklus-Prozess-Norm (EN 62304)
u Vorurteil: „Die Norm fordert das V-Modell!“
„Das haben wir schon immer so gemacht!“
u Ursache: Unsicherheit bzgl. der „mächtigen“ Normen
à Fehlinterpretation (Die Norm fordert lediglich
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.
1. Ebene des Widerstands
Verständniskonflikte
.
Qualitätsmanagement-Norm (ISO 13485)
u Vorurteil: „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ösung: 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.
2. Ebene des Widerstands
Rollenkonflikte
.
Risikomanagement-Norm (ISO 14971)
u Vorurteil: „In Scrum wird nichts dokumentiert,
obwohl die Norm das fordert!“
u Ursache: Fehlinterpretation des zweiten Punkts
des agilen Manifests.
à Verteidigungshaltung in beiden „Lagern“
Lösung: 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.
3. Ebene des Widerstands:
Wertekonflikte
.
Gebrauchstauglichkeitsnorm (EN 62366)
u Vorurteil: „Scrum ist rein technisch,
Kunden werden nicht eingebunden!“
u Ursache: Entwickler lieben Scrum UND Technik
à Stakeholder halten Scrum für rein 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.
4. Ebene des Widerstands
Tief sitzende menschliche Urängste
.
Agiles V-Modell
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
.
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
.
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
.
Vielen Dank für
Ihre Aufmerksamkeit!
consanis.de
frank.lange@consanis.de

Weitere ähnliche Inhalte

Andere mochten auch

Impuls Workshop: die brennendsten Probleme der Medizintechnik (MedConf 2014) ...
Impuls Workshop: die brennendsten Probleme der Medizintechnik (MedConf 2014) ...Impuls Workshop: die brennendsten Probleme der Medizintechnik (MedConf 2014) ...
Impuls Workshop: die brennendsten Probleme der Medizintechnik (MedConf 2014) ...Marc Bless
 
Agile Methoden und die Theory of Constraints
Agile Methoden und die Theory of ConstraintsAgile Methoden und die Theory of Constraints
Agile Methoden und die Theory of ConstraintsFrank Lange
 
Projektmanagement in der Medizintechnik
Projektmanagement in der MedizintechnikProjektmanagement in der Medizintechnik
Projektmanagement in der MedizintechnikChristian Johner
 
10 die fünf irrtümer
10 die fünf irrtümer10 die fünf irrtümer
10 die fünf irrtümerICV_eV
 
Die besten Zitate für Ihre Präsentation, Teil 1
Die besten Zitate für Ihre Präsentation, Teil 1Die besten Zitate für Ihre Präsentation, Teil 1
Die besten Zitate für Ihre Präsentation, Teil 1Vorzeige Helden
 
SeHF 2013 | Zusammenrücken von Medizininformatik und Medizintechnik im Rahmen...
SeHF 2013 | Zusammenrücken von Medizininformatik und Medizintechnik im Rahmen...SeHF 2013 | Zusammenrücken von Medizininformatik und Medizintechnik im Rahmen...
SeHF 2013 | Zusammenrücken von Medizininformatik und Medizintechnik im Rahmen...Swiss eHealth Forum
 
Kommunikation und Gesprächsführung
Kommunikation und GesprächsführungKommunikation und Gesprächsführung
Kommunikation und Gesprächsführungfoobar2605
 
Usability Engineering in Medizintechnik-Projekten
Usability Engineering in Medizintechnik-ProjektenUsability Engineering in Medizintechnik-Projekten
Usability Engineering in Medizintechnik-Projektenm3mitsuppe
 
E-Zigarette Großhandel: ZARsmoke® - Die Echte Alternative - Thekenaufsteller
E-Zigarette Großhandel: ZARsmoke® - Die Echte Alternative - ThekenaufstellerE-Zigarette Großhandel: ZARsmoke® - Die Echte Alternative - Thekenaufsteller
E-Zigarette Großhandel: ZARsmoke® - Die Echte Alternative - ThekenaufstellerGleb Konovalov
 

Andere mochten auch (9)

Impuls Workshop: die brennendsten Probleme der Medizintechnik (MedConf 2014) ...
Impuls Workshop: die brennendsten Probleme der Medizintechnik (MedConf 2014) ...Impuls Workshop: die brennendsten Probleme der Medizintechnik (MedConf 2014) ...
Impuls Workshop: die brennendsten Probleme der Medizintechnik (MedConf 2014) ...
 
Agile Methoden und die Theory of Constraints
Agile Methoden und die Theory of ConstraintsAgile Methoden und die Theory of Constraints
Agile Methoden und die Theory of Constraints
 
Projektmanagement in der Medizintechnik
Projektmanagement in der MedizintechnikProjektmanagement in der Medizintechnik
Projektmanagement in der Medizintechnik
 
10 die fünf irrtümer
10 die fünf irrtümer10 die fünf irrtümer
10 die fünf irrtümer
 
Die besten Zitate für Ihre Präsentation, Teil 1
Die besten Zitate für Ihre Präsentation, Teil 1Die besten Zitate für Ihre Präsentation, Teil 1
Die besten Zitate für Ihre Präsentation, Teil 1
 
SeHF 2013 | Zusammenrücken von Medizininformatik und Medizintechnik im Rahmen...
SeHF 2013 | Zusammenrücken von Medizininformatik und Medizintechnik im Rahmen...SeHF 2013 | Zusammenrücken von Medizininformatik und Medizintechnik im Rahmen...
SeHF 2013 | Zusammenrücken von Medizininformatik und Medizintechnik im Rahmen...
 
Kommunikation und Gesprächsführung
Kommunikation und GesprächsführungKommunikation und Gesprächsführung
Kommunikation und Gesprächsführung
 
Usability Engineering in Medizintechnik-Projekten
Usability Engineering in Medizintechnik-ProjektenUsability Engineering in Medizintechnik-Projekten
Usability Engineering in Medizintechnik-Projekten
 
E-Zigarette Großhandel: ZARsmoke® - Die Echte Alternative - Thekenaufsteller
E-Zigarette Großhandel: ZARsmoke® - Die Echte Alternative - ThekenaufstellerE-Zigarette Großhandel: ZARsmoke® - Die Echte Alternative - Thekenaufsteller
E-Zigarette Großhandel: ZARsmoke® - Die Echte Alternative - Thekenaufsteller
 

Ähnlich wie Das Eisberg Prinzip - die 4 Ebenen des Widerstands bei der Einführung von Scrum in der Medizintechnik

Ketzerischer Vortrag zur Agilen Entwicklung
Ketzerischer Vortrag zur Agilen Entwicklung Ketzerischer Vortrag zur Agilen Entwicklung
Ketzerischer Vortrag zur Agilen Entwicklung Thomas Arends
 
Verbesserung des Risikomanagements für Medizinprodukte
Verbesserung des Risikomanagements für MedizinprodukteVerbesserung des Risikomanagements für Medizinprodukte
Verbesserung des Risikomanagements für MedizinprodukteDenis Werner
 
Den PEP (Produktentwicklungsprozess) neu denken!
Den PEP (Produktentwicklungsprozess) neu denken!Den PEP (Produktentwicklungsprozess) neu denken!
Den PEP (Produktentwicklungsprozess) neu denken!Christoph Schmiedinger
 
Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?HOOD Group
 
Agile Projektentwicklung mit SCRUM
Agile Projektentwicklung mit SCRUMAgile Projektentwicklung mit SCRUM
Agile Projektentwicklung mit SCRUMTechDivision GmbH
 
usability_vorlesung_5.pdf
usability_vorlesung_5.pdfusability_vorlesung_5.pdf
usability_vorlesung_5.pdfssuser3a90c6
 
Software trends veranstaltungsprogramm_neu
Software trends veranstaltungsprogramm_neuSoftware trends veranstaltungsprogramm_neu
Software trends veranstaltungsprogramm_neuCON.ECT Eventmanagement
 
Qz Req Eng Ebert Rudorfer 2011 V3
Qz Req Eng Ebert Rudorfer 2011 V3Qz Req Eng Ebert Rudorfer 2011 V3
Qz Req Eng Ebert Rudorfer 2011 V3Arnold Rudorfer
 
So klappt’s: Qualitätsziele erreichen durch kontrollierte Absicherung
So klappt’s: Qualitätsziele erreichen durch kontrollierte AbsicherungSo klappt’s: Qualitätsziele erreichen durch kontrollierte Absicherung
So klappt’s: Qualitätsziele erreichen durch kontrollierte AbsicherungRalf Bongard
 
Agilität und Qualitätskriterien in der Softwareentwicklung
Agilität und Qualitätskriterien in der SoftwareentwicklungAgilität und Qualitätskriterien in der Softwareentwicklung
Agilität und Qualitätskriterien in der Softwareentwicklungrico.fritzsche
 
Im Spannungsfeld: Agilität und sicherheitskritische Systeme
Im Spannungsfeld: Agilität und sicherheitskritische SystemeIm Spannungsfeld: Agilität und sicherheitskritische Systeme
Im Spannungsfeld: Agilität und sicherheitskritische SystemeStefan Wertheimer
 
Abenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-WartungAbenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-WartungErnest Wallmueller
 
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...Marc Bless
 
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
 Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See... Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...QAware GmbH
 
Der digitale Zwilling als Reisebegleiter in die agile Hardware Entwicklung
Der digitale Zwilling als Reisebegleiter in die agile Hardware EntwicklungDer digitale Zwilling als Reisebegleiter in die agile Hardware Entwicklung
Der digitale Zwilling als Reisebegleiter in die agile Hardware EntwicklungAgile Austria Conference
 
Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshopmrdoubleb
 
Softwarequalität – Schlagwort oder Realität ?
Softwarequalität – Schlagwort oder Realität ?Softwarequalität – Schlagwort oder Realität ?
Softwarequalität – Schlagwort oder Realität ?Ernest Wallmueller
 
Agile (Software-) Prozesse - Quo Vadis? [in German]
Agile (Software-) Prozesse - Quo Vadis? [in German]Agile (Software-) Prozesse - Quo Vadis? [in German]
Agile (Software-) Prozesse - Quo Vadis? [in German]Martin Gaedke
 

Ähnlich wie Das Eisberg Prinzip - die 4 Ebenen des Widerstands bei der Einführung von Scrum in der Medizintechnik (20)

Xidra 2016 DevOps
Xidra 2016 DevOpsXidra 2016 DevOps
Xidra 2016 DevOps
 
Ketzerischer Vortrag zur Agilen Entwicklung
Ketzerischer Vortrag zur Agilen Entwicklung Ketzerischer Vortrag zur Agilen Entwicklung
Ketzerischer Vortrag zur Agilen Entwicklung
 
Verbesserung des Risikomanagements für Medizinprodukte
Verbesserung des Risikomanagements für MedizinprodukteVerbesserung des Risikomanagements für Medizinprodukte
Verbesserung des Risikomanagements für Medizinprodukte
 
Den PEP (Produktentwicklungsprozess) neu denken!
Den PEP (Produktentwicklungsprozess) neu denken!Den PEP (Produktentwicklungsprozess) neu denken!
Den PEP (Produktentwicklungsprozess) neu denken!
 
Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?
 
Agile Projektentwicklung mit SCRUM
Agile Projektentwicklung mit SCRUMAgile Projektentwicklung mit SCRUM
Agile Projektentwicklung mit SCRUM
 
usability_vorlesung_5.pdf
usability_vorlesung_5.pdfusability_vorlesung_5.pdf
usability_vorlesung_5.pdf
 
Software trends veranstaltungsprogramm_neu
Software trends veranstaltungsprogramm_neuSoftware trends veranstaltungsprogramm_neu
Software trends veranstaltungsprogramm_neu
 
Mehr Softwarequalität: Team-Cleancoding
Mehr Softwarequalität: Team-CleancodingMehr Softwarequalität: Team-Cleancoding
Mehr Softwarequalität: Team-Cleancoding
 
Qz Req Eng Ebert Rudorfer 2011 V3
Qz Req Eng Ebert Rudorfer 2011 V3Qz Req Eng Ebert Rudorfer 2011 V3
Qz Req Eng Ebert Rudorfer 2011 V3
 
So klappt’s: Qualitätsziele erreichen durch kontrollierte Absicherung
So klappt’s: Qualitätsziele erreichen durch kontrollierte AbsicherungSo klappt’s: Qualitätsziele erreichen durch kontrollierte Absicherung
So klappt’s: Qualitätsziele erreichen durch kontrollierte Absicherung
 
Agilität und Qualitätskriterien in der Softwareentwicklung
Agilität und Qualitätskriterien in der SoftwareentwicklungAgilität und Qualitätskriterien in der Softwareentwicklung
Agilität und Qualitätskriterien in der Softwareentwicklung
 
Im Spannungsfeld: Agilität und sicherheitskritische Systeme
Im Spannungsfeld: Agilität und sicherheitskritische SystemeIm Spannungsfeld: Agilität und sicherheitskritische Systeme
Im Spannungsfeld: Agilität und sicherheitskritische Systeme
 
Abenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-WartungAbenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-Wartung
 
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
 
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
 Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See... Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
 
Der digitale Zwilling als Reisebegleiter in die agile Hardware Entwicklung
Der digitale Zwilling als Reisebegleiter in die agile Hardware EntwicklungDer digitale Zwilling als Reisebegleiter in die agile Hardware Entwicklung
Der digitale Zwilling als Reisebegleiter in die agile Hardware Entwicklung
 
Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshop
 
Softwarequalität – Schlagwort oder Realität ?
Softwarequalität – Schlagwort oder Realität ?Softwarequalität – Schlagwort oder Realität ?
Softwarequalität – Schlagwort oder Realität ?
 
Agile (Software-) Prozesse - Quo Vadis? [in German]
Agile (Software-) Prozesse - Quo Vadis? [in German]Agile (Software-) Prozesse - Quo Vadis? [in German]
Agile (Software-) Prozesse - Quo Vadis? [in German]
 

Das Eisberg Prinzip - die 4 Ebenen des Widerstands bei der Einführung von Scrum in der Medizintechnik

  • 1. Das Eisberg-Prinzip
 
 Die 4 Ebenen des Widerstands bei der Einführung von Scrum in der Medizintechnik
 
 
 Frank Lange
 Consanis GmbH
 
 
 
 
 Agile Med 2014 , 19.02.2014 München.

  • 2. Herausforderungen im Gesundheitswesen u Steigender Kostendruck u Komplexe Gesamtsysteme (integrierte Workflows statt Einzelprodukte) UND Einfache Handhabung (Vergleich mit Consumer-Produkten) u Hohe Dynamik (Kurze Entwicklungszyklen, häufige Anforderungsänderungen) UND Starre Entwicklungsabläufe (regulierter Markt, hohe Qualitätsanforderungen)
  • 9. Normen zur Softwareentwicklung in der Medizintechnik
  • 10. 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 vollständig zu verstehen, heißt bereits ihn zu lösen.” (Theory of Constraints) .
  • 11. Software-Lebenszyklus-Prozess-Norm (EN 62304) u Vorurteil: „Die Norm fordert das V-Modell!“ „Das haben wir schon immer so gemacht!“ u Ursache: Unsicherheit bzgl. der „mächtigen“ Normen à Fehlinterpretation (Die Norm fordert lediglich 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. 1. Ebene des Widerstands Verständniskonflikte .
  • 12. Qualitätsmanagement-Norm (ISO 13485) u Vorurteil: „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ösung: 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. 2. Ebene des Widerstands Rollenkonflikte .
  • 13. Risikomanagement-Norm (ISO 14971) u Vorurteil: „In Scrum wird nichts dokumentiert, obwohl die Norm das fordert!“ u Ursache: Fehlinterpretation des zweiten Punkts des agilen Manifests. à Verteidigungshaltung in beiden „Lagern“ Lösung: 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. 3. Ebene des Widerstands: Wertekonflikte .
  • 14. Gebrauchstauglichkeitsnorm (EN 62366) u Vorurteil: „Scrum ist rein technisch, Kunden werden nicht eingebunden!“ u Ursache: Entwickler lieben Scrum UND Technik à Stakeholder halten Scrum für rein 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. 4. Ebene des Widerstands Tief sitzende menschliche Urängste .
  • 16. 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 .
  • 17. 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 .
  • 18. 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 .
  • 19. Vielen Dank für Ihre Aufmerksamkeit! consanis.de frank.lange@consanis.de