diff --git a/Writerside/images/image_901.png b/Writerside/images/image_901.png
new file mode 100644
index 0000000..032ce7b
Binary files /dev/null and b/Writerside/images/image_901.png differ
diff --git a/Writerside/images/image_902.png b/Writerside/images/image_902.png
new file mode 100644
index 0000000..029f85c
Binary files /dev/null and b/Writerside/images/image_902.png differ
diff --git a/Writerside/images/image_903.png b/Writerside/images/image_903.png
new file mode 100644
index 0000000..eed6d0a
Binary files /dev/null and b/Writerside/images/image_903.png differ
diff --git a/Writerside/images/image_904.png b/Writerside/images/image_904.png
new file mode 100644
index 0000000..f7b79c7
Binary files /dev/null and b/Writerside/images/image_904.png differ
diff --git a/Writerside/images/image_905.png b/Writerside/images/image_905.png
new file mode 100644
index 0000000..b7c1f02
Binary files /dev/null and b/Writerside/images/image_905.png differ
diff --git a/Writerside/images/image_906.png b/Writerside/images/image_906.png
new file mode 100644
index 0000000..3d648e0
Binary files /dev/null and b/Writerside/images/image_906.png differ
diff --git a/Writerside/images/image_907.png b/Writerside/images/image_907.png
new file mode 100644
index 0000000..1f6c6d9
Binary files /dev/null and b/Writerside/images/image_907.png differ
diff --git a/Writerside/images/image_908.png b/Writerside/images/image_908.png
new file mode 100644
index 0000000..70648a5
Binary files /dev/null and b/Writerside/images/image_908.png differ
diff --git a/Writerside/images/image_909.png b/Writerside/images/image_909.png
new file mode 100644
index 0000000..3388f2a
Binary files /dev/null and b/Writerside/images/image_909.png differ
diff --git a/Writerside/images/image_910.png b/Writerside/images/image_910.png
new file mode 100644
index 0000000..979aaa0
Binary files /dev/null and b/Writerside/images/image_910.png differ
diff --git a/Writerside/images/image_911.png b/Writerside/images/image_911.png
new file mode 100644
index 0000000..f52c28c
Binary files /dev/null and b/Writerside/images/image_911.png differ
diff --git a/Writerside/images/image_912.png b/Writerside/images/image_912.png
new file mode 100644
index 0000000..f3f2376
Binary files /dev/null and b/Writerside/images/image_912.png differ
diff --git a/Writerside/images/image_913.png b/Writerside/images/image_913.png
new file mode 100644
index 0000000..1c2bf3e
Binary files /dev/null and b/Writerside/images/image_913.png differ
diff --git a/Writerside/in.tree b/Writerside/in.tree
index 036e1dc..1babbb7 100644
--- a/Writerside/in.tree
+++ b/Writerside/in.tree
@@ -126,6 +126,7 @@
+
diff --git a/Writerside/topics/04/Software Engineering/05_DevelopmentMethodologies.md b/Writerside/topics/04/Software Engineering/05_DevelopmentMethodologies.md
new file mode 100644
index 0000000..74d8124
--- /dev/null
+++ b/Writerside/topics/04/Software Engineering/05_DevelopmentMethodologies.md
@@ -0,0 +1,396 @@
+# Development Methodologies
+## Classic / Plan-based
+### Waterfall Model
+- [OOAD Waterfall](SoftwareProcesses.md#waterfall-model)
+- Einzelne Phasen werden sequentiell durchlaufen
+- Phasen überlappen sich kaum oder nicht
+- Sobald eine Phase abgeschlossen ist, wird sie nicht mehr verändert
+
+- Nur für kleine Projekte geeignet
+
+### V-Model
+- [OOAD V-Model](SoftwareProcesses.md#v-modell)
+- Erweiterung des Waterfall-Modells
+- Testphasen werden explizit in den Entwicklungsprozess integriert
+- Jede Phase hat eine zugehörige Testphase
+
+### Spiral Model
+- [OOAD Spiral Model](SoftwareProcesses.md#spiral-modell)
+- Iteratives Modell, das die Phasen des Waterfall-Modells in Zyklen durchläuft
+
+
+## Agile
+### The Agile Manifesto
+#### 4 Werte
+- **Individuen und Interaktionen** über _Prozesse und Werkzeuge_
+- **Funktionierende Software** über _verständliche Dokumentation_
+- **Arbeit mit Kunden** über _Vertragsverhandlungen_
+- **Anpassung an Veränderung** über _folgen des Plans_
+
+#### 12 Prinzipien
+
+1. Kunden glücklich machen
+ - Frühe und durchgehende Lieferung von wertvoller Software
+ - Auf Kundenfeedback reagieren
+2. Anforderungsänderungen willkommen heißen
+ - Auch spät in der Entwicklung
+3. Regelmäßig funktionierende Software liefern
+ - Alle paar Wochen - Monate
+ - Viele Vorteile durch kurze Iterationen
+4. Tägliche Zusammenarbeit
+ - Entwickler, Tester, Kunden
+5. Projekte um motivierte Individuen aufbauen
+ - Vertrauen in die Teammitglieder
+ - Gute Umgebung und Unterstützung
+6. Face-to-Face Kommunikation
+ - Effektivste Methode der Kommunikation
+7. Fortschritt in funktionierender Software messen
+ - Nicht in Dokumentation oder Berichten
+8. Konstante Geschwindigkeit halten (Marathon, nicht Sprint)
+ - Nicht zu viel vornehmen
+9. Technische Exzellenz und gutes Design
+ - Verbessert die Agilität
+ - Weniger technische Schulden
+10. Einfachheit
+ - Die Kunst, die Menge an nicht gemachter Arbeit zu maximieren
+ - Weniger Features, die nicht benötigt werden
+11. Vertraue deinem Team
+ - Selbstorganisierte Teams
+ - Cross-funktionale Teams
+12. Reflektieren und Anpassen
+ - Regelmäßige Retrospektiven
+ - Kontinuierliche Verbesserung
+
+## Agile: Scrum
+### Scrum Theory
+- Scrum ist ein agiles Framework für die Softwareentwicklung
+- Fokus auf Transparenz, Inspektion und Anpassung
+
+#### Scrum Pillars
+- **Transparenz**
+ - Alle Aspekte des Prozesses sind sichtbar für alle Beteiligten
+ - Ermöglicht informierte Entscheidungen
+- **Inspektion**
+ - Alle Aspekte des Prozesses und der Arbeitsergebnisse werden regelmäßig überprüft
+ - Frühzeitiges Erkennen von Problemen
+- **Adaption**
+ - Alle Aspekte des Prozesses und der Arbeitsergebnisse werden angepasst, wenn nötig
+ - Kontinuierliche Verbesserung des Prozesses
+
+### Scrum Team
+- fokussiert sich nur auf das Ziel des Projekts
+- ist cross-funktional
+ - alle notwendigen Fähigkeiten sind im Team vorhanden
+ - managed sich selbst
+
+#### Product Owner
+
+
+- Verantwortlich für den Erfolg des Produkts
+ - Stellt sicher, dass das Team den höchsten Wert liefert
+ - Kommuniziert mit Stakeholdern
+- Verantwortlich für das Product Backlog
+ - Was wird wann gemacht?
+- Skillset:
+ - Domain
+ - Produktvision haben und das Team leiten
+ - tiefgreifende Business- und Domainkenntnisse
+ - People
+ - "Stimme der Kunden"
+ - Gutes Verhältnis mit jedem
+ - Decision-Making
+ - (schwere) Entscheidungen über Features und Releases treffen
+ - Prioritäten setzen
+ - Verantwortung
+ - Verantwortung für den (Miss-)Erfolg des Produkts
+ - Klare Kommunikation der Ziele und Prioritäten
+
+#### Scrum Master
+
+- Verantwortlich für den Scrum-Prozess
+ - Moderation der Meetings
+ - Beseitigung von Hindernissen
+- Skillset:
+ - Scrum
+ - tiefgreifendes Wissen über Scrum und agile Methoden
+ - Kollaborativ
+ - arbeitet eng mit dem gesamten Team zusammen
+ - fördert Selbstorganisation
+ - Coaching
+ - Team bei der kontinuierlichen Verbesserung unterstützen
+ - Fragen stellen, um das Team zum Nachdenken zu bringen
+ - Beschützend
+ - vor äußeren Störungen schützen
+ - z.B. Meetings, die während des Sprints stattfinden
+ - Transparent
+ - sorgt dafür, dass alle Aspekte des Prozesses transparent sind
+ - fördert offene Kommunikation im Team
+
+#### Development Team
+
+- Verantwortlich für die Umsetzung der Arbeit
+ - Liefert das Inkrement am Ende jedes Sprints
+- Skillset:
+ - Cross-funktional
+ - Alle notwendigen Fähigkeiten sind im Team vorhanden
+ - Jeder kann an jedem Feature arbeiten
+ - Selbstorganisiert
+ - Team entscheidet, wie die Arbeit erledigt wird
+ - Keine externen Anweisungen
+ - T-Shaped Skills
+ - Teammitglieder haben tiefes Wissen in ihrem Bereich
+ - Breites Wissen über andere Bereiche
+ - Teamorientiert
+ - einer für alle, alle für einen
+ - gemeinsame Verantwortung für den Erfolg des Sprints
+ - Kommunikativ
+ - offener Austausch im Team
+ - regelmäßige Updates über den Fortschritt
+ - richtige Größe
+ - ≤ 10 Personen
+ - zu große Teams führen zu Kommunikationsproblemen und Ineffizienz
+ - zu kleine Teams haben nicht genug Fähigkeiten, um alle Aufgaben zu erledigen
+
+### Scrum Events
+
+#### Sprint
+- Zeitfenster von 1 bis 4 Wochen
+- Ziel: Ein Inkrement liefern
+#### Sprint Planning
+- initiiert den Sprint
+- Ziele und Aufgaben für den Sprint festlegen
+ - Warum ist der Sprint wichtig?
+ - Was soll erreicht werden?
+ - Wie wird entschieden, was im Sprint umgesetzt wird?
+ - Sprint Kapazität muss berücksichtigt werden
+- PO präsentiert das Product Backlog
+- Input:
+ - Product Backlog
+ - Team-Kapazität
+ - Abhängigkeiten
+ - Team-Fähigkeiten
+ - Initiales Sprint-Ziel
+- Arten:
+ - **2-Part Sprint Planning**
+ 1. Teil: _Was wird im Sprint gemacht?_
+ - PO präsentiert das Product Backlog
+ - Team wählt Items aus, die sie umsetzen können
+ 2. Teil: _Wie wird es umgesetzt?_
+ - Team plant die Umsetzung der ausgewählten Items
+ - Aufgaben werden aufgeteilt und geschätzt
+ - 
+ - **1-Part Sprint Planning**
+ - Team eruiert Kapazität
+ - Sprint-Ziel ggf. anpassen
+ - Team wählt Items aus dem Product Backlog aus
+ - 
+
+#### Sprint Execution
+- Daily Scrum
+ - 15min tägliches Meeting
+ - Jeder beantwortet 3 Fragen:
+ - _Was habe ich seit dem letzten Meeting gemacht?_
+ - _Was werde ich bis zum nächsten Meeting tun?_
+ - _Gibt es Hindernisse/Hilfsbedarf?_
+- Input:
+ - Task-Board
+ - 
+ - Sprint Burndown Chart
+ - Grafik, die zu erledigende Arbeit vs verbleibende Zeit zeigt
+ - 
+
+#### Sprint Review
+- Ergebnisse des Sprints präsentieren
+- Feedback von Stakeholdern einholen
+- Anpassungen am Product Backlog vornehmen
+
+#### Sprint Retrospective
+- Wege erarbeiten, um Qualität und Effizienz nächstes Mal zu verbessern
+- Fragen:
+ - _Was lief gut?_
+ - _Was kann verbessert werden?_
+ - _Welche Maßnahmen können ergriffen werden?_
+
+### Scrum Artefakte
+- **Product Backlog**
+ - Liste aller Anforderungen und Features
+ - Priorisierung
+ - Detaillierung
+ - _nicht alle Items müssen gleich detailliert sein_
+ - Aufwandsschätzung
+ - Definition of Ready (DoR)
+ - _Checkliste, ob ein Product Backlog Item abgearbeitet werden kann_
+ - Wird vom Product Owner gepflegt und priorisiert
+- **Sprint Backlog**
+ - Liste der Aufgaben, die im aktuellen Sprint umgesetzt werden sollen
+ - Wird vom Development Team erstellt
+- **Increment**
+ - Fertiges Produkt am Ende eines Sprints
+
+## Agile: Extreme Programming (XP)
+- Ziel: hohe Softwarequalität und hohe Lebensqualität für Entwickler
+- Fokus auf technische Exzellenz und kontinuierliche Verbesserung
+
+### Values
+- Kommunikation
+ - Jeder weiß, wer was macht
+- Einfachheit
+ - Einfache und direkte Lösungen
+- Feedback
+ - Regelmäßiges Feedback von Kunden und Teammitgliedern
+- Mut
+ - für die besten Entscheidungen
+ - auch wenn sie zunächst unbequem sind
+- Respekt
+ - Respektvoller Umgang im Team
+ - Wertschätzung der Arbeit aller Teammitglieder
+
+### Prinzipien
+- Humanität
+ - Ausgleich zwischen Arbeit und Privatleben
+- Economy
+ - Fokus auf das Wesentliche
+- Gemeinsamer Nutzen
+ - Praktische Lösungen, die für alle funktionieren
+- Selbstähnlichkeit
+ - monatlicher Zyklus ist gleich wie wöchentlicher/täglicher
+- Verbesserung
+ - sich ständig verbessern
+- Diversität
+ - verschiedene Perspektiven und Ansätze einbeziehen
+- Reflektion
+ - regelmäßig über die eigene Arbeit nachdenken
+- Flow
+ - konstante und flüssige Arbeitsweise
+- Möglichkeiten
+ - Probleme sind eine Chance zum Lernen und Wachsen
+- Redundanz
+ - verhindert Fehler und verbessert die Qualität
+- Failure
+ - ist absolut okay
+- Qualität
+ - hat hohe Priorität
+ - schlechte Qualität führt nicht zu schnellerer Lieferung
+- Verantwortlichkeit
+ - Teammitglieder sind für ihre Arbeit verantwortlich
+- Baby-Steps
+ - kleine Schritte, um schnell Feedback zu erhalten
+
+### Practices
+#### Primär
+##### Programmieren
+- **Pair Programming**
+ - Zwei Entwickler arbeiten zusammen an einem Computer
+ - Fördert Wissenstransfer und Codequalität
+- **Test-Driven Development (TDD)**
+ - Tests werden vor dem Code geschrieben
+ - Sicherstellen, dass der Code die Anforderungen erfüllt
+
+##### Integration
+- **Ten-Minute Build**
+ - Builden und Testen sollte nicht länger als 10 Minuten dauern
+ - Wenns länger dauert, führt man es seltener aus
+ - Fördert schnelle Feedback-Zyklen
+- **Continuous Integration**
+ - Direkt nach dem Commit wird der Code gebaut und getestet
+ - Schnelles Feedback über den aktuellen Stand des Codes
+
+##### Planning
+- **Weekly Cycle**
+ - Synonym zu Sprint
+ - Montags wird geplant
+ - Freitags wird geliefert
+- **Quarterly Cycle**
+ - Synonym zu Release
+ - Kunde bekommt alle 3 Monate eine neue Version
+ - Feedback / Wünsche werden in den nächsten Zyklus aufgenommen
+- **User Stories**
+ - Anforderungen werden in Form von User Stories formuliert
+ - [OOAD User-Stories](RequirementsAnalysis.md#user-stories)
+- **Slack**
+ - ein paar niedrig priorisierte Aufgaben einplanen
+ - um Puffer für Unvorhergesehenes zu haben
+
+##### Team
+- **Sit Together**
+ - Teammitglieder sitzen zusammen
+ - Fördert Kommunikation und Zusammenarbeit
+- **Informative Workspace**
+ - Kommunikation fördern
+ - Privatsphäre respektieren
+ - Wissen teilen
+ - z.B. Whiteboards, Post-Its, etc.
+
+##### Holistic
+- **Incremental Design**
+ - Design wird schrittweise verbessert
+ - nicht alles auf einmal
+- **Whole Team**
+ - Cross-funktionales Team
+- **Energized Work**
+ - Höchste Effizienz, wenn jeder fokussiert ist und nicht abgelenkt wird
+ - niemanden überarbeiten
+ - Gesundheit und Wohlbefinden fördern
+
+#### Corollary
+- Folgen aus primären Praktiken
+- **Real Customer Involvement**
+ - Kunden in die wöchentliche / vierteljährliche Planung einbeziehen
+- **Incremental Deployment**
+ - mehrere kleinere Releases statt eines großen
+- **Team continuity**
+ - Effektive Teams bleiben zusammen (auch in anderen Projekten)
+- **Shrinking Teams**
+ - Wenn ein Team effizienter arbeitet, kann es kleiner werden
+ - nicht mehr Arbeit geben
+ - "unnötiges" Mitglied kann in anderen Teams XP einführen
+- **Root-cause analysis**
+ - Wenn irgendwas schiefgeht, die Grund-Ursache finden und beheben
+- **Shared code**
+ - Jeder im Team kann auf den Code zugreifen und ihn ändern
+ - jeder ist für die Qualität des Codes verantwortlich
+- **Single codebase**
+ - Es gibt nur einen Code, nicht mehrere Versionen gleichzeitig
+- **Daily Deployment**
+ - täglich eine neue Version ausliefern
+- **Negotiated scope contract**
+ - Kunden und Team einigen sich auf den Umfang der Arbeit
+- **Pay-per-use**
+ - Nicht für Arbeit bezahlen lassen
+ - Kunde zahlt, wenn er das Produkt nutzt
+
+## XP vs Scrum
+- Scrum ist ein Framework, XP ist eine Sammlung von Praktiken
+- 
+
+## Agile: DevOps
+- [OOAD DevOps](SoftwareProcesses.md#devops)
+- Kombination von Entwicklung (Dev) und Betrieb (Ops)
+- Ziel: schnellere und zuverlässigere Software-Lieferung
+- Fokus auf Automatisierung, Continuous Integration und Continuous Deployment (CI/CD)
+
+
+
+## Agile Praktiken skalieren
+### Scrum of Scrums
+- 
+- Scrum-Team-Repräsentanten treffen sich regelmäßig
+ - bilden neues Scrum-Team
+
+### Release Train
+- 
+- Zug-Metapher
+ - Plan, für Features, wann sie die "Station" verlassen
+ - Alle Teams wollen ihre Produkte noch auf den Zug bringen
+ - Falls nicht, müssen sie auf den nächsten Zug warten
+
+### Frameworks
+- **LeSS (Large Scale Scrum)**
+ - Skalierung von Scrum auf mehrere Teams
+ - Fokus auf Einfachheit und Transparenz
+- **Disciplined Agile Delivery (DAD)**
+ - Agnostisches, hybrides Toolkit, das verschiedene agile Praktiken kombiniert
+- **Nexus**
+- **Scaled Agile Framework (SAFe)**
+ - Skalierung von Scrum auf mehrere Teams und Programme
+ - Fokus auf Planung, Koordination und Integration
\ No newline at end of file