Teil 1: Woran traditionelle Methoden scheitern

• Das V-Modell erklärt
• Übung: "Das Stille-Post-Spiel"
• Das Planungsparadoxon

Teil 2: Scrum in Aktion

• Scrum 3-5-3: Rollen, Events, Artefakte
• Übung: "Das Sprint-Spiel"
• Die Macht des Boards

Kernidee: Jede Entwicklungsphase hat eine entsprechende Testphase.

Versprechen:

• Klare Phasen mit definierten Ergebnissen
• Testing von Anfang an geplant
• Rückverfolgbarkeit von Anforderungen zu Tests
• "Wir finden Probleme, bevor sie teuer werden"

Realität:

• Erste funktionierende Software erscheint Monate nach den Anforderungen
• Anforderungen ändern sich, aber der Plan nicht
• Spät gefundene Probleme = teure Korrekturen

Barry Boehm (1976): Einen Bug in der Produktion zu beheben kostet 30-100x mehr als während der Anforderungsphase.

Das V-Modell nimmt an:

1. "Wir können alle Anforderungen im Voraus kennen"

   • Realität: Nutzer wissen nicht, was sie wollen, bis sie es sehen

2. "Wir können vollständig entwerfen vor dem Codieren"

   • Realität: Designprobleme zeigen sich erst beim Bauen

3. "Wir können es beim ersten Mal richtig bauen"

   • Realität: Lernen passiert durch Iteration

Das sind nicht nur schwer zu erreichen - sie sind unmöglich.

Wenn wir mehr planen, verschwenden wir Zeit mit Plänen, die sich ändern werden.
Wenn wir weniger planen, bauen wir das Falsche.

Traditionelle Antwort: Noch SORGFÄLTIGER planen!

• Mehr Dokumentation
• Mehr Review-Meetings
• Mehr Freigaben

Ergebnis: Langsamere Lieferung, gleiche Probleme.

Ziel: Erleben, warum die Phasentrennung des V-Modells versagt.

Zur Web-App beitreten - Code wird auf dem Bildschirm gezeigt

Wichtige Regel: Keine Fragen zwischen den Phasen!

Thema: Lernraum-Buchungs-App

Runde	Rolle	Ausgabe
1	KUNDE	"Zeige Tagesmenü, Preise, Veggie-Filter und wie lang die Schlange ist"
2	ANALYST	"ANF-1: Menü. ANF-2: Preise. ANF-3: Diät-Filter. ANF-4: Schlangenstatus"
3	ENTWICKLER	"Dropdown, Preisspalte, Checkbox, Ampel für Schlange"
4	TESTER	"wie lang" (Wartezeit) vs "Ampel" (Auslastung)

Was ging schief? Mehrdeutige "Schlange"-Anforderung → verschiedene Interpretationen!

Die App rotiert Dokumente automatisch zwischen den Runden!

Denk dran: Keine Fragen zwischen den Phasen!

Diskussionsfragen:

1. Wo gingen Informationen verloren?
2. Welche Annahmen hat jede Gruppe gemacht?
3. Wann hast du zuerst bemerkt, dass etwas nicht passt?
4. Wie hätte kontinuierliches Feedback geholfen?

Wichtige Erkenntnis: Spätes Feedback = teure Korrekturen

Anstatt Unsicherheit mit mehr Planung zu bekämpfen...

Scrum bietet Struktur ohne Flexibilität zu opfern.

Die 3-5-3 Struktur:

• 3 Rollen: Product Owner, Entwickler, Scrum Master
• 5 Events: Sprint, Planning, Daily, Review, Retrospektive
• 3 Artefakte: Product Backlog, Sprint Backlog, Inkrement

Kritisch: Klare Aufgabentrennung!

Die Stimme des Kunden

• Definiert und priorisiert das Product Backlog
• Vertritt die Stakeholder
• Nimmt erledigte Arbeit ab oder lehnt sie ab
• Kommuniziert die Produktvision

Kernprinzip: Eine Person, eine Stimme, eine Priorität.

Kein Komitee!

Die Menschen, die die Arbeit erledigen

• Selbstorganisierend: entscheiden WIE die Arbeit erledigt wird
• Cross-funktional: haben alle benötigten Fähigkeiten
• Liefern jedes Sprint ein potenziell auslieferbares Inkrement
• Typischerweise 3-9 Personen

Kernprinzip: Arbeit wird GEZOGEN, nicht ZUGEWIESEN.

Teammitglieder wählen Aufgaben vom Board!

Servant-Leader für das Team

• Moderiert Scrum Events
• Beseitigt Hindernisse, die das Team blockieren
• Coacht das Team in Scrum-Praktiken
• Schützt das Team vor Störungen von außen

Kernprinzip: KEIN Projektmanager!

Weist keine Arbeit zu und trifft keine Entscheidungen für das Team.

Szenario 1: Ein Kunde möchte mitten im Sprint ein neues Feature.

• Wer entscheidet, ob es den Sprint wert ist zu unterbrechen?

Szenario 2: Das Team braucht Server-Zugang, aber die IT reagiert nicht.

• Wer eskaliert dieses Hindernis?

Szenario 3: Das Team debattiert React vs. Vue fürs Frontend.

• Wer trifft die endgültige technische Entscheidung?

Szenario 1: Kunde will neues Feature mitten im Sprint

• Product Owner - Sie kontrollieren die Prioritäten

Szenario 2: Team von IT blockiert

• Scrum Master - Sie beseitigen Hindernisse

Szenario 3: React vs. Vue Debatte

• Development Team - Technische Entscheidungen sind ihre

Warum visuelles Management wichtig ist

┌─────────────┬─────────────┬─────────────┬─────────────┐
│  ZU TUN     │ IN ARBEIT   │  IM REVIEW  │   FERTIG    │
├─────────────┼─────────────┼─────────────┼─────────────┤
│ ┌─────┐     │ ┌─────┐     │ ┌─────┐     │ ┌─────┐     │
│ │US-4 │     │ │US-3 │     │ │US-2 │     │ │US-1 │     │
│ └─────┘     │ └─────┘     │ └─────┘     │ └─────┘     │
│ ┌─────┐     │             │             │             │
│ │US-5 │     │             │             │             │
│ └─────┘     │             │             │             │
└─────────────┴─────────────┴─────────────┴─────────────┘

Auf einen Blick: Was ist fertig, was ist blockiert, wer braucht Hilfe.

Warnsignal 1: 8 Items "In Arbeit", 0 "Fertig"

• Problem: Zu viel Work in Progress (WIP)
• Lösung: Dinge fertigstellen, bevor neue angefangen werden

Warnsignal 2: Board unverändert seit 3 Tagen

• Problem: Versteckte Blocker oder keine Updates
• Lösung: Daily Scrum, um Probleme aufzudecken

Warnsignal 3: PO verschiebt Karten direkt

• Problem: Rollenverletzung
• Lösung: Team besitzt seinen Workflow

Ziel: Einen kompletten Scrum-Sprint in 30 Minuten erleben.

Dein Team:

• 1 Product Owner
• 1 Scrum Master
• 3-4 Entwickler

Materialien:

• Product Backlog Karten
• Leeres Sprint Board
• Timer

Sprint Planning (5 Min):

• PO präsentiert Top-Stories aus dem Backlog
• Team schätzt und committet sich zum Sprint

Sprint Execution (15 Min):

• Entwickler arbeiten an Aufgaben
• Karten auf dem Board verschieben während du vorankommst
• SM achtet auf Blocker

Sprint Review (5 Min):

• Demo der erledigten Arbeit für den PO

Retrospektive (5 Min):

• Was lief gut? Was kann verbessert werden?

Runde 1 → Runde 2 → Ausführung → Review → Ergebnisse

Runde 1: Backlog-Priorisierung (13 Min)

• 1.1 Wichtigkeits-Voting: Bewerte jede Story ★★★★★
• 1.2 Prioritäts-Voting: Lege Ausführungsreihenfolge fest (0-3)
• 1.3 Finale Priorisierung: PO ordnet neu, Team stimmt Konfidenz ab

Runde 2: Story-Zuweisung (10 Min)

• 2.1 Entwickler-Präferenzen: Wähle Stories, die du willst
• 2.2 PO-Zuweisung: Stories werden Entwicklern zugewiesen
• 2.3 Zufriedenheits-Voting: Bewerte deine Zuweisung

Phase 1.1: Wichtigkeits-Voting (5 Min)
Alle bewerten die Wichtigkeit jeder Story: ★ bis ★★★★★

Phase 1.2: Prioritäts-Voting (5 Min)
Top-Stories ausgewählt → Stimme über Ausführungsreihenfolge ab (0-3)

Phase 1.3: Finale Priorisierung (3 Min)

• PO kann das Backlog neu ordnen (Drag & Drop)
• Team stimmt Konfidenz ab: Bereit | Unsicher | Bedenken

Phase 2.1: Entwickler-Präferenzen (3 Min)
Wähle die Stories aus, an denen du arbeiten möchtest

Phase 2.2: PO-Zuweisung (5 Min)
PO weist jede Story einem Entwickler zu
(Sieht, wer welche Story wollte)

Phase 2.3: Zufriedenheits-Voting (2 Min)
Bewerte deine Zuweisung: Zufrieden | OK | Unzufrieden
PO kann basierend auf Feedback neu zuweisen

Ausführungsphase
Arbeite an zugewiesenen Stories mit dem Kanban-Board:
Zu Tun → In Arbeit → Im Review → Fertig

Review-Phase
Stories im "Review" brauchen Team-Genehmigung:

• Alle stimmen ab: Genehmigen oder Ablehnen
• Alle genehmigen → Story geht nach Fertig
• Ablehnung → Zurück zu In Arbeit für Nachbesserung

• Stimme ehrlich ab - Deine Meinung formt den Sprint
• Kommuniziere - Nutze das Board, sprich mit Teamkollegen
• Ziehe Arbeit - Warte nicht auf Zuweisung
• Verschiebe Karten - Halte das Board in Echtzeit aktuell
• Zeit zählt - Jede Phase hat einen Timer!

Bereit? Los geht's mit dem Sprint-Spiel!

Diskussionsfragen:

1. Habt ihr alles geschafft, wozu ihr euch committed habt?
2. Was hat euch während des Sprints blockiert?
3. Wie hat das Board geholfen (oder nicht geholfen)?
4. Was würdet ihr im nächsten Sprint anders machen?

Denkt dran: Unvollständige Arbeit kommt zurück ins Backlog!

März 2024: US Army schreibt Agile für alle Software vor

"Wir lernen aus aktuellen Konflikten - einschließlich der Ukraine - dass der Erfolg der Army auf zukünftigen Schlachtfeldern von unserer Fähigkeit abhängt, Software schnell zu aktualisieren."
— Armeeministerin Christine Wormuth

Wenn es für missionskritische Militärsysteme funktioniert, kann es für dein Projekt funktionieren.

Die Lektion: "Agile skaliert nicht" ist ein Mythos.

1. V-Modell versagt, weil seine Annahmen unmöglich zu erfüllen sind
2. Agile akzeptiert Unsicherheit und baut kurze Feedback-Schleifen
3. Scrum bietet Struktur durch Rollen, Events und Artefakte
4. Das Board ist kritisch - Transparenz ermöglicht Zusammenarbeit
5. Arbeit wird GEZOGEN, nicht zugewiesen - Teams organisieren sich selbst

Für euren Road Profile Viewer:

1. Erstelle ein Product Backlog als GitHub Issues
2. Plane einen 1-Wochen-Sprint mit klarem Ziel
3. Richte ein GitHub Project Board ein
4. Haltet Daily Standups (auch async auf Slack)
5. Macht ein Sprint Review, um euren Fortschritt zu zeigen
6. Führt eine Retrospektive durch, um euch zu verbessern

Der beste Weg, Agile zu lernen, ist es zu praktizieren.

Offizielle Quellen:

• Der Scrum Guide - Kostenlos, 13 Seiten
• US Army Agile Policy (2024)

Tools:

• GitHub Projects - Kostenlos, integriert mit Issues
• Jira - Enterprise-tauglich
• Linear - Modern, entwicklerfreundlich