Vortrag auf der Medconf 2019 zum Thema Agile in der Normativen Welt

1. AGILE in der
Normativen Welt
Es wird ein wenig ketzerisch

2. Thomas Arends
58 Jahre
Verheiratet 4 Kinder
Inhaber Geschäftsführer Deutscher Mittelstand Ltd.
 Geschäftsführung, CPO, Projektleitung, Qualitätsleitung,Task Force Management
 Automotive, Aerospace, Industrial, Financial/Legal, Medical, Pharma
 V-Modell, Agile, SAFe®, LESS, CMMI, RUP, SCRUM, Kanban
Europa Distributor für Kovair ALM, Kovair Omnibus, Kovair Quick Synch

3. Inhalt
▪ Agil
▪ Agile Hype
▪ SAFe® - ein Dämpfer?
▪ Agile Studie Kugler Maag
▪ Methodenstudie Namecook
▪ Normative Anforderungen
▪ Lösungsansatz
▪ Was es so an Studien gibt
Erst werde ich Ihnen Agilität vermiesen
um dann zu zeigen wie es trotzdem geht

4. Agile in der Normativen Welt
Was ist die Beste Entwicklungsmethode?
▪ Agile mit Scrum & oder Kanban
▪ LESS
▪ SAFe®
▪ V-Modell mit Agilität
▪ CMMI SPIRAL
Woran erkennt man das Beste Modell?

5. Was ist Agil?
▪ Bessere Wege, Software zu entwickeln, indem wir es selbst tun und Anderen dabei helfen.
▪ Individuen und Interaktionen
mehr als Prozesse und Werkzeuge
▪ Funktionierende Software
mehr als umfassende Dokumentation
▪ Zusammenarbeit mit dem Kunden
mehr als Vertragsverhandlung
▪ Reagieren auf Veränderung
mehr als das Befolgen eines Plans
http://agilemanifesto.org/
Das Untere wird meist
nicht mehr gelesen:
Obwohl wir die Werte
auf der „unteren“ Seite
wichtig finden, schätzen
wir die Werte auf der
linken Seite höher ein

6. Agilität als Irrweg
▪ Studien Zeigen, dass die Methode (Agil, Waterfall…) völlig unwichtig ist um gute
Qualität zu erreichen, ERFAHRUNG macht es! (Seite 18)
▪ Ebenso zeigen Studien (und Aussagen von Mitarbeitern in der Automobilindustrie
und in der Medizin), dass Agil (trotz SAFe® und LESS …) NICHT skaliert/nicht
anwendbar ist, sobald es um besondere normative Anforderungen geht.
▪ Agil widerspricht dem V-Modell nicht!
▪ Wer etwas anders behauptet hat entweder das Eine, oder das Andere oder beide
NICHT VERSTANDEN.

7. Agile Hype
Und ein paar ketzerische Kommentare

8. HYPE?

9. Grundlegende Ideen
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.
Abschauen und Kopieren erlaubt  Bionik.

10. AGILE hier SAFe®
So ganz scheint es nicht zu passen

11. https://www.youtube.com/watch?v=a-BOSpxYJ9M&feature=youtu.be

12. SAFe® als HYPE?
P 147

13. SAFe®
P 339

14. SAFe®
P 343

15. Zusammnengassung
Build In Quality
Value Stream Level is Optional
Value Stream Level is most fundamental
oder
Stellen Sie sich vor
Ihre Mitarbeiter liefern Ihnen so ein „Unsafe“

16. Studie der Fa. Kugler Maag
zur Anwendung von AGILE
Einstimmige Ansicht der Befragten:
Nach agilen Methoden und Prinzipien "blind" wie "durch das Buch beschrieben zu
arbeiten hätte zum Scheitern geführt
Deshalb machen die Befragten “cherry picking" und implementieren solche agile
Praktiken, die für sie nützlich sind

17. Studie der Fa. Kugler Maag
Einstimmige Ansicht der Befragten:
▪ Agile skaliert nicht (Trotz LESS & SAFE*)
▪ Mangel an Vorausplanung und
▪ 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_CONTE
NT_PDF/2-22_agile-
automotive_survey-
2015.pdf

18. 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

19. 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.

20. Qualität

21. Ergebnisse einer Studie von Namecook 2015!
Effizienz und Qualität verschiedener Methodden
▪ Alle Methoden erreichen Ihr Ziel
▪ Agile Methoden sind schnell
▪ Qualitätslastige Methoden sind qualitativ hochwertig
▪ Kostenvarianz unterschiedlicher Methoden bei gleicher Last 1->4
Rather to do with joining a cult but a technical decision
▪ In general choosing a development method has

22. Ergebnis der Studie
Gleichmacherei in der Agilität
▪ 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.

23. Interessenskonflikt
▪ Sicherheit / Qualität und Agile gehören beide zu unseren wichtigen Themen.
▪ Agile is not strong on quality so it is only number 8 out of 10
▪ Hat Sicherheit für Ihr Unternehmen hat ein Anreizsystem?
▪ Bei SCRUM gibt es das:
Der Product Owner wird an der Wirtschaftlichkeit der Increments gemessen.

24. Agiler Ansatz
M-SPICE© (VDI 5702)
ISO 13485
ISO 14971
ISO 60601
CFR21
SPICE ©
Grundlegende Anforderungen  Erst mal die Normen

25. ISO 15504 / 330xx SPICE®
▪ Software Process Improvement and Capability Determination
(SPICE)
▪ ISO/IEC 15504 / 330xx
Information technology – Process assessment, also termed (SPICE), is
• a set of technical standards documents
• for the computer software development process and
• related business management functions.
(This is the mostly overlooked information out of the Norm)
Basic for Medical SPICE® (VDI5702)

26. Process House
ISO15504 330xx
65 Processes
> 250 Work Products

27. Das MSPICE© Prozesshaus
ISO 62304
ist ähnlich

28. Das MSPICE© Prozesshaus
(Standalone mapping)

29. Medical SPICE VDI 5702

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

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

32. Agile Methode Widersprüche zur Norm
& Abhängigkeiten -1
Agile Methode
▪ Menschen und Interaktionen stehen über Prozessen und Werkzeugen
 Conway Gesetz
*Was ist
“funktionierend?”
▪ Funktionierende* Software steht über einer umfassenden Dokumentation
 Conway Gesetz
Widerspricht scheinbar der gesetzlich und der seitens der Norm geforderten Dokumentationspflicht
▪ Reagieren auf Veränderung steht über dem Befolgen eines Plans
 Standard [TOC & EKS und „Conway“]
▪ Zufriedenstellung des Kunden durch frühe und kontinuierliche Auslieferung von wertvoller Software.
Widerspricht der Notwendigkeit einer Sicherheitsarchitektur sowie der Modularität vs. Schnittstellen
▪ Agile Prozesse nutzen Veränderungen (selbst spät in der Entwicklung) zum Wettbewerbsvorteil des Kunden.
 Conway Gesetz

33. ▪ Lieferung von funktionierender Software in regelmäßigen, bevorzugt kurzen Zeitspannen (wenige
Wochen oder Monate)
▪ Widerspricht der Notwendigkeit aus der Norm Konzepte und Architektur zu haben bevor man weiter arbeitet
Agile Methode Widersprüche zur Norm
& Abhängigkeiten -2
▪ Nahezu tägliche Zusammenarbeit von Fachexperten und Entwicklern während des Projektes
(Bsp.: Gemeinsamer Code-Besitz (Collective Code Ownership))
(Conway und Ausbildung)
▪ Bereitstellung des Umfeldes und der Unterstützung, welche von motivierten Individuen für die
Aufgabenerfüllung benötigt wird
[Diese Anforderung ist undefiniert  Ermittlung des notwendigen Umfeldes durch Umfrage]
▪ Informationsübertragung nach Möglichkeit im Gespräch von Angesicht zu Angesicht
▪ Widerspricht anscheinend der Notwendigkeit zur Dokumentation
▪ Als wichtigstes Fortschrittsmaß gilt die Funktionsfähigkeit der Software
▪ Widerspricht anscheinend der Notwendigkeit Interfaces

34. ▪ Einhalten eines gleichmäßigen Arbeitstempos von Auftraggebern, Entwicklern und Benutzern für
eine nachhaltige Entwicklung
 Planung Strukturierung
▪ Ständiges Augenmerk auf technische Exzellenz und gutes Design
▪  Widerspricht den Architekturen welche ggf. durch Anforderungen geändert werden)
▪ Einfachheit ist essenziell (KISS-Prinzip)
[Wie kann man das machen .. FTA FMEA FMEDA….]
▪ Selbstorganisation der Teams bei Planung und Umsetzung
(Ideen vorgeben)
▪ Selbstreflexion der Teams über das eigene Verhalten zur Anpassung im Hinblick auf
Effizienzsteigerung
 Ziele müssen vorgegeben werden
Agile Methode Widersprüche zur Norm
& Abhängigkeiten -3

35. Inhalt
▪ Konflikte Agile Methode zur
▪ „Probleme“
▪ Lösungsansatz
▪ Umsetzung

36. Probleme
▪ Arbeitsprodukte müssen vorliegen, BEVOR agiert wird
▪ Gewisse Arbeitsprodukte müssen erstellt werden BEVOR weitere Entwicklung
stattfinden kann
▪ Schnittstellen zwischen den Modulen
(Grob anfangen  verfeinern und downsizen)
(Widerspruch Einkauf – möglichst Billig)
▪ Skalierung der Teams
(Agile Methode Selbst finden)

37. Wer oder was ist Conway… 1964
Conway's law
▪organizations which design systems ...
▪are constrained to produce designs which
are copies of the communication
structures of these organizations

38. Inhalt
▪ Konflikte Agile Methode zur Norm 26262
▪ „Probleme“
▪ Lösungsansatz
▪ Umsetzung

39. Lösungsansatz
Das Ergebnis zählt
Inhalt

40. Lösungsansatz
„Methodenlose“ Entwicklung
Das machen, welches das Ergebnis 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.
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

41. Lösungsansatz
Methodenlose Entwicklung
Das machen, welches das Ergebnis bringt
1. Überdimensioniert beginnen
2. Downsizing, wenn überhaupt in einem späten (C/ D( Muster
(widerspricht dem Wunsch des Einkaufs)
3. Prio 1 Themen zuerst
4. In der Vorentwicklung (A & B Muster)
MEHR investieren um dort die Lösungen zu finden
5. Kommunikation Einfordern [Meeting Support Record] [Conway]
6. Ausbildung Einfordern [Conway]
(BSP: 4 Std / Tag– Domänen untereinander)  Probleme kommen auf lösen
7. Das Team selbst die beste Methode finden lassen (Agile)
8. Aufwändige Aktionen Agil in Themenkomplexen entwickeln –
Bsp. Requirements & Architektur
9. Aufwändig planen – PUFFER realistisch einschätzen

42. Inhalt
▪ Konflikte Agile Methode zur Norm 26262
▪ „Probleme“
▪ Lösungsansatz
▪ Umsetzung

43. Lösungsansatz
Das Ergebnis zählt

44. Umsetzung User Stories
1. Teamaufsatz in Bezug auf „Must haves, before can do“ verändern
Grundsätzlich sind im Thema User Stories die
System Requirements Ingenieure, Architekten und Tester der Systemebene VOLL beteiligt.
2. „Abschnittsweise“ Bearbeitung der US
US
RQ (1) RQ Tester (1)
Agile Team 1
SYS
Architektur
SYS Integration
SW RQ HW RQ Me RQ

45. Umsetzung Systemebene
RQ1 RQ Tester (1)
SYS
Architektur
SYS Integration
SW RQ1 HW RQ1
ME RQ1
SW Tester 1 HW Tester 1
ME Tester 1
Agile Team 2
SI RQ1
Grau optional

46. Umsetzung Architekturebene
SYS
Architektur
SYS Integration
SW RQ1 HW RQ1
ME RQ1
SW Tester 1 HW Tester 1
ME Tester 1
Agile Team 3
Safety RQ1

47. Umsetzung SWE / HWE
3. In den SWE/HWE/Ebenen wird entsprechen weiter gearbeitet
SWE/ HWE
RQ
Modul Tester
Architekt
Agile Team 4
FUSI RQ1
Modulerstelle
r
Integrator
Tester
Grau optional

48. Finally
Was es so an Studien gibt

49. Namecook
Studie

50. Software Schedules, Staff, Effort, Productivity
Methodologies Schedule Staff Effort FP Development
Months Months Month Cost
1 Extreme (XP) 11.78 7 84 11.89 $630,860
2 Agile/scrum 11.82 7 84 11.85 $633,043
3 TSP 12.02 7 86 11.64 $644,070
4 CMMI 5/ spiral 12.45 7 83 12.05 $622,257
5 OO 12.78 8 107 9.31 $805,156
6 RUP 13.11 8 101 9.58 $756,157
7 Pair/iterative 13.15 12 155 9.21 $1,160,492
8 CMMI 3/iterative 13.34 8 107 9.37 $800,113
9 Proofs/waterfall 13.71 12 161 6.21 $1,207,500
10 CMMI 1/waterfall 15.85 10 158 6.51 $1,188,870
Average 13 8.6 112.6 9.762 $844,852
As can be seen the software development methods that yield the shortest schedules for applications of 1000 function points are the XP and Agile methods, with TSP coming in third.
--

51. Software Defect Potentials, Removal, and Delivery
Methodologies Defect Defect Defects Hi Sev.
Potential Removal Delivered Defects
1 TSP 2,700 96.79% 87 16
2 CMMI 5/ spiral 3,000 95.95% 122 22
3 RUP 3,900 95.07% 192 36
4 Extreme (XP) 4,500 93.36% 299 55
5 OO 4,950 93.74% 310 57
6 Pair/iterative 4,700 92.93% 332 61
7 Proofs/waterfall 4,650 92.21% 362 67
8 Agile/scrum 4,800 92.30% 370 68
9 CMMI 3/ Iter. 4,500 91.18% 397 73
10 CMMI 1/ Water. 6,000 78.76% 1,274 236
Average 4,370 92.23% 374 69
When the focus of the evaluation turns to quality rather than speed, TSP, CMMI 5, and RUP are on top, followed by XP. Agile is not strong on quality so it is only number 8 out of
10. The Agile lack of quality measures and failure to use inspections will also have an impact in the next comparison.
--

52. Total Cost of Ownership (TCO) and Cost of Quality (COQ)
Methodologies TCO COQ Percent
1 TSP $1,026,660 $298,699 29.09%
2 CMMI 5/ spiral $1,034,300 $377,880 36.53%
3 Extreme (XP) $1,318,539 $627,106 47.56%
4 RUP $1,360,857 $506,199 37.20%
5 Agile/scrum $1,467,957 $774,142 52.74%
6 OO $1,617,839 $735,388 45.45%
7 CMMI 3/iterative $1,748,043 $925,929 52.97%
8 Pair/iterative $2,107,861 $756,467 35.89%
9 Proofs/waterfall $2,216,167 $863,929 38.98%
10 CMMI 1/waterfall $3,944,159 $2,804,224 71.10%
Average $1,784,238 $866,996 44.75%
Some of the newer methods such as Agile and XP have not been in use long enough to show really long-range findings over 10 years or more. In this article TCO is limited to only five years of usage, because there is almost no data older than that for Agile.
The figures for TCO include development, five years of enhancement, five years of maintenance or defect repairs, and five years of customer support. While the Software Risk Master tool predicts those values separately, in this article they are all combined
together into a single figure.
The figures for COQ consolidate all direct costs for finding and fixing bugs from the start of requirements through five years of customer usage.
11.6.3.5.1 Table 3: Total Cost of Ownership (TCO): Cost of Quality (COQ)
Because applications developed using the TSP, CMMI 5, and RUP methodologies are deployed with low numbers of defects it is fairly easy to enhance them, maintain them, and support them. Therefore the 5-year total cost of ownership clearly favors the
quality-related methods rather than the speed-related methods.
Agile is not bad, but with a COQ of more than 50% Agile needs to take quality more seriously up front.
The COQ percentages reveal a chronic problem for software applications. We have so many bugs that finding and fixing bugs is the major cost of both development and total cost of ownership.
--

53. Spiral

54. 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

55. 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

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

57. 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

58. Backup

59. Kundenanforderunge
n
Systemanforderunge
n
System Architektur System Integration
System Qualifikation
Domänen
Anforderungen
Domänen
Architektur
Domänen Detail
Design
Detail Tests
Integration
Domänen Test
1:n
1:n
1:n
1:n
1:n
1:n
1:n
1:n
n:1
n:1
Für jedes Element:
Bekannt(Wiederverwendung) /Unbekannt
Dauer für die Gestehung
Reviews
Investitionen & Ausgaben
Für jeden Test zusätzlich:
Dauer für die Implementierung
Dauer der Durchführung
Projekt Management
Qualitäts Management
Änderungsmanagement, Problemmanagement, Konfigurationsmanagement

60. 12 Prinzipen
1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung
wertvoller Software zufrieden zu stellen.
2. Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse
nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und
bevorzuge dabei die kürzere Zeitspanne.
4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die
Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines
Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

61. 12 Prinzipen
7. Funktionierende Software ist das wichtigste Fortschrittsmaß.
8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und
Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
10. Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist
essenziell.
11.Die besten Architekturen, Anforderungen und Entwürfe entstehen durch
selbstorganisierte Teams.
12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann
und passt sein Verhalten entsprechend an

62. Quelle
▪ Quora
https://www.quora.com/In-a-nutshell-why-do-a-lot-of-developers-dislike-Agile-
What-are-better-project-management-paradigm-alternatives

63. Manifesto for Agile Software Development