Agil am Limit E-Book

Jonathan von Wittern

• Herausgeber: tredition
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2023

Seitenzahl: 598

Beschreibung

Das Buch stellt den neuen Ansatz AgileTrio vor, der agile Methoden nahtlos mit ein regulatorische Framework kombiniert. Diese innovative Herangehensweise ermöglicht die erfolgreiche Einführung und kontinuierliche Entwicklung von zuverlässigen regulierten Softwareprodukten in schnellen Veröffentlichungszyklen, ein Ansatz, der auch im regulieren Umfeld immer bedeutsamer wird. Die Leser werden auf eine Reise durch die Welt der Softwareentwicklung mitgenommen, beginnend mit einer eingehenden Untersuchung der Geschichte der jungen Disziplin. Das Buch beleuchtet dabei die beiden Welten: das klassische Vorgehen und das vorherrschende traditionelle Mindset, das in regulierten Umgebungen weit verbreitet ist, sowie das agile Vorgehen und das zugehörige Mindset das in der weniger regulierten Web- und Applikationsentwicklung vorherrscht. Im Fokus stehen exemplarisch die verschiedenen Aspekte der Medizinischen Softwareentwicklung, wobei das Buch umfassend auf folgende Themen eingeht: - Qualitätsmanagementsysteme - Softwareentwicklung - Risikomanagement - Anforderungsmanagement - Produktverifizierung - Benutzerfreundlichkeit - Informationssicherheit - klinische Bewertung - Bereitstellung und Verteilung - Kennzeichnung - Begleitdokumentation - Produktlebenszyklus - Überwachung nach Inverkehrbringen - Informationssicherheit Der Autor skizziert die notwendigen Rollen innerhalb der Produktentwicklung und verdeutlichen die damit verbundenen Aufgaben und Verantwortlichkeiten. Ein Schwerpunkt liegt dabei auf der effektiven Zusammenarbeit aller beteiligten Parteien, um eine erfolgreiche Marktzulassung für regulierte Produkte sowie die Erstellung einer umfassenden Technischen Dokumentation zu gewährleisten. Inmitten der rasanten Digitalisierung der Gesundheitsbranche zeigt das Buch auf, wohin die Reise in Bezug auf die Produktentwicklung von regulierten Softwareprodukten führt. Es wirft dabei einen klaren Blick auf die damit verbundenen Herausforderungen und bietet konkrete Lösungsansätze.

Leseprobe

Agil am Limit

Agil am Limit

Wie Du mit AgileTrio agile Werte und Vorgehen im streng regulierten Umfeld umsetzen kannst

von Jonathan von Wittern

Impressum:

© 2023 Jonathan von Wittern

Lektorat: Julia Auth

Farben & Schrift: Designhoheit (https://designhoheit.de/)

ISBN Hardcover:

978-3-384-08287-9

ISBN E-Book:

978-3-384-08288-6

Druck und Distribution im Auftrag des Autors:

tredition GmbH,

Heinz-Beusen-Stieg 5,

22926 Ahrensburg,

Germany

Das Werk, einschließlich seiner Teile, ist urheberrechtlich geschützt. Für die Inhalte ist der Autor verantwortlich. Jede Verwertung ist ohne seine Zustimmung unzulässig. Die Publikation und Verbreitung erfolgen im Auftrag des Autors, zu erreichen unter:

tredition GmbH,

Abteilung „Impressumservice“,

Heinz-Beusen-Stieg 5,

22926 Ahrensburg,

Deutschland.

Um was es geht

Dieses Buch richtet sich an Scrum Teams und Geschäftsführer*innen im agilen Umfeld, die regulierte Software entwickeln und vertreiben möchten, sowie an Angestellte und Manager*innen in traditionellen Organisationen, die durch Agilität flexibler und zufriedener arbeiten wollen.

Es stellt den neuen Ansatz "AgileTrio" vor, der agiles Vorgehen mit einem regulatorischen Framework kombiniert. Es zeigt, wie dieser Ansatz erfolgreich eingeführt und damit zuverlässig regulierte Softwareprodukte in schnellen Veröffentlichungszyklen auf den Markt gebracht werden können.

Das Buch behandelt anhand Medizinischer Software dabei alle wichtigen Themen wie Qualitätsmanagementsystem, Softwareentwicklung, Risikomanagement, Benutzerfreundlichkeit, klinische Bewertung, Bereitstellung und Verteilung, Kennzeichnung, Begleitdokumentation, Produktlebenszyklus, Überwachung nach Inverkehrbringen und Informationssicherheit.

In Zeiten der Digitalisierung zeigt das Buch, wohin die Reise für die Produktentstehung von regulierten Softwareprodukten geht, und beleuchtet die damit verbundenen Herausforderungen.

Über den Autor

Der Autor schaut auf über 20 Jahre Berufserfahrung in regulierten Bereichen wie Medizintechnik, Luftfahrt und Automotive zurück. Seine Leidenschaft gilt der Medizintechnik. Zu wissen, dass Medizinprodukte das Leiden von Patienten lindern oder beseitigen können, ist für ihn eine unglaubliche Motivation.

Dabei durfte er Erfahrung in den verschiedensten Unternehmensbereichen wie Produktion, technischer Service, hardwarenahe Softwareentwicklung, Qualitätsmanagement und Regulatory Affairs sammeln. Er hat mit Weltmarktführern gearbeitet aber auch mit Familienunternehmen und Startups.

Inhalt

Cover

Halbe Titelseite

Titelblatt

Urheberrechte

Vorwort

1. Wie hat sich Softwareentwicklung verändert

2. Klassisches Vorgehen

Das Denken in Projekten

V-Model

Moderate Iterationen durch Stage-Gate

3. Klassisches Mindset

Managementmodelle

Starke Hierarchie

Management by Objectives

Strategiedefinition

Strategieimplementierung

4. Agiles Vorgehen

Das Denken in Produkten

Scrum

Scrum Rollen

Teambildung

Ablauf

Reporting

Praxisgruppen / Community Gruppen

Schnelle Iterationen durch Agiles Vorgehen

5. Agiles Mindset

Open Mindset

Aufgebrochene Hierarchie

Objective and Key Results

Strategiedefinition

Moals

Strategieimplementierung

6. Qualitätsmanagementsystem

Qualitätsmanagementsystem für Medizinprodukte

Struktur eines Qualitätsmanagementsystems

Prozesskompass

Plan-Do-Check-Act Zyklus

QMS für Medizinprodukteverordnung 2017/745 MDR

Prozesse

Computer Software Validation

Zusammenfassung

7. AgileTrio

Product Definition

Ergebnisse

Ablauf

Verantwortung

Zusammenfassung

Product Execution

Ergebnisse

Ablauf

Verantwortung

Zusammenfassung

Release Cycle

Ergebnisse

Ergebnisse – Produktlebenszyklus

Ablauf

Planung

Durchführung

Operations

Risikomanagement

Gebrauchstauglichkeit

Klinische Bewertung

Datenschutz

Begleitdokumentation

Finalisierung

Regulatorische Belange

Konformitätsbewertung

Registrierung

Abschluss

Ablauf – Produktlebenszyklus

Datenerfassung und Auswertung

Audits

Beschwerde- und Fehlermanagement

Verantwortung

Verantwortung – Produktlebenszyklus

Zusammenfassung

8. Technische Dokumentation

Summary Technical Documentation

Zusammenfassung

9. Risikomanagement

Arten von Risiken

Prozess Risiken

Produkt Risiken

Risikomanagementplan

Risikoanalyse mit Software Risikoklasse

Risikoanalyse mit Gefahrensituationsliste

Risikoanalyse als Design Fehlermöglichkeits- und -Einflussanalyse

Risikoanalyse mit Risiko-Nutzen Abwägung

Risikomanagementbericht

Risikomanagementakte

Jährliche Risikoauswertung

Zusammenfassung

10. Anforderungsmanagement

Arten von Anforderungen

Nutzeranforderungen

Technische Anforderungen

Visualisierung von Anforderungen

Qualitative Anforderungen

Dokumentation von Anforderungen

Rückverfolgbarkeit

Upstream Tracing

Downstream Tracing

Software Tool Unterstützung bei Anforderungen

Zusammenfassung

11. Verifizierung

Test Driven Development

Teststrategie

Verifizierungsplan

Zusammenfassung

12. Validierung

User Experience Design

Gebrauchstauglichkeit

Nutzerspezifikation

Validierungsplan

Nutzerschnittstellenbeschreibung

Begleitdokumentation und Schulungen

Formative und Summative Gebrauchstauglichkeitsstudien

Gebrauchstauglichkeitsakte

Änderungseinschätzung der Gebrauchstauglichkeit

Zusammenfassung

13. Softwareproduktion

Software Tool Validation

DevOps

Agile Development

Continuous Integration

Continuous Deployment

Release on Demand

Operations

Continuous Feedback

Zusammenfassung

14. Informationssicherheit

Schutzziele der Informationssicherheit

Grundsätze des Datenschutzes

Datenschutzverordnung

Verzeichnis der datenschutzrelevanten Verarbeitungstätigkeiten

Aussage zur Umsetzung der Rechte von Betroffenen

Zustimmungsmanagement

Datenschutzerklärung

Informationssicherheit für Softwareprodukte

Datenleck

Datenverlust

Datenmanipulation

Penetrationstest

Vulnerability Scan

Zusammenfassung

15. Überwachung nach Inverkehrbringen

16. Clinical Affairs

Klinische Bewertung

Klinische Prüfung

Klinische Nachbeobachtung nach Inverkehrbringen

Zusammenfassung

17. Reguliertes Umfeld

Produktsicherheit in Europa

Stark regulierter Bereich

Schwach regulierter Bereich

Produktsicherheit außerhalb Europas

Produktklassifizierung

Standards

Konformitätsverfahren

Benannte Stelle

Produktregistrierung

Zusammenfassung

Zusammenfassung & Ausblick

Begriffsverzeichnis

Quellen & Buchtipps

Agil am Limit, Fachbuch, Ratgeber, Medizinische Software, agiles Vorgehen, agile Einstellung, Softwareentwicklung, reguliertes Umfeld, Produktentstehung

Cover

Titelblatt

Urheberrechte

Vorwort

Quellen & Buchtipps

Agil am Limit, Fachbuch, Ratgeber, Medizinische Software, agiles Vorgehen, agile Einstellung, Softwareentwicklung, reguliertes Umfeld, Produktentstehung

Cover

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

Vorwort

Liebe Leserin, lieber Leser,

seit über 20 Jahren arbeite ich nun im regulierten Bereich. Begonnen habe ich meine Karriere in der Fertigung Medizinischer Geräte. Dann ging es weiter mit Kundenservice und Reparaturen Medizinischer Geräte. Es folgte eine Zeitspanne in der Entwicklung von Embedded Software für Luft- und Raumfahrt, Automotive und Medizinprodukte. Schließlich fand ich mich im Bereich Quality und Design Assurance der Medizintechnik wieder. Dort hatte ich auch zum ersten Mal eine Führungsposition inne.

Während meiner gesamten beruflichen Laufbahn bewegte ich mich bis dahin in einem traditionellen Arbeitsumfeld und arbeitete vorzugsweise in Projekten. Obwohl agiles Mindset und Methoden bereits vor über 20 Jahren entwickelt und im Laufe der Zeit immer populärer wurden, dauerte es mehr als 15 Jahre, bis ich die Gelegenheit hatte, mich im Detail mit agiler Softwareentwicklung in einem Startup für Medizinische Software auseinanderzusetzen.

Selbstverständlich gab es zuvor Versuche im konservativen Umfeld der Medizintechnik, agil zu arbeiten. Besonders in der Softwareentwicklung war dies am einfachsten umzusetzen. Dennoch waren die Ergebnisse oft enttäuschend. In den meisten streng regulierten Organisationen wurde die Produktentwicklung weiterhin in Form von Projekten durchgeführt, und die Strukturen blieben klassisch. Nur die Softwareentwicklung versuchte, sich agil zu organisieren, oft in Form von Scrum im V-Modell (V-Trichter).

In der Regel blieb es jedoch dabei. Scrum wurde vor allem genutzt, um Softwareteams zu organisieren, aber von echter Agilität konnte keine Rede sein. Die Produktentwicklung dauerte immer noch zwei bis drei Jahre, und Anpassungen am Projekt waren nur über moderate Iterationen eines Stage-Gate Prozesses möglich.

Eine andere Situation ergab sich in Startups für Medizinische Software. In meiner aktuellen Position im Bereich Regulatory Affairs, mit einem breiten Spektrum an Aufgaben und Verantwortung, arbeite ich in jungen Unternehmen, die sich auf die Digitalisierung des Gesundheitswesens spezialisiert haben. Hier habe ich hauptsächlich mit Medizinischer Software und Digitalen Gesundheitsapplikationen (DIGAs) zu tun.

Am Anfang ist alles oft wild und chaotisch. Die Softwareentwicklung beginnt in der Regel mit einer Mischung aus Scrum und Kanban, was als agiler Ansatz betrachtet werden kann. Doch bei der Marktzulassung gibt es immer wieder unangenehme Überraschungen. Gesetzliche Anforderungen und Standards werden häufig entweder nicht ausreichend berücksichtigt oder komplett ignoriert, was zu schwerwiegenden Verstößen gegen die Bedürfnisse der Nutzenden des Produkts führt.

Selbstverständlich kann man das Scrum Team im agilen Vorgehen immer wieder ausprobieren lassen, die Marktzulassung doch noch irgendwie durch Versuch und Scheitern zu erwirken und das Team daran wachsen lassen. Doch ohne die notwendige Erfahrung, Kenntnisse sowie ohne die Techniken, Methoden und Tools kann dies ein sehr langwieriger Prozess sein, der mit viel Frust und Ressourcenverlust einhergeht.

Darüber hinaus stellt das Scheitern bei der Marktzulassung insbesondere für junge Unternehmen und Startups ein existenzielles Risiko dar. Investoren reagieren empfindlich, wenn die Marktzulassung nicht reibungslos verläuft. Geldgebende verstehen sehr gut, welche Folgen ein gescheitertes Zulassungsverfahren hat und erkennen sofort, dass dies auf mangelnde Beachtung von Gesetzen und Standards zurückzuführen ist. Die Bereitschaft, weiteres Geld zu investieren, schwindet schnell, und das Startup kann in die Insolvenz geraten.

Dieses Buch hilft dir dabei, das Risiko bei Softwareprodukten in streng regulierten Bereichen zu reduzieren. Es richtet sich an ganze Teams, Scrum Master und Product Owner aus der agilen Welt, die Verantwortung für streng regulierte Produkte tragen, sowie an Qualitätsmanager*innen und Regulatory Affairs aus dem klassischen Bereich, die sich mit der agilen Haltung und Vorgehensweise vertraut machen möchten. Auch Topmanager*innen und Geschäftsführende in jungen Organisationen und Startups profitieren von diesem Buch, da es wertvolle Erkenntnisse liefert.

Um beide Welten zu vereinen, behandelt das Buch sowohl klassische als auch agile Ansätze und Denkweisen. Ziel ist es, Angehörigen beider Welten zu vermitteln, wie die jeweils andere Seite funktioniert, welche Vor- und Nachteile beide Welten mit sich bringen und warum beide Ansätze nach wie vor relevant sind. Es ist klug, sich in beiden Welten auszukennen und das Beste aus diesen zu nutzen.

Das Buch widmet sich zudem dem Thema Qualitätsmanagementsystem, da im streng regulierten Umfeld „Zufall und Zuruf“ nicht ausreichen. Dies erfordert eine Umstellung, besonders von der Geschäftsführung und den Process Owner, die ihre Rolle verstehen und konkrete Verantwortung übernehmen müssen.

Das Herzstück meines Buches ist AgileTrio. Hier wird der Produktlebenszyklus für Medizinische Software in Schleifen durchlaufen. Der Ansatz lässt sich jedoch leicht auf andere Softwareprodukte im regulierten Bereich übertragen, indem wenige Anpassungen vorgenommen werden. Das Ziel ist, die Release Zyklen so kurz wie möglich zu halten, wobei „Continuous Documentation“ der Schlüssel ist.

Zudem gehe ich detailliert auf Themen wie die Technische Dokumentation, das Risikomanagement, das Anforderungsmanagement, die Verifizierung, die Validierung und die Softwareproduktion ein. Ich bringe dir Techniken und Methoden näher, die dir helfen sollen, saubere und nutzbare Ergebnisse zu erzielen.

Da heutzutage kein Softwareprodukt mehr ohne Informationssicherheit und Datenschutz auskommt, widme ich auch diesem Thema ein eigenes Kapitel zur Vertiefung. Hier zeige ich, worauf es ankommt und worauf im Detail zu achten ist. Besonders beim Thema Datenschutz kursieren viele Halbwahrheiten. Teilweise sieht man sich mit Frustration und Naivität konfrontiert.

Die Kapitel zu den Themen Überwachung nach dem Inverkehrbringen und Clinical Affairs sind zwar spezifisch für Medizinprodukte, doch besonders die Überwachung nach dem Inverkehrbringen zeigt, dass es sich eigentlich um „Continuous Feedback“ handelt, das für viele Arten von Produkten interessant ist, unabhängig von der Vorgehensweise.

Abschließend richte ich den Fokus auf meinen Spezialbereich - das Regulierte Umfeld. Dieses Kapitel ist insbesondere für diejenigen unter euch von Interesse, die schon immer genau wissen wollten, was Regulatory Affairs eigentlich macht. Auch hierbei nähere ich mich dem Thema anhand Medizinischer Software, gehe aber zusätzlich auf allgemeine Gesetzgebung, vorzugsweise in der Europäischen Union, ein.

Es wäre natürlich wünschenswert, wenn du das komplette Buch lesen würdest. Es ist aber nicht zwingend erforderlich. Wer sich nicht lange mit irgendwelchen Mindsets oder Vorgehensweisen beschäftigen möchte, sondern lieber direkt wissen will, was Sache ist, kann gerne mit dem Kapitel AgileTrio beginnen. Es ist nicht zwangsläufig notwendig die Kapitel davor gelesen zu haben. Bei den Vertiefungsthemen, die folgen, steht ebenfalls jedes Kapitel für sich. Ich habe das Buch extra so konzipiert, dass du dich nur mit den Themen auseinandersetzen kannst, die akut sind oder dich persönlich betreffen und ansprechen.

Innerhalb des Buches gibt es immer wieder kleine Exkursionen in Form von gelben Notizboxen, die oft meine persönlichen Erfahrungen und Perspektiven widerspiegeln, aber die vor allem dich zum Nachdenken anregen sollen. Ich hoffe, du hast Freude daran und es bringt dich gelegentlich zum Schmunzeln.

Die Idee, dieses Buch zu schreiben, kam mir während der Entwicklung und Implementierung des AgileTrio Ansatzes. Diese Zeit war intensiv und erlaubte kaum Fehler. Denn wie schon beschrieben, kann das Scheitern einer Markzulassung in einem Startup das Ende bedeuten. Umso erfreulicher war deswegen die Abnahme der Implementierung des AgileTrio Ansatzes durch eine Benannte Stelle anhand einer Medizinischen Software. Zwar war uns vorher bereits bewusst, dass es für die Scrum Teams funktioniert. Anschließend bekamen wir jedoch zusätzlich die Bestätigung, dass es auch regulatorisch funktioniert.

Ich möchte mich für diese Erfahrung besonders bei zwei Personen bedanken. Vaclav Vlcek, der mir als Qualitätsmanager den Rücken freigehalten hat und es dadurch ermöglicht hat, mir ausreichend kreative Zeit mit den Scrum Teams und der Organisation für die Umsetzung des AgileTrio Ansatzes zu verschaffen. Mein besonderer Dank gilt zudem Anna Winkler, eine Kollegin und Scrum Master, für die zahlreichen Diskussionen und Debatten, ihre unnachgiebige Art, Dinge zu hinterfragen, und ihr großartiges Kommunikationstalent. Ohne diese beiden Personen wäre die Entwicklung und Implementierung des AgileTrio Ansatzes in dieser Form nicht möglich gewesen.

Es hat mehr als ein Jahr gedauert, bis ich schließlich mit dem Schreiben dieses Buches begonnen habe. Das Schreiben selbst hat mir geholfen, sämtliche berufliche Erfahrungen zu reflektieren, zu hinterfragen und auch zu verarbeiten. Dafür blieb zuvor oft nicht die Zeit. Bis zur Veröffentlichung dieser 1. Auflage verging nochmals über ein Jahr. Dabei habe ich gelernt, dass das Schreiben eines Buches einem Marathonlauf ähnelt und enorme Ausdauer und Durchhaltevermögen erfordert.

Mein Dank gilt hier Thomas Kluge für sein fachliches Review, neue Denkanstöße und die Motivation. Selbstverständlich darf auch meine Lektorin Julia Auth nicht unerwähnt bleiben, die nicht nur für sprachliche Korrekturen gesorgt hat, sondern auch darauf geachtet hat, dass alles schlüssig ist und zusammenpasst.

Ein abschließender und ganz besonderer Dank gilt meiner wunderbaren Frau Bernadette von Wittern, für ihre Geduld, die vielen Stunden des Zuhörens und dafür, dass sie mich regelmäßig auf den Boden der Tatsachen zurückgeholt hat. Zudem haben sie und unsere beiden Kinder mir die Zeit eingeräumt, dieses Buch schreiben zu können. Sie alle haben Geduld bewiesen, wenn ich mich nicht sofort vom Schreiben lösen konnte.

Nun möchte ich dich nicht länger auf die Folter spannen und meinen AgileTrio Ansatz und meine Gedanken dazu in dieser 1. Ausgabe mit dir teilen.

Jonathan von Wittern

Auf euer Feedback, eure Anregungen sowie Gedanken freue ich mich immer unter:

[email protected]

1. Wie hat sich Softwareentwicklung verändert

Die Softwareentwicklung ist im Vergleich zu anderen Entwicklungsdisziplinen wie Hardware oder Mechanik noch relativ jung. Sie ist jedoch die abstrakteste Disziplin. Software kann nicht angefasst werden und ist oft schwer verständlich für Menschen, die keine Programmierkenntnisse haben. Um als Softwareentwickler*in verständlich zu sein, benötigt man neben Programmierfähigkeiten auch gute Kommunikationsfähigkeiten, um Sachverhalte zu veranschaulichen und zu dokumentieren. Es ist zudem wichtig zu verstehen, dass Software ohne Hardware nicht existieren kann. Dies wird zuweilen übersehen. Wenn es um angemessene Testtiefen geht, verwende ich oft den Spruch „Software läuft nicht in der Luft“.

Die Hardware umfasst physische Komponenten, die benötigt werden, um Software zu speichern und auszuführen. Die Hardware verfügt in der Regel über Schnittstellen, die Ein- und Ausgänge ermöglichen. Diese Schnittstellen können Dateneingänge und -ausgänge sowie Aktoren und Sensoren sein. Die Hardware umfasst auch Speichereinheiten wie Mikrochips und Festplatten, Prozessoren sowie Eingabegeräte wie Maus oder Tastatur.

Die Software besteht aus Verfahren, die in Zusammenarbeit mit der Hardware bestimmte Aufgaben erfüllen. Es handelt sich um geordnete Anweisungen, die Veränderungen in der Hardware bewirken. Dadurch können wir mit der Hardware kommunizieren und interagieren. Menschen tun dies normalerweise über Nutzerschnittstellen. Aber auch andere Hardware oder Sensoren können mit der Hardware interagieren und über geordnete Anweisungen weitere Hardware oder Aktoren ansprechen.

Die Softwareentwicklung begann in den 1950er Jahren, in denen Software und Hardware als unterschiedliche Dinge betrachtet wurden. Es war auch die Zeit der ersten Transistoren, was die Möglichkeit bot, Schaltkreise immer kleiner zu machen. In den 1960er Jahren kamen die ersten Minicomputer auf und die Softwareentwicklung konnte breiter voranschreiten. Gleichzeitig stieg der Bedarf an Software. In den 1970er Jahren wurden mit den Mikrocontrollern Computer immer kleiner und leistungsfähiger.

Jedoch begann 1965 die sogenannte große Software-Krise, die bis etwa 1985 andauerte. In dieser Zeit wurden viele Probleme der Softwareentwicklung identifiziert und bekannt. Budgets und Zeitpläne gerieten regelmäßig außer Kontrolle. Fehlerhafte Software verursachte große Schäden und kostete zum ersten Mal auch Menschenleben. Ein Beispiel dafür sind die Strahlentherapieunfälle Anfang der 1980er Jahre, bei denen fehlerhafte Software dazu führte, dass Geräte eine tödliche Strahlendosis an Patienten*innen abgaben.

Das Wasserfallmodell entstand in dieser Zeit. 1970 veröffentlichte Winston W. Royce eine erste Publikation darüber. Das Ziel war, große Softwareprojekte besser kontrollieren und fatale Fehler vermeiden zu können. Dadurch sollten Kosten, Zeit und Ressourcen besser planbar und kontrollierbar werden.

Das Requirements-Engineering hat ebenfalls seine Ursprünge in den 1970er Jahren. Das Ziel war, Anwenderbedürfnisse durch systematische Anforderungsanalyse besser zu berücksichtigen und umzusetzen. Das Requirements-Engineering wurde entwickelt, um Projekte, die Kosten, Zeit und Ressourcen außer Kontrolle geraten lassen, zu vermeiden.

In den 1980er Jahren entstanden verschiedene Vorgehensweisen und Lösungen, die als „Silver Bullets“ angepriesen wurden, um die Software-Krise zu bewältigen. Doch in den 1990er Jahren setzte die Ernüchterung ein. Fred Brooks veröffentlichte einen Artikel Mit dem Titel „No Silver Bullet“, in dem er argumentierte, dass keine einzelne Technologie oder Praxis innerhalb von zehn Jahren eine 10-fache Verbesserung der Produktivität bewirken würde.

Mit den 1990er Jahren begann der Aufstieg des Internets, was zu einer großen Nachfrage nach unkritischer und anwendungsbezogener Software führte. Die Softwareentwicklung wurde durch Skriptsprachen erleichtert. In dieser Zeit entstand auch das V-Modell als Weiterentwicklung des Wasserfallmodells, das moderate Iterationen ermöglicht. Das Requirements-Engineering entwickelte sich ebenfalls weiter. Die Unified Modeling Language sollte dabei helfen, Software zu modellieren, anstatt sie selbst zu programmieren. Es bot auch die Möglichkeit, Anforderungen visuell darzustellen, anstatt nur sprachlich.

Anfang der 2000er Jahre wurde die ISO/IEC 25000er Reihe [1] veröffentlicht. Sie stellt ein standardisiertes Werk für Anforderungen, Qualität und Bewertung von Softwareprodukten dar. Diese Anforderungen sind wissenschaftlich fundiert und entsprechen dem „Stand der Technik“. Sie werden auch heute noch in der klassischen Softwareentwicklung angewendet.

Mit dem Aufstieg des Internets und der starken Nachfrage nach anwendungsbezogener und unkritischer Software wuchs auch der Frust bei Teilen der Softwareentwicklung über herkömmliche Methoden. Dadurch entstand bis 2001 das Agile Manifesto, das als Ursprung und Basis aller nachfolgenden agilen Vorgehensweisen, Prinzipien und Praktiken gilt.

Kanban hat seinen Ursprung bei Toyota und wurde in den 1940er Jahren zunächst in der Autoproduktion eingesetzt. In der Softwareentwicklung wurde es erst etwa 70 Jahre später, um 2010, erstmals angewendet. Kanban gilt als eine der radikalsten agilen Methoden, die jedoch nur mit großer Teamdisziplin gut funktionieren kann.

Scrum dagegen entstand bereits in den 1990er Jahren durch Jeff Sutherland und Ken Schwaber. Es wurde jedoch erst Anfang der 2000er Jahre bekannt, als beide Vordenker es zum ersten Mal publizierten. Scrum ist ein Time-Boxing-Verfahren, das von Natur aus Disziplin erfordert und als das erfolgreichste agile Vorgehensmodell gilt. Auch im agilen Vorgehen ist Anforderungsmanagement wichtig, jedoch oft direkter, leichter und unvollständiger.

Moderne Ansätze für agile Softwareanforderungen versuchen, systematische Ansätze anzubieten, die das Dokumentieren und Spezifizieren nicht überbetonen, aber dennoch eine Mindestspezifikation bieten. Oft wird die Dokumentation auf Organisationsebene auch als Anforderungsdokumentation für ein Produkt genutzt. Diese Ansätze sind relativ neu und weniger als zehn Jahre alt.

Heutzutage stehen wir vor den Herausforderungen der Digitalisierung in einer schnelllebigen Welt. Unsere Nutzung von Cloud-Services vermittelt uns den Eindruck, dass Hardwareressourcen unbegrenzt verfügbar sind. Software spielt eine zentrale Rolle und wird auch in kritischen Bereichen wie autonomen Fahren, Medizinischer Software, dem Internet der Dinge, maschinellem Lernen und künstlicher Intelligenz eingesetzt. Daher besteht ein wachsender Bedarf an agilen Methoden für streng regulierte Produkte.

Mein Ansatz, den ich in diesem Buch erläutere, ist AgileTrio, das Organisationen und Teams dabei helfen kann, regulierte und qualitativ hochwertige Software flexibel, anpassungsfähig und schnell zu entwickeln. Dabei sollen moderne agile Werte nicht vernachlässigt werden. Dazu wird Scrum mit einem regulierten Framework kombiniert. Darauf werde ich im Kapitel AgileTrio näher eingehen.

Das Bild zeigt die Geschichte der Softwareentwicklung. Es veranschaulicht, wie die wissenschaftlichen Errungenschaften der klassischen Softwareentwicklungen zusammen mit den neueren agilen Methoden und Erkenntnissen genutzt werden können, um die Softwareentwicklung zu verbessern.

In der Softwareentwicklung gibt es einen Trend zur „Deprofessionalisierung“ aufgrund des zunehmenden Einflusses des Internets und mobiler Geräte. Immer mehr Menschen, die keine formale Ausbildung absolviert haben, beteiligen sich am Softwareentwicklungsprozess. Sie lernen das Programmieren autodidaktisch durch Bücher, Kurse oder Tutorials. Zudem entstehen durch Open-Source-Projekte und die globale Vernetzung große Communities, in denen Laien und ausgebildete Softwareentwickler zusammenarbeiten. Dabei werden Programmiersprachen immer einfacher und die Software-Hardware-Kopplung wird gelockert. Das Wissen um bewährte Techniken und die Bedeutsamkeit einer professionellen Ausbildung wird zunehmend inessenziell.

Auf der anderen Seite möchten auch regulierte Produkte und sicherheitskritische Anwendungen von den Möglichkeiten der Softwareentwicklung profitieren. Dadurch steigt die Nachfrage nach Standards und Qualitätssicherung in der Softwareentwicklung. Produkte und Systeme werden immer komplexer und die Software muss permanent mehr Funktionalität umsetzen. Heutzutage ist Software oft kostengünstiger als Hardware, sie altert nicht und ermöglicht eine einfachere Anpassung der implementierten Funktionalitäten.

Die Globalisierung führt dazu, dass Produkte in wachsendem Maße vom raschen Wandel gekennzeichnet sind. Breiter Wettbewerb und gesättigte Märkte erfordern von Unternehmen heute eine schnelle Reaktion, um erfolgreich zu sein. Gesellschaftliche, politische und umweltspezifische Veränderungen führen dazu, dass sich Bedürfnisse rapide ändern und Produktlebenszyklen kürzer werden, es sei denn, man kann schnell darauf reagieren.

Daher ist es legitim, dass Startups und junge Unternehmen mit agilen Methoden und Werten auch in streng regulierte Bereiche vordringen und versuchen, innovativ und unternehmerisch zu sein. Dennoch gelten für sie die gleichen Anforderungen an Regulierung und Qualität wie für etablierte Organisationen, die traditionelle Wege gehen. Startups müssen sich und ihre Softwareentwickler*innen professionalisieren, um dem entgegenzuwirken und sich erfolgreich auf dem regulierten Markt behaupten zu können.

In diesem Kontext unterstützt der AgileTrio Ansatz mit einem eingebetteten regulierten Framework. Das Framework stellt Leitlinien bereit, die dem Entwicklungsteam den richtigen Weg zeigen sollen, um schnell, aber gleichzeitig nutzerzentrierte und hochwertige Softwareprodukte liefern zu können.

2. Klassisches Vorgehen

Ich habe meine Karriere um das Jahr 2000 in einem mittelständischen Unternehmen für Medizinprodukte im Bereich minimalinvasive Chirurgie begonnen. Dieses Unternehmen war zum damaligen Zeitpunkt bereits weltweit führend auf diesem Gebiet. Es wurde von der einzigen Tochter des Gründers matriarchalisch geführt und hatte den Ruf, familiär und traditionell zu sein. Alle Entscheidungen wurden ausschließlich von der Geschäftsführerin getroffen, selbst wenn dies bedeutete, dass man Monate auf einen neuen Bürostuhl warten musste. Es gab eine strenge Hierarchie, viel Unternehmenspolitik und alles lief über Beziehungen. Jeder kannte seinen Platz.

Ich war damals 16 Jahre alt und hatte wenig Berufserfahrung. Wahrscheinlich war es positiv für mich, dass die Geschäftsführerin sich wie eine Mutter einer großen Familie um die Belegschaft kümmerte. Ich blieb dort zehn Jahre, absolvierte meine Ausbildung sowie meine erste Fortbildung und entdeckte meine Begeisterung für die Entwicklung von hardwarenaher Software. Während meiner Zeit dort hat das Unternehmen seine Mitarbeiterzahl und seinen Umsatz verdoppelt.

Mikrocontroller, Embedded Systeme und Field Programmable Gate Arrays als Teil von Produkten und damit auch Software begannen sich zu diesem Zeitpunkt zu etablieren. Eigentlich waren diese Technologien damals bereits etwa zehn Jahre alt, aber in der Medizintechnik konnte man bezüglich der technologischen Entwicklung nicht mithalten. Neue Technologien müssen sich erst als sicher und zuverlässig erweisen, bevor sie in der Medizintechnik eingesetzt werden können. Forschung und Entwicklung sind häufig strikt voneinander getrennt. Wenn Technologien in die Entwicklung einbezogen werden, sind sie in der Regel gut erforscht und ausgereift. Der Schwerpunkt liegt in der Entwicklung darauf, eine stabile Reproduzierbarkeit von Produkten zu erreichen, um später eine gute und sichere Produktion gewährleisten zu können.

Solche Unternehmen sind oft stark technologieorientiert und berücksichtigen nicht immer die Bedürfnisse und Probleme der Nutzenden in ihren Entscheidungen. Produktentwicklungen dauern in der Regel drei bis fünf Jahre und spiegeln meist inkrementelle Innovationen wider. So werden bekannte Klinische Anwendungen mit anderer existierender Technologie versorgt. Dies wird oft durch Bauteilabkündigungen verursacht, die sich nicht leicht kompensieren lassen. Alternativ wird die gleiche Technologie für ähnliche oder alternative Klinische Anwendungen verwendet. Auch hier vorzugsweise inkrementell, da die Klinische Anwendung meist schon bekannt ist, aber alternativ eingesetzt wird.

Es wird demnach ein konservatives oder ausbalanciertes Wachstumsportfolio angestrebt. Dieses folgt dem 70-20-10 Modell von Eric Schmidt und Sergey Brin [2]. Dabei gehen 70% der Ressourcen in inkrementelle Innovationen, 20% in neue Märkte für das Unternehmen oder aktuellere Technologie für bestehende Märkte und 10% in die Forschung. Somit ergeben sich für regulierte Märkte wie der Medizintechnik feste Rahmenbedingungen und eine stabile Umgebung, was ideal für klassisches Projektmanagement ist.

Das Denken in Projekten

Ein Projekt zielt darauf ab, von einem bestehenden Zustand zu einem neuen Zustand zu gelangen. Dabei kann der bestehende Zustand entweder bereits ein Produkt sein, das im neuen Zustand verbessert werden soll, oder es handelt sich um eine Produktidee. Der neue Zustand ist das entwickelte Produkt, das die Bedürfnisse der Nutzenden erfüllen oder ihre Probleme lösen soll.

Das Projektmanagement umfasst verschiedene Aufgaben, die zur Führung gehören und von speziellen Projektmanagern*innen übernommen werden. In einer Matrixstruktur liegt die fachliche Führung normalerweise bei den Projektmanagern*innen. Wenn das Unternehmen jedoch in Projektteams unterteilt ist, kann es sein, dass die Projektmanager*innen zusätzlich die disziplinare Führung ihrer Teams übernehmen.

Das Projektmanagement beinhaltet die Initiierung, Planung, Steuerung, Organisation, Durchführung, Kontrolle und den Abschluss von Projekten. Es ist ein wichtiger Bestandteil der Arbeitsorganisation in vielen Unternehmen, um die besten Ergebnisse in einer komplexen und globalen Arbeitsumgebung zu erzielen. Es schafft Struktur, klärt Ressourcen, definiert Schnittstellen und Vorgehensweisen.

Initiierung – Die Initiierung eines Projektes verwandelt eine vage Idee in einen verbindlichen Projektauftrag. Dabei werden üblicherweise Fragen zur Ressourcenplanung, Meilensteinen und Rentabilität geklärt. Es ist wichtig zu prüfen, ob das Projekt mit den vorhandenen Ressourcen umgesetzt werden kann und ob es zur Strategie und Wirtschaftlichkeit der Organisation passt. Projekte innerhalb einer Organisation konkurrieren ständig um begrenzte Ressourcen. Aus diesem Grund haben viele Organisationen ein Projektportfolio, in dem Projekte miteinander verglichen werden. Es wird zudem überlegt und festgelegt, welche Aufgaben mit internen Ressourcen bewältigt werden können und welche Projekte oder Projektteile externe Unterstützung benötigen. Das Ergebnis dieser Initiierung ist normalerweise ein Projektvertrag.

Planung – Die Planung von komplexen Projekten umfasst den Einsatz von Ressourcen, die Festlegung des Ablaufs, der Termine und der Projektkosten. Außerdem werden die Ziele in überschaubare Arbeitspakete aufgeteilt. Es wird überprüft, ob die Vorgaben des Auftraggebenden realistisch sind. Um die Abhängigkeiten zwischen den drei Hauptfaktoren Kosten, Zeit und Ergebnisse zu verdeutlichen, wird das magische Dreieck verwendet:

Die drei Faktoren - Qualität der Ergebnisse und Funktionalität, Zeit und Kosten - sind untrennbar miteinander verbunden. Eine Veränderung eines Faktors wirkt sich zwangsläufig auf die anderen beiden aus. Es ergeben sich unterschiedliche Projektstrategien, je nachdem, welcher Faktor priorisiert wird:

• Best-to-Market: Hier steht die Qualität der Ergebnisse und Funktionalität im Vordergrund. Ziel ist es, am Markt neue Kunden*innen besonders gut anzusprechen.

• Time-to-Market: Hier liegt der Fokus auf der Zeit. Das Ziel ist es, so schnell wie möglich am Markt präsent zu sein und dadurch die Konkurrenz zu überholen.

• Design-to-Cost: Hier stehen die Kosten im Mittelpunkt. Das Ziel ist es, die Kosten bis zum Markteintritt zu reduzieren, sei es durch Materialkosten oder Produktionskosten, um am Markt profitabler zu sein.

Oftmals scheitert das Projekt bereits an diesem Punkt, da Auftraggebende oder Stakeholder am liebsten in allen drei Bereichen erfolgreich sein möchten. Das Ergebnis dieser Planung ist ein konkreter Projektplan.

Steuerung – Die Projektleitung nutzt die Zahlen und Berichte des Controllings, um das Projekt zu steuern. Dabei müssen Anpassungen basierend auf Kennzahlen zu Kosten, Qualität, Ressourcen, Kommunikation, Risikomanagement, Beschaffung, Stakeholder-Erwartungen sowie Projektzielen und -umfang vorgenommen werden. Es kommt häufig vor, dass Projekte nicht wie geplant verlaufen. Ressourcen stehen nicht rechtzeitig zur Verfügung, Lösungen funktionieren nicht wie erwartet, Mitarbeitende sind nicht uneingeschränkt verfügbar, die Erwartungen der Stakeholder ändern sich und das Projektumfeld ist im ständigen Wandel. Die Steuerung des Projekts befasst sich mit den erforderlichen Anpassungen.

Organisation – Die Organisation von Projekten befasst sich mit den Rahmenbedingungen der Organisation. Dabei geht es um die Verantwortung der Projektführung, Entscheidungsbefugnisse, erforderliche Fachkenntnisse, interne Kommunikation im Projekt und die Kommunikation mit externen Interessengruppen sowie die Verfügbarkeit von Ressourcen. Oftmals treffen hier die Matrixstruktur und die Projektumgebung aufeinander. Das bedeutet, dass Projektmitarbeitende häufig nicht ausschließlich dem Projekt gewidmet sind, sondern auch noch Aufgaben innerhalb der Organisationsstruktur erledigen müssen. Es kann auch vorkommen, dass Projektmitarbeitende noch für weitere Projekte zuständig sind, die sie ebenfalls betreuen müssen. Konflikte treten in einer schwach organisierten Projektstruktur häufig auf.

Durchführung – Die Durchführung eines Projekts umfasst das Umsetzen der Projektpläne mit den vorhandenen Ressourcen, innerhalb der vereinbarten Kosten und innerhalb der zuvor festgelegten Zeit. Dabei müssen verbindliche Ergebnisse erzielt werden. Es ist wichtig, Abhängigkeiten und Engpässe zu berücksichtigen und entsprechend damit umzugehen. In klassischen Organisationen, insbesondere im regulierten Umfeld, wird die Durchführung oft nach dem V-Modell in Kombination mit dem Stage-Gate-Ansatz durchgeführt. Es gibt aber auch andere Vorgehensweisen zur Durchführung, die gewählt werden können.

Kontrolle – Die Kontrolle sorgt dafür, dass die Projektziele erreicht werden. Sie beginnt bereits bei der Initiierung, indem Projekte im Portfolio priorisiert werden. Während der Durchführung werden Kennzahlen verwendet, um kontinuierlich Zeit, Kosten und Qualität des Projekts zu überprüfen und sicherzustellen, dass die Ziele erreicht werden können. Dafür werden verschiedene Berichte erstellt, die sowohl den Stakeholdern als auch dem Projektteam den aktuellen Stand des Projekts zeigen. Diese Berichte ermöglichen es, Entscheidungen zu treffen und bei Bedarf einzugreifen, um das Projekt zu lenken.

Abschluss – Ein Projektabschluss beginnt normalerweise mit einer Übergabe. Die Übergabe kann an die Fertigung, einen neuen Besitzenden, IT-Operations oder einen anderen Stakeholder erfolgen. Häufig sind damit Abnahmeinspektionen, Schulungen oder Inbetriebnahmen verbunden. Diese Übertragung oder der Transfer ist ein kritischer Schritt, bei dem Ergebnisse weitergegeben werden. Da sich das Projektteam in der Regel nach Abschluss auflöst, ist es für den Empfangenden oft schwierig, nachträgliche Korrekturen zu erhalten. Das Projektteam muss auch darauf achten, dass berechtigte Nachforderungen gestellt werden und nicht zu übertriebenen Forderungen führen. Im Projektmanagement ist es zudem ratsam, eine Retrospektive durchzuführen, um aus dem Projektablauf zu lernen und Erfahrungen in zukünftige Projekte einfließen zu lassen.

Projektarbeit in Matrix- oder Linienstrukturen kann für Mitarbeitende eine willkommene Abwechslung im täglichen Geschäft bieten. In solchen Organisationen beschränkt sich die Rolle der Mitarbeitenden oft nur auf ihre Aufgaben innerhalb von Prozessen, während die Mitarbeit an Projekten mehr Vielfalt ermöglicht. Es fördert die Zusammenarbeit mit anderen Abteilungen und erweitert den Horizont. Durch zielgerichtetes Arbeiten kann man den Fortschritt innerhalb eines Projektes besser verfolgen und nachvollziehen. Die individuellen Beiträge der Teammitglieder sind dabei oft deutlicher erkennbar als im Alltagsgeschäft. Es kann sehr motivierend sein, einen Unterschied zu machen.

Ein weiterer großer Vorteil des Projektmanagements besteht darin, dass es Struktur und Ordnung schafft. Insbesondere bei komplexen Projekten mit vielen externen Schnittstellen und Abhängigkeiten ist eine sorgfältige und vorausschauende Planung wichtig, um Engpässe und lange Wartezeiten zu vermeiden. Projektmanagement bietet einen effektiven und robusten Ansatz, um gewünschte Ergebnisse zu erzielen, insbesondere für strenger regulierte Produkte mit klar definierten Vorgaben und stabilem Umfeld. Wenn die Vorgaben unklar sind und das Umfeld instabil ist, geraten Projekte oft an ihre Grenzen. In solchen Fällen funktionieren agile Ansätze meist besser, wie später im Kapitel Agiles Vorgehen erläutert wird.

Für diejenigen, die mehr über Projektmanagement erfahren möchten, empfehle ich das Buch „Handbuch Projektmanagement - Agil - Klassisch - Hybrid“ [3]. Ich stehe dem Thema agiles Projektmanagement kritisch gegenüber. Im Kapitel Agiles Vorgehen wird darauf hingewiesen, dass ich im agilen Ansatz bevorzugt von Produkten statt von Projekten spreche. Trotzdem empfehle ich definitiv, das Buch anzuschauen.

V-Model

Ich habe das V-Modell aus den klassischen Vorgehensmodellen für Entwicklungsprojekte ausgewählt. Es ist das häufigste Modell in regulierten Umgebungen und eignet sich besonders gut für die Entwicklung von physischen Medizinprodukten. Im agilen Umfeld wird oft behauptet, dass das V-Modell nichts anderes als ein Wasserfallmodell sei. In diesen Kreisen wird alles außerhalb agilen Vorgehens als Wasserfallmodell bezeichnet. Ich halte das für sehr undifferenziert und es ist meistens ein Anzeichen dafür, dass man stark vom agilen Ansatz überzeugt ist. Menschen mit dieser Einstellung beschränken sich bewusst in ihren Möglichkeiten, Produkte zu entwickeln. Das V-Modell ermöglicht, in Kombination mit dem Stage-Gate-Ansatz, moderate Iterationen. Ein Wasserfallmodell hingegen ermöglicht das nicht.

Das V-Modell besteht aus drei Hauptphasen: Spezifikation, Implementierung und Test. In der Spezifikationsphase werden die Anforderungen festgelegt und in der Implementierungsphase wird die Software entwickelt. Die Testphase dient der Überprüfung der Funktionalität. Das V-Modell wurde ursprünglich im Jahr 1979 von Barry Boehm entwickelt [4]. Es wurde jedoch erst um die Jahrtausendwende weitgehend anerkannt und fand Eingang in viele Standards und Normen als repräsentatives Modell. Ein Beispiel dafür ist der Standard EN IEC 62304 [5], der das V-Modell als Grundlage verwendet. Es ist jedoch wichtig zu beachten, dass der Standard nicht zwingend die Verwendung dieses Modells vorschreibt.

Spezifikationsphase – Während der Spezifikationsphase werden Nutzeranforderungen erfasst und definiert. Technische Anforderungen werden in unterschiedlicher Detailtiefe spezifiziert, abhängig von der Komplexität der Entwicklung. Diese umfassen Systemanforderungen, Software-/Hardware-/Mechanische Anforderungen, Komponentenanforderungen, Einheitenanforderungen sowie detailliertes Design und Architektur. Das Produkt wird dabei schrittweise in seine Bestandteile zerlegt und diese werden spezifiziert. Die Tiefe und Detailgenauigkeit der Spezifikation hängen oft von der Komplexität und dem Risiko, das vom Produkt ausgehen kann, ab. Insbesondere im streng regulierten Umfeld steht die Betriebssicherheit im Vordergrund. Bei Flugzeugen, Autos, Kraftwerken, elektrischen Geräten oder Medizinprodukten ist es unabdingbar, sorgfältig zu prüfen, welche Aspekte berücksichtigt werden müssen. Eine nachlässige oder ungenaue Spezifikation kann oft zu unnötigen Risiken für Endanwendende oder die Umwelt führen.

Implementierungsphase – In der Implementierungsphase werden die Anforderungen umgesetzt. Dabei wird die Funktionalität entsprechend in Hardware, Software oder Mechanik implementiert. Es ist wichtig, darauf zu achten, dass alles später zusammenpasst. Dafür werden oft genaue Schnittstellen spezifiziert, an die sich alle halten müssen. So können auch sehr große und komplexe Projekte mit vielen Teammitgliedern, verschiedenen Disziplinen und Fachwissen, die auf interne Mitarbeitende und externe Partner*innen verteilt sind, umgesetzt werden.

Testphase – Während der Testphase werden die entsprechenden Testfälle durchgeführt. Diese werden oft gleichzeitig mit der Spezifikation erstellt. Die Verifizierung beginnt mit den Einheitentests und geht dann über Komponententests, Integrationstests und Systemtests zur Validierung. Man erreicht erst dann die nächste Stufe, wenn die Testergebnisse positiv und akzeptabel sind. Wenn Probleme auftreten, kehrt man zur Spezifikationsphase zurück und iteriert moderat. Das Ziel besteht darin, alle Anforderungen aus der Spezifikationsphase durch positive Testfälle zu bestätigen. Test Driven Development kann hier genutzt werden. Es wird allerdings nicht sofort gegen die Testfälle implementiert. Bei Test Driven Development werden die Testfälle und die Spezifikation der Anforderungen gleichzeitig formuliert. Mehr zu dieser Technik im Kapitel Verifizierung. Folgende Grafik stellt das V-Modell dar:

Das V-Modell unterscheidet sich deutlich vom Wasserfallmodell. Im V-Modell werden Testfälle normalerweise gleichzeitig mit der Spezifikation erstellt. Für den Fall, dass während der Testphase etwas schiefgeht, werden Tests auf höherer Ebene nicht fortgesetzt. Stattdessen wird ein Schritt zurück zur Spezifikationsphase gemacht, um das Problem zu lösen. Dadurch ergeben sich Möglichkeiten, das Produkt durch moderate Iterationen anzupassen.

Ich persönlich habe das Entwickeln nach dem V-Modell insbesondere in Luftfahrtprojekten im streng regulierten Umfeld kennengelernt. Bei der Mitentwicklung eines Flugzeugs gibt es wenig Spielraum für Experimente und Lernen aus Fehlern. Es arbeiten viele Organisationen und Teams an einem komplexen System zusammen. Die Anforderungen an einzelne Flugzeugkomponenten müssen sehr detailliert und umfassend definiert werden. Die Implementierung muss den Anforderungen entsprechen und funktionieren. Wenn dies nicht der Fall ist, passt die entwickelte Komponente nicht zu den anderen Komponenten im Flugzeug. Wenn eine Komponente nicht zuverlässig funktioniert, kann dies im schlimmsten Fall die Sicherheit des Flugzeugs und die Menschen gefährden.

Der A350 von Airbus fliegt seit 2015. Bis heute wurden etwas mehr als 500 Stück ausgeliefert. Etwas mehr als 400 weitere sind in Auftrag gegeben worden. 37 gemeldete Zwischenfälle sind bis Anfang 2023 bekannt geworden. Keiner der Vorfälle führte zu Abstürzen oder Unfällen mit Todesopfern.

Das Entwickeln nach dem V-Modell in Projekten kann demnach Produkte ermöglichen, bei denen zahlreiche Organisationen an einem komplizierten System zusammenarbeiten und es zum Schluss bei der Nutzung des Produktes, kein Spielraum für Fehler gibt.

Moderate Iterationen durch Stage-Gate

Einen richtigen Schub bekommt das V-Modell durch Robert G. Coopers Stage-Gate Phasenmodell [6]. Cooper hat das Modell im Laufe der Zeit weiterentwickelt. Das Stage-Gate Phasenmodell zeigt fünf Phasen für die Produktentstehung auf. Jeder Übergang von einer Phase zur nächsten erfolgt über ein Gate, das passiert werden muss. Das V-Modell wird innerhalb der Phasen immer wieder durchlaufen, jedoch mit unterschiedlicher Gewichtung von Produktmanagement und Entwicklung. Dies gilt auch innerhalb der Entwicklung selbst, speziell in der Spezifikationsphase, Implementierungsphase und Testphase. Die Gates dienen als konkrete Design Reviews, wie sie oft in regulierten Umgebungen gefordert werden. Folgendes Bild zeigt den Ablauf des Stage-Gate Phasenmodells:

Hier sind in den einzelnen Stages und Gates folgende Schwerpunkte vorgesehen:

• Stage 1 – Ideenfindung: Bei der Ideenfindung werden Nutzerbedürfnisse und Probleme erkannt, analysiert und mit der Unternehmensstrategie abgeglichen. Darauf basierend werden Ideen generiert, angereichert, bewertet und es werden vielversprechende Ideen weiterverfolgt.

• Gate 1 – Ideenprüfung: In der Ideenprüfung werden Ideen grob anhand von Kosten-Nutzen-Überlegungen und begrenzten Ressourcen ausgewählt. Anhand detaillierter Kennzahlen wird dann entschieden, ob diese Ideen umgesetzt werden sollen. Die Entscheidung basiert auf Zahlen, Daten und Fakten, nicht auf Bauchgefühl. Die Auswahlkriterien müssen transparent sein.

• Stage 2 – Konzept: In der Konzeptphase werden detaillierte Nutzeranforderungen festgelegt. Diese werden mit den Nutzenden an Modellen oder Prototypen bewertet und die technische Machbarkeit geprüft. Es werden auch rechtliche und regulatorische Anforderungen identifiziert und ein konkreter Businessplan erstellt, der die Wirtschaftlichkeit, Absatzplanung und Prognosen berücksichtigt.

• Gate 2 – Entwicklungsfreigabe: Bei der Entwicklungsfreigabe wird überprüft, ob alle Nutzeranforderungen erfasst worden sind und diese bestimmte Qualitätskriterien erfüllen. Es wird auch die technische Machbarkeit und wirtschaftliche Umsetzbarkeit bewertet. Es wird geprüft, ob ein ausgereifter Businessplan inklusive Finanzplanung vorhanden ist.

• Stage 3 – Entwicklung: In der Entwicklungsphase wird das Konzept zur Marktreife gebracht. Es werden konkrete technische Anforderungen erstellt, verschiedene Varianten und Designs diskutiert und Entscheidungen getroffen. Es werden erste Prototypen hergestellt und die Produktionsplanung oder IT-Operations-Infrastruktur vorbereitet.

• Gate 3 – Testfreigabe: Für die Testfreigabe werden das technische Design und dessen Dokumentation auf Qualitätskriterien überprüft. Die Prototypen müssen einen gewissen Reifegrad erreicht haben und die Testpläne für Verifizierung und Validierung müssen ausgereift sein. Es müssen erste Lieferanten evaluiert werden, um vollständige Prototypen zu erstellen oder eine IT-Operations-Infrastruktur aufzubauen.

• Stage 4 – Verifizierung & Validierung: In der Verifizierungs- und Validierungsphase wird das Produkt auf technische Korrektheit überprüft und zusammen mit den Nutzenden auf Tauglichkeit validiert. Dies geschieht in verschiedenen Testläufen. Der Marketingplan wird abgeschlossen und der Vertrieb sowie die Produktion oder finale IT-Operations werden vorbereitet.

• Gate 4 – Freigabe der Einführung: Vor der Freigabe der Einführung werden die Ergebnisse der Verifizierung und Validierung überprüft. Die ausgewählten Lieferanten werden bewertet. Es wird evaluiert, ob regulatorische und gesetzliche Vorschriften eingehalten werden. Die Pläne für Marketing und Vertrieb werden gesichtet. Zudem wird die Qualität und Vollständigkeit der Pläne und Umsetzung für den Designtransfer in die Produktion oder IT-Operations-Infrastruktur begutachtet.

• Stage 5 – Produktion & Markteinführung: In der Produktion und Markteinführung wird die Qualitätsüberwachung finalisiert. Es werden Service-, Wartungs- und andere produktbegleitende Dienstleistungen eingerichtet. Die Marketing- und Vertriebsmaterialien werden fertiggestellt und das Personal wird geschult. Es wird eine abschließende Wirtschaftlichkeitsanalyse für den gesamten Produktlebenszyklus durchgeführt. Das Produkt wird registriert und schließlich auf den Markt gebracht.

Wenn ein Gate nicht passiert wird, weil die vorangegangene Phase nicht die erwarteten Ergebnisse liefert, hat der Auftraggebende zwei Möglichkeiten: entweder das Projekt abzubrechen oder das Entwicklungsteam durchläuft eine weitere Iteration der vorangegangenen Phase. Dadurch wird eine bessere Kontrolle der Kosten und des Nutzens im Vergleich zum einfachen V-Modell erreicht.

In jeder Phase des Stage-Gate Phasenmodells werden verschiedene Schwerpunkte gesetzt, wie Produktvision, Nutzeranforderungen, technische Anforderungen an Systeme, Software, Hardware oder Mechanik, Implementierung, Verifizierung und Validierung sowie Produktüberleitung. Diese Schwerpunkte haben unterschiedliche Ausprägungen in den einzelnen Phasen. Zu Beginn stehen Produktvision und Nutzeranforderungen im Fokus, in den mittleren Phasen liegen die technischen Anforderungen sowie Implementierung und Verifizierung im Vordergrund, und am Ende stehen Validierung und Produktüberleitung.

Das bedeutet jedoch nicht, dass in den moderaten Iterationen in der letzten Phase keine Anpassungen an Nutzeranforderungen oder sogar der Produktvision vorgenommen werden können. Zwar sollten in der letzten Phase keine großen Änderungen mehr umgesetzt werden, aber kleinere Anpassungen sind immer noch möglich.

Das folgende Bild zeigt eine mögliche Gewichtung der Fokusthemen über die Phasen des Stage-Gate Phasenmodells:

Die Kombination des V-Modells mit dem Stage-Gate Phasenmodell begünstigt infolgedessen moderate Iterationen in der Produktentstehung. Die Produktentstehung erfolgt dabei als Projekt. Das sorgt für eine gute Balance an Änderungsmöglichkeit und Stabilität, die besonders in einem regulierten Umfeld mit vielen Kontrollmechanismen oft einem optimalen Vorgehen entspricht. Aus diesem Grund ist dieser Ansatz das gängigste Vorgehen im regulierten Umfeld und erlaubt komplizierte Produkte entwickeln zu können.

Mehr zum Thema chaotische, komplexe, komplizierte und einfache Situationen, erklärt am Cynefin-Framework, im Kapitel Agiles Vorgehen. Komplexe Vorhaben werden durch das Vorgehen über die einzelnen Stages zu komplizierten Vorhaben heruntergebrochen. Ursache und Wirkung sollten bei jedem streng regulierten Produkt spätestens vor Markteinführung bekannt sein.

Neue und innovative Ansätze werden dagegen oft entkoppelt und als Forschung separat abgehandelt. Das wiederum erklärt das Phänomen, das beispielsweise in der Medizintechnik oft Technologie eingesetzt wird, die bereits acht bis zehn Jahre zuvor ihren Durchbruch hatte.

Es ist wichtig anzumerken, dass das hier beschriebene V-Modell und Stage-Gate Phasenmodell nur beispielhaft ist. Jede Organisation muss ihr eigenes spezifisches V-Modell und Stage-Gate Phasenmodell definieren, das zu ihren Produkten, ihrem Umfeld, ihrer Strategie, ihrer Organisationsstruktur und ihren Mitarbeitenden passt. Die Tiefe des V-Modells kann je nach Kritikalität und Komplexität des Produkts oder Systems variieren. Der untere Teil des V-Modells kann auch in separate V-Modelle für verschiedene Disziplinen wie Mechanik, Hardware und Software aufgeteilt werden. Es ist demnach wichtig, das Vorgehen an die individuellen Gegebenheiten anzupassen.

3. Klassisches Mindset

Während ich bei meiner Arbeitsweise gerne sowohl klassisches als auch agiles Vorgehen verwende und dabei angepasst an das Problem verfahre, kann ich das vom klassischen Mindset nicht behaupten. Ich gehöre der Generation Y an und wie bei vielen jungen Menschen meiner Generation sind Konkurrenz- und Bürokratiewerte nicht so stark ausgeprägt, wie bei den Generationen davor. Ich erinnere mich an eine Situation bei meinem ersten Arbeitgeber, in der ich mit meinem Vorgesetzten eine Diskussion über meine hohe Vergütung hatte. Aus meiner Sicht wäre es Verschwendung gewesen lediglich meine Hände zum Arbeiten zu benutzen, wenn ich dem Unternehmen zusätzlich durch meine Denkfähigkeit mehr Nutzen hätte bringen können. Ich war damals im technischen Service tätig und habe elektrische Medizinprodukte repariert.

Bereits in jungen Jahren war es mir wichtig, mich beruflich aktiv einzubringen und Entscheidungen selbst zu treffen. Das einfache Befolgen von Anweisungen entsprach nicht meiner Vorstellung von sinnvoller Arbeit. Im Regelfall benötige ich keinen Vorgesetzten, um adäquate Entscheidungen zu treffen. Außerdem neige ich dazu, improvisieren zu wollen, anstatt mich streng an Vorgaben und Prozesse zu halten.

Meine Konsenswerte sind weniger stark ausgeprägt. Das führe ich auf die Tatsache zurück, dass ich mit einer großen Anzahl von Geschwistern aufgewachsen bin. Dafür sind meine Entrepreneurwerte stärker ausgeprägt, was dazu führen kann, dass ich dem Vorgesetzten gegenüber betone, dass meine Loyalität der Organisation gilt und nicht lediglich ihm.

Das zeigt, dass jeder Mensch oder auch Arbeitnehmende eigene Bedürfnisse hat. Früher wurde dies mithilfe der Maslowschen Bedürfnispyramide erklärt. Doch wie nahezu jedes Forschungsgebiet hat auch die Neuropsychologie Fortschritte gemacht. Heute verwenden wir den Spiral Dynamics Ansatz von Don Beck und Chris Cowan [7]. Richard Barrett hat daraus das „Barrett Modell“ entwickelt, das 2011 [8] veröffentlicht wurde und heute oft für Persönlichkeits- und Führungskräfteentwicklung genutzt wird. Das Modell beschreibt sieben Bewusstseinsebenen:

1. Lebensfähigkeit – Befriedigung unserer körperlichen Bedürfnisse und Überlebensbedürfnisse Angst: Ich habe nicht genug

2. Beziehungen – Sich beschützt und geliebt fühlen.

Angst: Ich werde nicht genug geliebt

3. Leistung – Gefühl des Selbstwertgefühls

Angst: Ich bin nicht genug

4. Evolution – Ängste loslassen. Den Mut, sich weiterzuentwickeln und zu wachsen

5. Ausrichtung – Sinn in der Existenz finden

6. Zusammenarbeit – Einen positiven Unterschied in der Welt bewirken

7. Beitrag – Selbstloser Dienst

Richard Barrett hat die sieben Ebenen in drei Bereiche unterteilt.

Der Bereich der ersten drei Ebenen – Lebensfähigkeit, Beziehungen und Leistung – betonen unser persönliches Interesse. Sie beinhalten das Erfüllen unserer Bedürfnisse nach Sicherheit, Liebe und Zugehörigkeit sowie das Streben nach Stolz und Zufriedenheit mit uns selbst. Wenn diese Bedürfnisse erfüllt sind, fühlen wir uns nicht dauerhaft befriedigt, aber wir empfinden Ängste, wenn sie nicht erfüllt werden.

Im Bereich der vierten Ebene – Evolution – liegt der Fokus auf dem Loslassen von Ängsten. Hier entwickeln wir ein Bewusstsein für unsere persönliche Autorität und unsere eigene Stimme. In dieser Phase entscheiden wir uns dafür, nach unseren innersten Werten und Überzeugungen zu leben.

Der Bereich der oberen drei Ebenen – Ausrichtung, Zusammenarbeit und Beitrag – konzentriert sich auf unser Bedürfnis, Sinn und Zweck in unserem Leben zu finden. Wir drücken diese Bedeutung aus, indem wir danach streben, unsere Welt zu verbessern und selbstlos zu dienen. Wenn diese Bedürfnisse erfüllt sind, entsteht eine tiefere Motivation und Hingabe. In diesen Bereichen lernen wir, unseren inneren Kompass zu entwickeln, der uns dabei hilft, positive Entscheidungen zu treffen, die das Leben bejahen.

Richard Barrett stellt fest, dass Menschen, die ausschließlich ihre persönlichen Grundbedürfnisse im Blick haben, von Ängsten beeinflusst werden können und nach Zustimmung oder Bestätigung anderer suchen. Wenn sich Menschen ausschließlich auf die Erfüllung des dritten Bereichs konzentrieren, fehlen ihnen möglicherweise die Fähigkeiten, um praktisch und effektiv zu handeln, wenn es um ihre Grundbedürfnisse geht. Die erfolgreichsten Menschen, so Barett sind diejenigen, die alle sieben Ebenen miteinander in Einklang bringen. Sie vertrauen anderen, können mit Komplexität umgehen und sich an unterschiedliche Situationen anpassen.

Laut Richard Barrett operieren Menschen jedoch nicht nur auf einer einzigen Bewusstseinsebene. In der Regel konzentrieren sie sich auf drei oder vier Ebenen. Gewöhnlich richten sich Individuen auf die Ebenen eins bis fünf aus und legen dabei besonderes Augenmerk auf die Suche nach dem Sinn des Lebens in der fünften Ebene.

Wenn man die gesellschaftliche Verteilung basierend auf persönlichen Werteeinschätzungen betrachtet, stellt man fest, dass etwa 50% der Menschen ihre Werte auf die ersten drei Ebenen ausrichten. Weitere 30% fokussieren sich auf die vierte Ebene, was Selbstreflexion und den Mut beinhaltet, sich den eigenen Ängsten zu stellen und an sich zu arbeiten. Die letzten 20% legen ihren Schwerpunkt auf die Werte des dritten Bereichs.

Der Wunsch nach Sicherheit, Ordnung, Zugehörigkeit und persönlichem Eigeninteresse ist demnach in der Gesellschaft weit verbreitet und erklärt auch die starke Prävalenz konservativer und klassischer Denkmuster. Traditionelle Managementmodelle und starke Hierarchien unterstützen und spiegeln diese Werte bevorzugt wider.

Managementmodelle

Um zu verstehen, warum das klassische Mindset immer noch so dominant ist, ist es hilfreich, sich mit den Managementmodellen von Alfred Oswald [9] auseinanderzusetzen. Organisationen unterliegen im Laufe der Zeit Veränderungen, die durch sich wandelnde Geschäftsfelder, -modelle und neue Technologien vorangetrieben werden. Neue Geschäftsmodelle, die besser auf die Bedürfnisse von Nutzenden und Kunden*innen eingehen oder ressourcenschonender sind, zerstören alte Geschäftsmodelle und manchmal auch ganze Organisationen, wenn sie nicht selbst innovativ sind. Mit neuen Geschäftsmodellen ändert sich oft auch die interne Struktur. Verantwortlichkeiten werden neu verteilt, Entscheidungsbereiche verlieren an Einfluss, während andere an Bedeutung gewinnen. Mitarbeitende wechseln dann entweder weiter zu anderen Organisationen oder werden Teil neuer Strukturen.

Ein weiterer großer Einflussfaktor, der Organisationen verändert, ist der soziologische Aspekt. Unterschiedliche Generationen haben unterschiedliche Wertvorstellungen. Jede Generation wird von der Zeit geprägt, in der sie aufwächst. Seit 1922 gibt es sechs verschiedene Generationen, die sich wie im Bild gezeigt aufteilen:

Entsprechend der Wertevorstellungen der einzelnen Generationen, ist auch das darauffolgende Arbeitsleben und die Art des Arbeitens geprägt. Daraus ergeben sich aktuell drei Modelle des Managements:

• Management 1.0 – geprägt durch Industrialisierung und Taylorismus: Dieses Management-Modell basiert auf dem Taylorismus und ist klassisch und etabliert. Die Arbeit wird in Prozessschritte aufgeteilt, wobei jeder Mitarbeitende für einen Schritt verantwortlich ist. Es gibt eine klare Hierarchie im Management, bei der Ziele, Entscheidungen und Verantwortung von oben nach unten weitergegeben werden. Hierarchie und Arbeitsteilung bieten den Mitarbeitenden einen Rahmen, innerhalb dessen sie handeln können.

Das Top-Management kümmert sich um die strategische Ausrichtung des Unternehmens. Das Management in den unteren Ebenen ist für die Umsetzung der Strategie zuständig, indem es Prozessschritte festlegt, und die benötigten Ressourcen, Zeit und Mitarbeitenden plant. Die Unternehmensziele sind klar definiert und alle kennen ihren Platz und ihre Aufgaben. Dies kann den Mitarbeitenden ein Gefühl von Sicherheit und Stabilität vermitteln.

Die Überwachung und Kontrolle stellen sicher, dass die Unternehmensziele und die Qualität erreicht werden. Das Management kann Anpassungen und Korrekturen vornehmen. Die Verantwortung wird nach oben weitergegeben, sodass letztendlich das Top-Management oder die Geschäftsführenden die volle Verantwortung tragen.

Dieses Modell ist skalierbar und eignet sich daher für Unternehmen jeder Größe. Es wird häufig von großen traditionellen Unternehmen oder Behörden genutzt.

• Management 2.0 – geprägt durch Balanced Scorecards und Total Quality Management: In diesem Modell steht der Fokus auf den Mitarbeitenden als Humanressourcen in den organisatorischen Prozessen. Ziel ist es, sie durch Motivationsanreize zu besseren Leistungen zu bewegen. Dabei spielen extrinsische und intrinsische Motivationsfaktoren eine Rolle. Bei extrinsischer Motivation geht es um Gehalt, Boni, Status, Geschäftswagen, Bürogröße oder Titel. Intrinsische Motivation wird durch individuelle Ziele angestrebt, die den Mitarbeitenden helfen, ihren Beitrag zu den strategischen Zielen der Organisation transparenter zu erkennen.

Alle schwergewichtigen Managementsysteme und große Teile der regulatorischen Anforderungen, setzen dieses Management Modell voraus. Methoden wie Projektmanagement, Balanced Scorecards und auch das V-Modell kommen hier bevorzugt zum Einsatz. Durch Management by Objectives bleibt es aber bei holistischen Zielen, die vom Top-Management auf alle individuell herunter gebrochen werden. Mehr dazu später in diesem Kapitel.

Die Unternehmensstruktur ist hierarchisch aufgebaut, mit einem Top-Management und mehreren Führungsebenen darunter. Die Führungskultur ist top-down orientiert, und Probleme werden nach oben eskaliert. Kontrolle erfolgt über Monitoring und Reporting, wobei der Fokus auf der Kontrolle der Ziele und ihrer Erreichung liegt. Die Mitarbeitenden übernehmen Mitverantwortung, indem sie für die Erreichung ihrer Ziele und einen Teil der Umsetzung der strategischen Ziele der Organisation verantwortlich sind.

Dieses Modell des Managements wird von großen Konzernen und Organisationen im regulierten Umfeld genutzt, da es skalierbar ist.

• Management 3.0 – geprägt durch agile Werte: In diesem Modell tritt die Unternehmensstruktur in den Hintergrund. Hierarchien sind flacher oder werden abgebaut. Das Management agiert als „Servant Leader“, indem es ein Arbeitsumfeld schafft, in dem Mitarbeitende ihr Bestes geben können. Dadurch werden strategische Unternehmensziele erreicht.

Das Top-Management ist dafür verantwortlich, die Organisation auszurichten und Strategien zu kommunizieren. Die Entscheidungen und die Verantwortung für die Umsetzung liegen bei den Mitarbeitenden, oft in Form von Teams statt individuell. Durch eine geringere Arbeitsteilung und Hierarchie müssen Mitarbeitende mehr Verantwortung übernehmen. Dabei geht es nicht nur um den Unternehmenserfolg, sondern auch um die persönliche Verantwortung. Es ist wichtig, Möglichkeiten zur Reflexion zu schaffen und über Themen wie Erfolge, Konflikte, Motivation, Ängste und Werte sprechen zu können.

Oft werden dafür leichtgewichtige Managementsysteme verwendet, die sich hauptsächlich mit der Umsetzung der Organisationsausrichtung und Strategie befassen, z. B. Objective and Key Results. Motivation entsteht in der Regel intrinsisch oder durch den „sozialen Druck“ im Team. Mitarbeitende werden mehr zu Unternehmenden und haben dadurch einen großen Einfluss auf den Unternehmenserfolg.

Dieses Managementmodell eignet sich besonders gut für komplexe Umgebungen, z. B. in IT-Organisationen mit Softwareprodukten oder bei jungen Unternehmen wie Start-ups.

Es gibt ein weiteres Modell namens Management 4.0. Die Experten*innen sind sich jedoch uneinig über die zukünftige Entwicklung. Einige sehen in diesem Modell den Weg zur Selbstorganisation innerhalb eines Unternehmens ohne Führung. Andere hingegen erkennen den Trend zur Digitalisierung und betrachten dieses Modell als Transformationsprozess zu digitalen und dezentralen Organisationsformen. Die Diskussion darüber, inwieweit sich welches Modell etablieren wird, wird also noch kontrovers geführt.

Wenn man sich die unterschiedlichen Managementmodelle und die damit verbundenen Generationen ansieht, fällt auf, dass in der Politik viele Menschen aus den Generationen der Traditionalisten und Babyboomer vertreten sind. In Ministerien und Behörden spiegeln sich oft immer noch ihre Wertevorstellungen in der Art des Managements wider.

Auch traditionelle Organisationen und familiengeführte Unternehmen werden häufig von einer älteren Geschäftsführung und einem Management geleitet, das oft von der Generation der Babyboomer und der Generation X dominiert wird. Das Management 2.0 mit seinen schweren Managementsystemen ist stark verwurzelt. Auch deren Werte prägen das Managementmodell.

Die jüngeren Generationen haben, durch ihre eigenen Wertevorstellungen, weniger Interesse daran, zu führen. Status und Führungsanspruch sind für die Generation Y und Generation Z weniger wichtig. Deshalb bleiben ältere Generationen weiterhin in Führungspositionen und setzen ihre Werte und Managementmodelle fort. Dabei müssten gerade jüngere Generationen, wie die Generation Y härter für ihre Werte arbeiten und verstärkt für diese eintreten. Dazu gehört auch Politik zu machen und auf Standards und Gesetze einzuwirken. Schaut man sich die Normengremien an, welche an den Standards arbeiten, sind in hohem Maße ältere Menschen vertreten. Junge Menschen zeigen weniger Interesse daran.

Allerdings wäre es umso wichtiger, das modernere agile Wertevorstellungen stärker wissenschaftlich bewertet werden und deren Nutzen und Leistungsfähigkeit, gute, qualitativ hochwertige und sichere Produkte zu erzeugen, sich mindestens vergleichbar, wenn nicht als fortschrittlicher erweisen. Doch besonders im agilen Bereich wird sehr viel emotional und nach Gefühl argumentiert. Wissenschaftlich fundierte Nachweise der Leistungsfähigkeit agiler Werte und Vorgehen im Vergleich zu klassischen Werten und Vorgehen sind rar. Und so basieren regulatorische Vorgaben und Standards weiterhin auf teilweise überholte wissenschaftliche Erkenntnisse und Werte der Generation Babyboomer und Generation X. Trotzdem werden sie als „Stand der Wissenschaft“ und „Stand der Technik“ bezeichnet.

Der Demografische Wandel hat sicherlich ebenso Einfluss darauf, dass klassische Denkweisen und Vorgehensweisen weiterhin vorherrschen. Aktuell stellen die Babyboomer und die Generation X etwa zwei Drittel der arbeitenden Bevölkerung in Deutschland dar, während die Generation Y und Generation Z nur ein Drittel ausmachen. Daher ist es nicht überraschend, dass klassische Werte und Vorgehensweisen dominieren. Dies führt dazu, dass Managementmodelle nicht mit den Entwicklungen der Generationen Schritt halten können und sich länger halten als die Generationen selbst. Aus diesem Grund sind die Wertevorstellungen der Babyboomer und der Generation X im Management von Organisationen weiterhin verbreitet und stark ausgeprägt.

Starke Hierarchie

Eine starke Hierarchie zeichnet sich dadurch aus, dass die Vorgesetzten Befehle erteilen und Entscheidungen treffen, während die Angestellten diese ausführen und Ergebnisse vorlegen. Jeder Mitarbeitende hat eine direkte Führungskraft, die wiederum eine weitere Führungskraft bis zur Geschäftsführung hat. Die Kommunikation verläuft dabei immer vertikal, entweder vom Rangniedrigeren zum Ranghöheren oder umgekehrt. Direkter Austausch zwischen den höchsten und niedrigsten Rängen wird vermieden oder sogar verboten. Gleiches gilt für die Zusammenarbeit zwischen Abteilungen. Wollen diese zusammenarbeiten, ist das nur über die Vorgesetzten möglich oder sogar erwünscht. Die Vorgesetzten möchten schließlich die Kontrolle über die Tätigkeiten der Angestellten haben.

In der heutigen Zeit wirkt diese Beschreibung allerdings übertrieben, schon fast überspitzt dargestellt. Oft wird der Austausch auf gleicher Ebene zwischen Abteilungen gefördert und Zusammenarbeit findet auch ohne Einbindung der Vorgesetzten statt, beispielsweise in Form von Projekten. Zudem gibt es Formate wie Townhall-Meetings oder Frühstück mit Geschäftsführenden, bei denen zufällig ausgewählte Mitarbeitende die Möglichkeit haben, direkt mit den höchsten Rängen zu kommunizieren. Es existieren dennoch immer noch viele Organisationen, die einer starken Hierarchie unterliegen und es nicht akzeptieren, dass Mitarbeitende ihre Vorgesetzten umgehen und sich direkt an andere Abteilungen wenden. Das folgende Diagramm zeigt eine klassische starke Hierarchie:

Die Aufbaustruktur kann dabei von Organisation zu Organisation in ihrer Breite und Tiefe variieren. Manchmal gibt es auch Manager*innen im Top-Management, Bereichsleitung oder Abteilungsleitung, die keine Angestellten haben. In solchen Fällen geht es nicht mehr um Organisationsaufbau, sondern ausschließlich um den Titel und den damit verbundenen Status. Nichtsdestotrotz wird genau diese Art von Aufbauorganisation im streng regulierten Umfeld bevorzugt und in den eingängigen Standards für klassische Managementsysteme exemplarisch verwendet, auch wenn sie dort nicht konkret gefordert wird.

Ein wichtiger Grund dafür ist die Haftungsfrage. Wenn es um Produkte mit sicherheitskritischen Risiken geht – sei es in Bezug auf Betriebssicherheit, klinische Sicherheit, Informationssicherheit, Umweltsicherheit, Giftstoffe, Unfälle oder Ähnliches – muss jemand die Verantwortung für Entscheidungen übernehmen. Im regulierten Umfeld liegt diese Verantwortung immer beim Top-Management. Es geht um die Verantwortung der Leitung, nicht des Teams. Das ergibt in den meisten Fällen Sinn, denn Teams können nicht haftbar gemacht werden, wenn es ernst wird.

Das liegt in der Natur der Sache. Es ist förderlich für den Teamgeist, zu sagen, dass wir gemeinsam entschieden haben und auch gemeinsam für das Ergebnis verantwortlich sind, solange dies keine negativen Konsequenzen nach sich zieht. Wenn jedoch durch Fehlentscheidungen Menschen zu Schaden kommen, wird womöglich jedes Teammitglied für sich selbst kämpfen. Das Team wird nicht zusammenstehen und sagen: „Wir haben gemeinsam entschieden, also haften wir auch gemeinsam dafür.“

Agile Teams sind in Haftungsfragen leider häufig sehr naiv. Es tritt oft eine kollektive Vermeidungshaltung auf. Dann kommt es zudem schnell zu Situationen, in denen es im Team zu lange dauert, Konsens über das weitere Vorgehen zu erzielen und weiteren Schaden zu vermeiden. Im Haftungsfall müssen Entscheidungen in der Regel zeitnah und präzise getroffen werden. Das lässt sich in einer stark hierarchischen Struktur besser bewältigen.

Agile Teams müssen, wenn Risiken oder riskante Situationen eingetreten sind oder im Haftungsfall selbst, ihre Entscheidungskompetenz schlagartig abgeben. Das funktioniert oft nicht sehr gut, muss aber direkt funktionieren. Oft übernimmt eine Officer Rolle wie der Qualitätsmanagementverantwortliche, in der Medizintechnik die Person verantwortlich für Einhaltung gesetzlicher Vorgaben, in der Informationssicherheit der Datenschutzbeauftragte oder einer aus dem Top-Management die Entscheidungshoheit und somit auch die Haftung.