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

Scrum in regulierten Branchen -
Dürfen wir das überhaupt?
GPM Friedrichshafen, 21.09.2012
Frank Lange Agilefokus.de

Abstract
Verschiedene 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 - frank.lange@agilefokus.de
"Scrum in regulierten Branchen - Dürfen wir das überhaupt?" - GPM Friedrichshafen - 21.09.2012

Frank Lange
Frank 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?

● Beispiele regulierter Branchen: Automotive, Luftfahrt, Medizintechnik, Chemie, Pharma, ..
● Starker Einfluss von Normen auf Unternehmen und ihre Prozesse
● Hohes Sicherheitsbedürfnis
--> Schwergewichtige Prozesse erforderlich

● 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)

.
D: Wunsch
V-Modell anwenden
D': Wunsch
Scrum anwenden
-

.
D: Wunsch
V-Modell anwenden
D': Wunsch
Scrum anwenden
C: Bedürfnis
Kundenwünsche
erfüllen
B: Bedürfnis
Normen erfüllen

.
D: Wunsch
V-Modell anwenden
D': Wunsch
Scrum anwenden
C: Bedürfnis
Kundenwünsche
erfüllen
B: Bedürfnis
Normen erfüllen
A: Ziel
Erfolgreiche
medizintechnische
Produkte entwickeln

.
D: Wunsch
V-Modell anwenden
D': Wunsch
Scrum anwenden
C: Bedürfnis
Kundenwünsche
erfüllen
B: Bedürfnis
Normen erfüllen
A: Ziel
Erfolgreiche
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 60601
Sicherheitsanforderungen und
ergonomische Anforderungen an
medizinische elektrische Geräte
und in medizinischen Systemen
EN 60601-1, 3. Ausgabe
Medizinische elektrische
Geräte, Teil 1: Allgemeine
Festlegung für die Sicherheit
einschließlich der
wesentlichen
Leistungsmerkmale
EN 60601-1-1
System-Norm
EN 60601-1-4
Software-Norm
EN 60601-1-6
Gebrauchstauglichkeit
Stärkung
EN 62304
Medizingeräte-
Software -
Software-Lebens-
zyklus-Prozess
ISO 14971
Anwendung des
Risikomanage-
ments auf
Medizinprodukte
ISO 13485
Anwendung des
Qualitätsmanage-
ments auf
Medizinprodukte
EN 62366
Anwendung des
der Gebrauchs-
tauglichkeit auf
Medizinprodukte
ISO 9001
Qualitätsmanage-
mentsystem
ISO 9241; Teil
11
Gebrauchs-
tauglichkeit
ISO 31000
Risikomanage-
ment
ISO 12207
SW-Lebenszy-
klus-Prozess

Normen: SW-Entwicklung in der Medizintechnik
EN 60601
Sicherheitsanforderungen und
ergonomische Anforderungen an
medizinische elektrische Geräte
und in medizinischen Systemen
EN 60601-1, 3. Ausgabe
Medizinische elektrische
Geräte, Teil 1: Allgemeine
Festlegung für die Sicherheit
einschließlich der
wesentlichen
Leistungsmerkmale
EN 60601-1-1
System-Norm
EN 60601-1-4
Software-Norm
EN 60601-1-6
Gebrauchstauglichkeit
Stärkung
EN 62304
Medizingeräte-
Software -
Software-Lebens-
zyklus-Prozess
ISO 14971
Anwendung des
Risikomanage-
ments auf
Medizinprodukte
ISO 13485
Anwendung des
Qualitätsmanage-
ments auf
Medizinprodukte
EN 62366
Anwendung des
der Gebrauchs-
tauglichkeit auf
Medizinprodukte
ISO 9001
Qualitätsmanage-
mentsystem
ISO 9241; Teil
11
Gebrauchs-
tauglichkeit
ISO 31000
Risikomanage-
ment
ISO 12207
SW-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

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

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.

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.

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
Anwenderfeedback

Scrum
Product-
Backlog
Sprint-
Backlog
hochwertige,
lieferfähige
Software
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
Anwenderfeedback

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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (15)

Mehr von Frank Lange

Mehr von Frank Lange (11)

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