Scrum in regulierten Branchen - dürfen wir das überhaupt?

Scrum in regulierten Branchen - Dürfen wir das überhaupt?

GPM Friedrichshafen, 21.09.2012Frank Lange Agilefokus.de

http://www.agilefokus.de

AbstractVerschiedene Studien zeigen regelmäßig jedes Jahr aufs neue, dass ein Großteil der Entwicklungsprojekte in Unternehmen scheitert. Mal werden

Liefertermine überschritten, ein anderes mal explodieren die Kosten. Selbst bei genauester Planung kommt es auch immer wieder vor, dass das

ein Projekt zwar "erfolgreich" abgeschlossen werden konnte (alle Anforderungen wurden vollständig und korrekt umgesetzt), der Produkterfolg

jedoch ausblieb. Etwa, weil die eigentlichen Anforderungen sich im Projektverlauf stark geändert haben, das Pflichtenheft aber aus Gründen der

Planungssicherheit diesen neuen Gegebenheiten nicht angepasst wurde.

Agile Entwicklungsmethoden wie etwa Scrum bieten Ansätze, um genau diese Probleme anzugehen und somit die Chance auf ein erfolgreiches

Projekt deutlich zu erhöhen. Speziell in der Softwareentwicklung konnte sich Scrum im letzten Jahrzehnt etablieren und seine Vorteile gegenüber

klassischen Ansätzen bereits in vielen Projekten unter Beweis stellen. In regulierten Branchen, wie Automotive, Luftfahrt oder Medizintechnik

werden agile Entwicklungsmethoden jedoch nur sehr zögerlich aufgenommen. Schreiben nicht die Normen die Verwendung des V-Modells

zwingend vor? Ist nicht ein verlässliches und unveränderliches Pflichtenheft der Garant dafür, die hohen qualitativen Anforderungen an das

Endprodukt zu erfüllen? Und überhaupt: Führt Agilität nicht letzendlich zu völligem Chaos, denn da darf doch jeder machen was er will?

An diesem Abend werden wir gemeinsam einige dieser Vorurteile widerlegen und an einem praxisnahen Beispiel aus der Medizintechnik erfahren,

dass agile Methoden sehr wohl auch in regulierten Branchen erfolgreich eingeführt und mit geltenden Normen und Regularien in Einklang

gebracht werden können. Typische Schwierigkeiten während des Changeprozesses werden nicht verschwiegen, sondern kreative

Lösungsansätze vorgestellt. Wir werden auf spielerische Art und Weise einiges über die Grundprinzipien agiler Methoden erfahren, zum Beispiel

warum weniger oft mehr ist und die Reduzierung des WIP (Work in Progress) kombiniert mit einem werteorientierten Führungsstil Teams zu

Höchstleistungen aufblühen lassen kann.

Frank Lange - Agilefokus.de - [email protected]

"Scrum in regulierten Branchen - Dürfen wir das überhaupt?" - GPM Friedrichshafen - 21.09.2012


Frank LangeFrank Lange besitzt eine langjährige Erfahrung im Bereich der Softwareentwicklung, speziell in der

Medizintechnik- und Pharmabranche sowie im Bereich Automotive. Er war als Projektleiter und

Entwicklungsleiter für eine Vielzahl von Projekten verantwortlich und hat dabei die typischen Probleme

von Entwicklungsprojekten immer wieder miterleben müssen: zu spät / zu teuer / falscher Fokus. Seit

drei Jahren setzt er agile Entwicklungsmethoden und engpassfokussierte Ansätze wie die Theory of

Constraints intensiv ein und konnte diese 3 Hauptprobleme damit auf ein Minimum eindämmen.

Neben seiner Position als Product Owner in einem medizintechnischen Unternehmen gibt er seine

Erfahrung auch als selbständiger Berater in Trainings und Coachings an solche Unternehmen weiter,

die zuverlässliche Projekte und ein starkes und nachhaltiges Firmenwachstum sicherstellen wollen.




3 W-Fragen von Veränderungsprozessen

1. Was soll geändert werden?2. Was ist das Ziel der Änderung?3. Wie soll die Änderung umgesetzt werden?




1. Was soll geändert werden?

● Beispiele regulierter Branchen: Automotive, Luftfahrt, Medizintechnik, Chemie, Pharma, ..

● Starker Einfluss von Normen auf Unternehmen und ihre Prozesse

● Hohes Sicherheitsbedürfnis

--> Schwergewichtige Prozesse erforderlich




1. Was soll geändert werden?

● Beispiele regulierter Branchen: Automotive, Luftfahrt, Medizintechnik, Chemie, Pharma, ..

● Starker Einfluss von Normen auf Unternehmen und ihre Prozesse

● Hohes Sicherheitsbedürfnis

--> Schwergewichtige Prozesse erforderlich (V-Modell)● Erhöhter Wettbewerb mit immer kürzeren Entwicklungszyklen

--> Leichtgewichtige Prozesse erforderlich (Scrum)




2. Was ist das Ziel der Änderung?.


D: WunschV-Modell anwenden

D': WunschScrum anwenden

-







C: BedürfnisKundenwünsche erfüllen

B: BedürfnisNormen erfüllen









A: ZielErfolgreiche medizintechnische Produkte entwickeln









A: ZielErfolgreiche medizintechnische Produkte entwicklen

- V-Modell und Scrum sind unvereinbar

- Normen sind komplex und umfangreich- Unwissenheit über genaue Anforderungen der Normen erzeugt Unsicherheit- "Normen verlangen zwangsläufig V-Modell"

- - Erfolg kann nur gemeinsam mit dem Kunden erreicht werden- Kunde hat das beste Domainenwissen

- Scrum bezieht Kunden in die Entwicklung ein- Transparenz erlaubt Kunden tiefen Einblick ins laufende Projekt- Kurze Feedbackschleifen erlauben frühe Optimierung der Anforderungen

- Ohne Erfüllung der Normen keine Zulassung









A: ZielErfolgreiche medizintechnische Produkte entwicklen

- V-Modell und Scrum sind unvereinbar

- Normen sind komplex und umfangreich- Unwissenheit über genaue Anforderungen der Normen erzeugt Unsicherheit- "Normen verlangen zwangsläufig V-Modell"

- - Erfolg kann nur gemeinsam mit dem Kunden erreicht werden- Kunde hat das beste Domainenwissen

- Scrum bezieht Kunden in die Entwicklung ein- Transparenz erlaubt Kunden tiefen Einblick ins laufende Projekt- Kurze Feedbackschleifen erlauben frühe Optimierung der Anforderungen

- Ohne Erfüllung der Normen keine Zulassung



Normen: SW-Entwicklung in der Medizintechnik


EN 60601Sicherheitsanforderungen und ergonomische Anforderungen an medizinische elektrische Geräte und in medizinischen Systemen

EN 60601-1, 3. AusgabeMedizinische elektrische Geräte, Teil 1: Allgemeine Festlegung für die Sicherheit einschließlich der wesentlichen Leistungsmerkmale

EN 60601-1-1System-Norm

EN 60601-1-4Software-Norm

EN 60601-1-6Gebrauchstauglichkeit

Stärkung

EN 62304Medizingeräte-Software - Software-Lebens-zyklus-Prozess

ISO 14971Anwendung desRisikomanage-ments auf Medizinprodukte

ISO 13485Anwendung des Qualitätsmanage-ments auf Medizinprodukte

EN 62366Anwendung des der Gebrauchs-tauglichkeit auf Medizinprodukte

ISO 9001Qualitätsmanage-mentsystem

ISO 9241; Teil 11Gebrauchs-tauglichkeit

ISO 31000Risikomanage-ment

ISO 12207SW-Lebenszy-klus-Prozess



Normen: SW-Entwicklung in der Medizintechnik


EN 60601Sicherheitsanforderungen und ergonomische Anforderungen an medizinische elektrische Geräte und in medizinischen Systemen

EN 60601-1, 3. AusgabeMedizinische elektrische Geräte, Teil 1: Allgemeine Festlegung für die Sicherheit einschließlich der wesentlichen Leistungsmerkmale

EN 60601-1-1System-Norm

EN 60601-1-4Software-Norm

EN 60601-1-6Gebrauchstauglichkeit

Stärkung

EN 62304Medizingeräte-Software - Software-Lebens-zyklus-Prozess

ISO 14971Anwendung desRisikomanage-ments auf Medizinprodukte

ISO 13485Anwendung des Qualitätsmanage-ments auf Medizinprodukte

EN 62366Anwendung des der Gebrauchs-tauglichkeit auf Medizinprodukte

ISO 9001Qualitätsmanage-mentsystem

ISO 9241; Teil 11Gebrauchs-tauglichkeit

ISO 31000Risikomanage-ment

ISO 12207SW-Lebenszy-klus-Prozess

"Das V-Modell ist zwingend vorgeschrieben, Scrum kann nicht funktionieren."

"Scrum betrachtet keine Risiken - es wird nicht einmal richtig dokumentiert."

"Scrum stellt keine Qualität sicher - jeder macht dort, was er will."

"Scrum ist ein rein technischer Entwicklungs-prozess, Kunden werden nicht eingebunden."



Konflikte zwischen Scrum und Normen (1)EN 62304 Software-Lebenszyklus-Prozess

● Vorurteil: Die Norm fordert eindeutig die Anwendung des V-Models

● Ursache: Die Norm fordert lediglich die "Einhaltung eines festgeschriebenen Entwicklungsprozesses, beispielsweise des V-Modells" --> Fehlinterpretation!

● Lösungsansatz: Freiheiten der Norm nutzen, ohne sie zu verletzen

● Umsetzung

○ Kurzfristig: Scrum im unteren Teil des V-Modells einsetzen

○ Langfristig: Komplettes V-Modell auf Scrum umstellen




Konflikte zwischen Scrum und Normen (2)EN 62366 Gebrauchstauglichkeit

● Vorurteil: Scrum ist ein rein technischer Entwicklungsprozess, Kunden werden nicht eingebunden.

● Ursache: Entwickler lieben Scrum - dadurch erscheint es sehr "technikorientiert". Stakeholder fühlen sich teilweise nicht eingebunden und "abgeholt".

● Lösungsansatz: Professionelle Einführung von Scrum

● Umsetzung

○ Stakeholdermanagement: Scrum im Unternehmen und Kunden bekannt machen

○ Offenheit und Transparenz: Kunden zu Sprint-Demos einladen

○ Frühes Scheitern: Feedback einfordern und bei Bedarf Pläne ändern




Konflikte zwischen Scrum und Normen (3)ISO 14971 Risikomanagement

● Vorurteil: Scrum dokumentiert nichts, daher funktioniert Risikomanagement nicht

● Ursache: Agiles Manifest "Funktionierende Software ist wichtiger als umfassende Dokumentation" wird fehlinterpretiert.

● Lösungsansatz: Tieferes Verständnis der Werte des agilen Manifests

Agiles Manifest

Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.

Funktionierende Software ist wichtiger als umfassende Dokumentation.

Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.

Eingehen auf Veränderungen ist wichtiger als Festhalten an einem Plan.




Konflikte zwischen Scrum und Normen (4)ISO 13485 Qualitätsmanagement

● Vorurteil: Jeder macht in Scrum was er will - Qualität kann so nicht entstehen

● Ursache: Neue Rollen in Scrum führen zu Unsicherheit ("Wer ist denn bei euch in der Software jetzt der Projektleiter?")

● Lösungsansatz: Tieferes Verständnis der Scrum-Rollen

● Rollen in Scrum

○ Team (Entwickler, Tester, Designer, ...) verantwortet Umsetzung (Wie?)

○ Scrum Master stellt Einhaltung des Prozesses sicher, Coach des Teams

○ Product Owner verantwortet Produktinhalt (Was?)

--> Verantwortung bleibt bestehen, ist nur auf andere Rollen verteilt.




Konflikte zwischen Scrum und Normen (5)

Zusammenfassung der Lösungsansätze

● Tieferes Verständnis der Normen

○ Freiheiten der Norm nutzen, ohne sie zu verletzen

● Professionelle Einführung von Scrum

○ Tieferes Verständnis der Werte des agilen Manifests

○ Tieferes Verständnis der Scrum-Rollen




3. Wie soll die Änderung umgesetzt werden?

Praxisbericht




V-Modell


Anforderungsanalyse

Systemarchitektur

Systementwurf

SW-Architektur

SW-Entwurf

Abnahme

System-Integration

Integrations-Tests

Unit-Tests

Fehlerbehebung

Anw

ende

rfeed

back



Scrum


Product-Backlog

Sprint-Backlog

hochwertige,lieferfähigeSoftware

1-4 Wochen

24 h

Sprint - kurze Zyklen

- "Definition of Done"- sofortige Fehlerbehebung- Impediments auflösen- Anwenderfeedback- Stakeholdermanagement

Qualitätssicherung



Agiles V-Modell


Anforderungsanalyse

Systemarchitektur

Systementwurf

SW-Architektur

SW-Entwurf

Abnahme

System-Integration

Integrations-Tests

Unit-Tests

Fehlerbehebung

Anw

ende

rfeed

back



Erfahrungsbericht (1) - Am Anfang passiert...

● ...nichts!

○ Qualitätsziele wurden nicht erreicht

○ Velocity war geringer als geplant

○ Aufwand für Teamfindung höher als erwartet

--> Erfolgskurve relativ flach




Erfahrungsbericht (2) - Quick Wins

● WISCY - Why isn't Sam coding yet?

○ Kurze Sprintzyklen (2 Wochen)

○ Stabile Software am Sprintende

○ Stabile Feedbackschleifen

--> Stakeholder fühlen sich "abgeholt",

--> positive Außenwirkung




Erfahrungsbericht (3) - "Nebenwirkungen"

● Das Team trägt plötzlich Verantwortung

○ Product Owner sagt "WAS" zu tun ist

○ Team entscheidet, "WIE" umgesetzt wird

○ Scrum Master fordert & fördert Verantwortung

○ Sinnfrage im Management:

Wozu sind wir eigentlich noch da?




Erfahrungsbericht (4) - Sichtbare Erfolge

● Transparenz --> Vertrauen bei Stakeholdern

● Stabile Velocity --> Planungssicherheit

● Zusammenarbeit mit Kunden --> Hoher Business Value




Vielen Dank für Ihre Aufmerksamkeit!




DiskussionÄhnlichkeiten und Unterschiede in den verschiedenen regulierten Märkten- Gilt das Gesagte auch für andere regulierte Branchen außerhalb der Medizintechnik?

- Welche Normen sind dort genau zu beachten?

- Welche Mindsets gelten dort?

Wer hat bereits Erfahrungen mit agilen Methoden gesammelt?- Wie genau sehen die Erfahrungen aus?

- Wie haben die positiven Erfahrungen sich auf das Wachstum des Gesamtunternehmens ausgewirkt?

- Welche Widerstände gab es und wie sind Sie damit umgegangen?




Literatur● Agiles Manifest http://de.wikipedia.org/wiki/Agiles_Manifest#Werte

● Marc Bless, Normenkonforme Medizinproduktentwicklung mit agilen Prozessen und Artefakten,

http://agilecoach.de/wp-content/uploads/2012/06/Marc-Bless-Agile-Methoden-in-der-

Medizintechnik-v0.1.pdf

● Frank Lange, Normen in der Medizintechnik, http://www.agilefokus.de/medizintechniknormen.html

● Frank Lange, Konfliktlösung mit der Dilemma Wolke, http://www.agilefokus.de/dilemma-wolke.html



http://de.wikipedia.org/wiki/Agiles_Manifest#Werte

http://agilecoach.de/wp-content/uploads/2012/06/Marc-Bless-Agile-Methoden-in-der-Medizintechnik-v0.1.pdf



http://www.agilefokus.de/medizintechniknormen.html

http://www.agilefokus.de/dilemma-wolke.html


Leadership & Management

Scrum in regulierten Branchen - dürfen wir das überhaupt?