Der Vortrag kritisiert die Entwicklung von agile als Reaktion auf das V-Modell, wobei er eine fanatische Methodenwahl und die Unvereinbarkeit agiler Praktiken mit normativen Anforderungen in der Automobilindustrie anführt. Trotz der Förderung von Selbstorganisation und Flexibilität stellt der Vortrag fest, dass ohne eine klare Zieldefinition, effektive Kommunikation und angemessene Prozessarchitekturen, agile Methoden oft scheitern können. Es wird ein 'methodenfreier' Ansatz vorgeschlagen, der auf den langfristigen Erfolg und die Kompetenz der Mitarbeiter fokussiert ist, anstatt sich dogmatisch an agile Praktiken zu klammern.

1. Agile wurde nur
entwickelt, weil man das
V-Modell nicht verstanden
hat
Ein Ketzerischer Vortrag um sich Feinde zu schaffen

2. Vorab
Ich glaube nicht – ich schaue!
Warum ich das sage?
Methodenwahl hat fanatische Ausmaße angenommen.
Es MUSS GENAU SO!!!  ich hab Recht !!!
Basierend auf einer Studie „Capers Jones & Associates LLC.“ wurden 10 Methoden in Bezug auf verschiedene Standard Metriken
inklusive
• Function points,
• Defect removal efficiency (DRE),
• Cost of Quality (COQ), und
• Total Cost of Ownership (TCO)
Untersucht um diese Methoden zu vergleichen.
Das Ergebnis ist:
In general selecting a software development methodology has more in common with
joining a cult than it does with making a technical decision.
UND
No single method appears to be a universal panacea that can be successful on every size
and kind of software application.

3. Agile in normativem Umfeld am Beispiel der
Automobilindustrie
• Grundlegende Forderungen ASPICE©
• Grundlegende Forderungen ISO 26262
• Das Agile Manifest
• Schritt für Schritt
Die Widersprüche zur Norm.
• Die Lösung

4. Agiler Ansatz
A-SPICE© & ISO 26262

5. ASPICE ©
Grundlegende Anforderungen

6. Das ASPICE© Prozesshaus

7. Der Entwicklungsprozess

8. Traceability & Konsistenz

9. Zusammenfassung
▪ Klares V-Model
▪ Entwicklung beginnen von den Top Anforderungen
▪ Traceability und Konsistenz ist ein MUSS!

10. ISO 26262
Normative Anforderung

11. Prozesse in der ISO 26262

12. Das V-Model

13. Zusammenfassung
▪ Klares V-Model
▪ Entwicklung beginnen von den Top Anforderungen
▪ Traceability und Konsistenz ist ein MUSS!

14. Das Agile Manifest
Und ein paar ketzerische Kommentare

15. Das Originale Manifest
http://agilemanifesto.org/
▪ Individuals and interactions over processes and tools
▪ Working software over comprehensive documentation
▪ Customer collaboration over contract negotiation
▪ Responding to change over following a plan

16. Ein bisschen Verwirrung
https://www.agilealliance.org/agile101/12-
principles-behind-the-agile-manifesto/
http://agilemanifesto.org/principles.html
http://www.automotive-spin.it/uploads/8/8W_mueller.pdf

17. Grundlegende Ideen
Agile Software Entwicklung beschreibt ein Prinzipien
Bei dem Anforderungen und Lösungen
Durch gemeinsame Anstrengung
Sich selbst organisierender Teams gelöst werden
Inhaltliches Zitat Prof. Dr. G. Dueck aus seinem Buch:
„Schwarmdumm – so blöd sind wir nur gemeinsam“
Hier führt Professor Dueck aus das die Schwarmintelligenz im Endeffekt nur dann
existiert wenn‘s wirklich frei zusammen arbeitende Leute sind.
Schwarmaktionen, sich selbst organisierende Systeme, gibt es nur in Freiheit.
Nicht in einer Firma unter „Zwang“.

18. Grundlegende Ideen
Dazu kommen 2 Ausführungen.
Ganz kurzer Exkurs in die Biologie.
Selbstorganisation führt maximal zu einem losen Einzellerverbund.
Alle höher organisierten Organismen egal ob Pflanzen, Tiere oder was
auch immer folgen einem hierarchischen System“.
Und die Kollegen von der Engineering Abteilung der Biologie hatten ein
paar mehr Jahre Zeit um etwas zu entwickeln.
Da könnte man sich ja mal etwas von ab gucken.
Schwarmtheorie
Tatsache ist dass Menschen typischerweise, auf dem niedrigsten Niveau
dass es überhaupt zu erreichen gibt, eine Übereinstimmung machen.

19. Studienergebnisse AGILE
So ganz scheint es nicht zu passen

20. Studie der Fa. Kugler Maag
Einstimmige Ansicht der Befragten:
Nach agilen Methoden und Prinzipien "blind" wie "durch das Buch beschrieben “ hätte
zum Scheitern geführt
Deshalb machen die Befragten “Kirschen Pflücken" und implementieren solche agile
Praktiken, die für sie nützlich sind

21. Studie der Fa. Kugler Maag
Einstimmige Ansicht der Befragten:
Wichtige Bedenken in Bezug auf Agile:
▪ Agile skaliert nicht (Trotz LESS & SAFE*)
▪ Mangel an Vorausplanung und (Siehe u.a. ASPICE MAN.3 und respektive Level 2)
▪ Managementwiderstand
▪ Das größte Problem:,
agile Elemente in eine nicht agile Umgebung zu bringen,
die Fähigkeit, die Organisationskultur,
die Projektkomplexität
und die Kundenzusammenarbeit zu verändern
*Diese Aussage habe ich zugefügt nach mehreren Gesprächen mit Entwicklern bei deutschen Automotive OEM‘s und Tier
1 Zulieferen
Quelle: http://www.kuglermaag.de/fileadmin/05_CONTENT_PDF/2-22_agile-automotive_survey-2015.pdf

22. Kurze Zusammenfassung
▪ Project Manager scheinen sehr intelligent zu reagieren.
▪ Sie machen das was notwendig ist so dass das gewünschte Ergebnis erreicht wird.
▪ Sie nahmen/nehmen das (egal woher es kommt) was Ihnen hilft besser zu werden.
▪ Es scheint unlösbare Wiedersprüche zu geben

23. Weitere Studienresultate
Weitere Studienresultate, welche in dem angegebenen Dokument (Kugler Maag) zu
finden sind.
• Low Performer und High Performer haben Probleme in solchen Projekten.
• Low Performer mit der Transparenz.
• High Performer verlieren ihren Heldenstatus.

24. Gleichmacherei
▪ Ich persönlich habe kein Problem damit das Low Performer auffallen und sich
unwohl fühlen.
▪ Ich habe aber ein großes Problem damit, wenn die Highperformer nicht
weiterhin exzellent genutzt werden.
Sie werden gehen.
▪ Jeder der nicht das Gefühl hat das seine Beiträge wertgeschätzt werden
▪ Wird knötterig
▪ Arbeitet gegen diese Menschen welche ihn nicht wertschätzen oder wendet sich von diesen ab.
▪ Auf lange Sicht wird er die Firma nicht mehr unterstützen, und selbst wenn es bloß darauf
hinausläuft dass er nicht mehr vollen Einsatz zeigt.

25. Das Agile Manifest
Vergleiche aus dem normalen Leben

26. Agile Befürwortet
▪ Adaptive Planung
▪ Evolutionäre Entwicklung
▪ Möglichst frühe Lieferung
▪ Kontinuierliche Verbesserung
▪ Befürwortet
schnelle und
flexible Antwort auf Änderung
Das ist die tägliche Arbeit im Automobilsektor
Das möchte jeder, aber keiner möchte sich verändern
Auch das möchte jeder haben
Das ist etwas, was jeder möchte.
Dem steht jedoch die Grundeinstellung entgegen:
„Das hamma immer schon so gemacht“
Auch hier der gleiche Satz wie oben:
Jeder möchte Veränderung aber keiner
möchte sich ändern.

27. Agile Manifest
Konflikte zu normativen Anforderungen #1
Menschen und Interaktionen sind wichtiger als Prozesse und
Werkzeug
Wer nicht verstanden hat wie wichtig Menschen sind, gehört
auf keine einzige Führungsposition.
Wenn nicht verstanden hat wie wichtig Prozesse sind um
erfolgreich zum Ergebnis zu kommen, gehört auch auf keine
Führungsposition.
Ein Widerspruch existiert erst mal nicht!
Die Wichtigkeit der Menschen ist jedoch seit langem durch
das Gesetz von Conway bekannt. Das ist kein agiles
Alleinstellungsmerkmal.
Funktionierende Software hat Vorrang vor umfassender
Dokumentation.
Software hat, genauso wie jedes andere Bauelement das
anhand von Anforderungen entwickelt wird, zu funktionieren
wie in den Anforderungen festgelegt.
Die Menge der notwendigen Dokumentation ist in normativen
Vorgaben festgelegt.  Definition of Done
Ein Versagen ausreichend zu dokumentieren führt
grundsätzlich zu weiteren Fehlern und ist von daher, da
Fehlerkorrektur mit die teuerste Projekteigenschaft ist, wenn
irgend möglich, zu vermeiden.
Ein Widerspruch existiert erst mal nicht!

28. Agile Manifest
Konflikte zu normativen Anforderungen #2
Zusammenarbeit mit dem Kunden hat Vorrang vor
Vertragsverhandlungen
Das ist etwas, was das Management anpassen muss.
Ein Widerspruch existiert erst mal nicht!
Wer jedoch genau hinschaut und sich die größten Fehler
anschaut die im Projektgeschäft immer wieder gemacht
werden, wird feststellen das ein sinnvoller Vertrag der
Schlüssel Faktor für eine erfolgreiche Zusammenarbeit ist.
Reagieren auf eine Änderung hat Vorrang vor den geplanten
Schritten
Das führt typischerweise innerhalb einer normalen Firma zu
dem was die Mitarbeiter so hassen:
Zum Chaos Management.
Die sofortige Reaktion auf größere Änderungen ist
typischerweise in komplexen Systemen nicht durchsetzbar.
Wer sich durch Änderung Management aus dem Plan heraus
werfen lässt, wird typischerweise nie am Ziel ankommen.
Ein Widerspruch existiert erst mal nicht!

29. Agile Manifest
Konflikte zu normativen Anforderungen #3
Reagieren auf eine Änderung hat Vorrang vor den geplanten
Schritten
Es gibt eine normative Anforderung zum
Änderungsmanagement.
Die Änderungsanfrage wird sich angeschaut, bewertet, die
Einflussanalyse durchgeführt und dann wird die Änderung
genehmigt und verplant oder verworfen.
Ein Widerspruch existiert erst mal nicht!
Grundlegend ist die Reaktion auf eine Änderung vorab zu
überlegen.
Die Änderung Management und Projektmanagementprozesse
müssen aufeinander abgestimmt sein und miteinander
interagieren.

30. Agile Manifest
Konflikte zu normativen Anforderungen #4
Zufriedenstellung des Kunden durch frühe und
kontinuierliche Auslieferung von wertvoller Software
Widerspricht der Notwendigkeit eine
Sicherheitsarchitektur zu haben, sowie der
Modularität vs. Schnittstellen
Die Zufriedenstellung des Kunden bezieht sich nicht
darauf, dass der Kunde nun ein Wunschkonzert
bekommt.
Die Erstellung einer Sicherheitsarchitektur oder eines
ähnlich komplexen Systems, bedarf einer gewissen
Zeit.
Natürlich kann man auch das modular entwickeln,
aber gerade größere Systeme benötigen ein wenig
Zeit und Gehirnschmalz von erfahrenen Architekten.
Wenn man sich diese nicht nimmt wird es im
Nachhinein immer sehr sehr schwer genau das was
man nicht möchte.
Ein Widerspruch existiert erst mal nicht!

31. Agile Manifest
Konflikte zu normativen Anforderungen #5
Agile Prozesse nutzen Veränderungen (selbst spät in
der Entwicklung) zum Wettbewerbsvorteil.
Das ist eine reine Behauptung und jeder der in einem
Unternehmen arbeitet wird versuchen Veränderungen
zum Wettbewerbsvorteil einzusetzen.
Das kann durch jeden intelligenten und gesteuerten
Prozess abgebildet werden.
Das ist kein Alleinstellungsmerkmal von agil.
Ein Widerspruch existiert erst mal nicht!
Nahezu tägliche Zusammenarbeit von Fachexperten
und Entwicklern während des Projektes (Bsp.:
Gemeinsamer Code-Besitz (Collective Code
Ownership))
O. k., wer es nicht schafft die Kollegen eines
Projektes zur Zusammenarbeit zu bekommen und
damit signifikant gegen jegliche Art von normalen
Erkenntnissen und ebenso dem Gesetz von Conway
widerspricht, der sollte auch keine Projekte leiten
Ein Widerspruch existiert erst mal nicht!

32. Agile Manifest
Konflikte zu normativen Anforderungen #6
Bereitstellung des Umfeldes und der Unterstützung,
welche von motivierten Individuen für die
Aufgabenerfüllung benötigt wird
Das ist eher ein Dauerthema, die Bereitstellung einer
Umgebung in der man arbeiten kann ist leider immer
noch viel zu selten anzutreffen. Wird aber nicht
durch die Agilität verbessert.
Ein Widerspruch existiert erst mal nicht!
Informationsübertragung nach Möglichkeit im
Gespräch von Angesicht zu Angesicht
Es ist normativ nicht verboten Informationen von
Angesicht zu Angesicht zu übertragen, diese müssen
jedoch dokumentiert werden.
Hier ist Dokumentation über Podcast, Mitschnitte etc.
erlaubt!
Es ist erlaubt diese Dokumentation als Aufzeichnung
mitzuführen.
Ein Widerspruch existiert erst mal nicht!

33. Agile Manifest
Konflikte zu normativen Anforderungen #7
Einhalten eines gleichmäßigen Arbeitstempos von
Auftraggebern, Entwicklern und Benutzern für eine
nachhaltige Entwicklung
Das ist keine Besonderheit der Agilität.
Kanban/Kaizen und andere Methoden zeigen, dass
eine gleichmäßige Auslastung von maximal 80 % ideal
ist. Ein Widerspruch existiert erst mal nicht!
Ständiges Augenmerk auf technische Exzellenz und
gutes Design
Das ist an sich die Idee eines jeden guten Technikers.
Diese wird jedoch oftmals durch Management
Entscheidungen über den Haufen geworfen.
Ein Widerspruch existiert erst mal nicht!
Einfachheit ist essenziell (KISS-Prinzip) Das lässt sich in komplexen Systemen kaum noch
abbilden.(Alles was man verstanden hat ist einfach)
Ein Widerspruch existiert erst mal nicht!
Selbstorganisation der Teams bei Planung und
Umsetzung
Die Kollegen bei der Planung und Umsetzung
einzubinden ist Standard eines jeden guten
Projektmanagers.
Ein Widerspruch existiert erst mal nicht!
Selbstreflexion der Teams über das eigene Verhalten
zur Anpassung im Hinblick auf Effizienzsteigerung
Das setzt voraus, dass es innerhalb der Firma eine
etablierte Fehler Mentalität gibt und eine etablierte
Fehlerkultur.
Ein Widerspruch existiert erst mal nicht!

34. Zusammenfassung
▪ So schlimm war es doch gar nicht, es gibt jedoch einige Punkte, die de facto im
Normativen Umfeld nicht durchsetzbar sind.
▪ Die Widersprüche zu den normativen Anforderungen sind hauptsächlich genau
die seitens der Projektleiter als Probleme in der Studie identifizierten Punkte.
▪ Wenn man genau hinschaut gibt es keinen direkten Widerspruch weder zu
irgendeiner Norm, noch zu irgend einer Methode.
▪ Es gibt keinen Widerspruch zum V Modell!
▪ DAS WAS IN DER AGILITÄT GEFORDERT WIRD,IST ETWAS WAS AN SICH
GESUNDER MENSCHENVERSTAND IST!
▪ Ich komme zurück zu meiner ursprünglichen Aussage:
Agilität ist nur entwickelt worden weil man das V Modell nicht verstanden hat.
Ich habe nicht gesagt wer es nicht verstanden hat....
Aber ich denke es ist jetzt etwas klarer

35. Wie löst man das Alles?
Das Langzeitergebnis zählt

36. Die Lösungsidee „methodenfreie Entwicklung“
Machen Sie was langfristig das gewünschte Resultat bringt
1. Ergebnis definieren/ Zieldefinition
(muss vorhanden sein) [Wer definiert] (Zeit, Aufwand, Qualität ….)
2. Entpolitisieren Meinungen entfernen
 Prozesse / Ergebnisse [Kennzahlen]
Weder ist das V-Modell, noch die Agile Methode richtig, das Ergebnis bestimmt den Weg
 auf die Kompetenz der Mitarbeiter setzen
3. Conway Gesetz
Organisationen, die Systeme entwerfen, […] sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser
Organisationen abbilden. (Bitte keine Religionskriege)
Ausbildung untereinander
 Stärkere Kommunikation der Teams untereinander  Ausbildung
4. Theorie der Abhängigkeiten
(TOC [Theory of constraints])
Engpass finden und auslasten (Bedingung  Kennzahlen)
5. EKS
(Engpass orientierte Strategie)
Konzentration auf die Kompetenzen  Lösungen hinzukaufen

37. Grundlegende Probleme jeglicher Entwicklung
▪ Gewisse Arbeitsprodukte müssen erstellt werden BEVOR weitere Entwicklung
stattfinden kann.
▪ (Architektur vor coding)
▪ Schnittstellen zwischen den Modulen müssen sauber definiert sein
(Grob anfangen  verfeinern und downsizen, gerade bei neuen Systemen)
(Widerspruch Einkauf – möglichst Billig)
▪ Skalierung der Teams
Die ideale Größe des Teams herauszufinden hat sehr viel mit den Kompetenzen zu tun, welche in Ihrem
Unternehmen vorhanden sind.
Ein Team größer als zehn Mitarbeiter ist jedoch unabhängig von den Kompetenzen nicht managebar.
▪ Missverständnis was AGILE wirklich ist
Aktivität bedeutet nicht auf jeden Kundenwunsch einzugehen.
Agile ist eine Aktion mit gesundem Menschenverstand zu entwickeln.
Wenn Projektleiter oder das Management Jasager zum Kunden sind, wird es in einer jeglichen Entwicklung schwer.

38. Lösungsansatz Methodenlose Entwicklung #1
Das machen, welches das Ergebnis bringt
1. Überdimensioniert beginnen
2. Downsizing, wenn überhaupt im C/ D Muster
(widerspricht dem Wunsch des Einkaufs)
3. Prio 1 Themen zuerst (Priorisierungsproblematik)
▪ Wird typischerweise in der Agilität über den Systemarchitekt festgelgt
4. In der Vorentwicklung (A & B Muster)
MEHR investieren um dort die Lösungen zu finden
5. Kommunikation Einfordern
[Meeting Support Record ASPICE] [Conway]

39. Lösungsansatz Methodenlose Entwicklung #2
Das machen, welches das Ergebnis bringt
6. Ausbildung Einfordern [Conway]
BSP: 1-2 Std / Tag
Domänen untereinander
 Probleme kommen auf
lösen
7. Statische Anforderungen der Norm (Mental) ausgliedern und als Teil der
„Definition of Done“ beifügen
8. Das Team selbst die beste Methode finden lassen.
9. Aufwändige Aktionen im Team in Themenkomplexen entwickeln –
Bsp. Requirements & Architektur
10. Aufwändig planen – PUFFER realistisch einschätzen

40. PIM.3* und SUP.9** ASPICE©
In Kombination mit ISO 26262
• Exzellenter PIM.3*  Generisch
• Lessons Learned umsetzen nicht nur aufschreiben 
• SUP.9 inklusive
• 08-29 Improvement plan
• 07-03 Personnel performance measure
• 14-02 Corrective action register
*Prozess Verbesserung
** Korrektur | Fehlerbehandlung

41. Finally
Was es so an Studien gibt

42. Fehler
Barry Boehm und Victor Basili
▪ Softwarefehler, die erst spät im Lebenszyklus einer Software – also z. B. nach der Auslieferung –
gefunden werden, verursachen bis zu 100-mal mehr Kosten als solche, die frühzeitig entdeckt
werden. Dies spricht für den konsequenten Einsatz von Techniken zur Fehlervermeidung,
insbesondere auch in den frühen Phasen eines Projektes.
▪ 40 bis 50 Prozent des Gesamtaufwandes eines Softwareprojekts entstehen durch eigentlich
vermeidbare Nacharbeit. Eine deutlicheReduktion dieses Aufwandes kann vor allem durch
Verbesserungen in den Bereichen Entwicklungsprozess, Softwarearchitektur und Risikomanagement
erreicht werden.
▪ 80 % der vermeidbaren Nacharbeit werden von nur 20 % der Fehler verursacht. Fehlermanagement
kann helfen, die kritischen Bereiche einer Anwendung zu identifizieren. Diese können dann einem
Refactoring unterzogen werden.
▪ 80 % der Fehler treten in nur 20 % der Module oder Komponenten auf.
Über die Hälfte aller Module und Komponenten ist fehlerfrei. Dieser Tatsache sollte man z. B. durch
automatisierte Codeanalysen Rechnung tragen. Diese Analysen geben schon früh im Lebenszyklus
eines Projektes wertvolle Hinweise auf potenziell fehleranfällige Module.
▪ 90 % aller Ausfälle eines Systems werden von nur 10 % der Fehler verursacht. Es ist offensichtlich,
dass der komplette Stillstand eines produktiven Systems zu den schwerwiegendsten Fehlerszenarien
gehört. Jeder einzelne frühzeitig identifizierte oder vermiedene Fehler aus diesen kritischen 10 %
rechtfertigt schon für sich die Maßnahmen zur Fehlervermeidung in einem Projekt
Zurück

43. Optimierungspotential
▪ 40 bis 50 Prozent des Gesamtaufwandes eines Softwareprojekts entstehen durch
eigentlich vermeidbare Nacharbeit. Eine deutliche Reduktion dieses Aufwandes
kann vor allem durch Verbesserungen in den Bereichen Entwicklungsprozess,
Softwarearchitektur und Risikomanagement erreicht werden
▪  Selbst mit zusätzlichem Aufwand zur Vermeidung lassen sich MINDESTENS >
20% der Entwicklungskosten sparen
▪ 100 Mann Projekt auf 3 Jahre = >10 Millionen Einsparung
▪ 25 Mann Projekt auf 3 Jahre = > 2,5 Mio Einsparung
▪ Pro Person auf 3 Jahre 125.000
Zurück

44. Conway's law
▪organizations which design systems ...
▪are constrained to produce designs which
are copies of the communication
structures of these organizations
Back

45. Die grundlegende Idee einer jeden Veränderung
▪ Benutzen Sie jegliche Norm.
▪ Benutzen Sie jegliche Methode.
▪ Benutzen Sie jegliches Werkzeug.
▪ Benutzen Sie was auch immer.
▪ Um besser zu werden

46. Danke
蔡荣耀Thomas Arends
Repräsentanz Deutscher Mittelstand
Schillerstr. 12/1,
73249 Wernau
Tel D - Mob | +49 176 42682164
Tel D - FeN | +49 7153 750 9918
Tel C - Mob | +86 159 50 153 049
Skype# +49 176 42682164
ta@deutscher-mittestand.com