Scrum

Ein festes Regelwerk für Agile. Man arbeitet in Sprints (meist 2 Wochen). Am Anfang plant man: "Was schaffen wir in 2 Wochen?" Während des Sprints darf niemand stören ("Könnt ihr mal schnell Farbe X ändern? -> Nein, erst im nächsten Sprint"). Am Ende präsentiert man das Ergebnis (Demo). Dann überlegt man: "Was lief gut, was schlecht?" (Retro). Und von vorn.

Merksatz: Ein agiles Framework, das komplexe Projekte durch feste Zeitintervalle (Sprints), klar definierte Rollen und regelmäßige Meetings strukturiert.

Die 3 Rollen:

Product Owner (PO): Die Stimme des Kunden. Entscheidet WAS gebaut wird (Priorisiert das Backlog).
Scrum Master: Der Coach. Achtet darauf, dass die Regeln eingehalten werden. Beseitigt Hindernisse ("Ich brauche einen Server"). Entscheidet nicht über das Produkt.
Developers: Entscheiden WIE es gebaut wird.

1. Events (Zeremonien)

Daily: 15 Min im Stehen. "Was habe ich gestern gemacht? Was mache ich heute? Wo habe ich Probleme?" Keine Diskussionen!
Review: Demo am Sprint-Ende. Stakeholder (Chefs) schauen zu.
Retrospective: Das wichtigste Meeting. Nur das Team. "Warum ist der Server ausgefallen? Wie verhindern wir das?" Kontinuierliche Verbesserung (Kaizen).

2. Definition of Done (DoD)

Wann ist ein Ticket fertig? "Auf meinem Laptop läuft es" zählt nicht. DoD: "Code ist committet, Tests sind grün, Code Review ist durch, Doku ist geschrieben, auf Staging deployt." Erst dann gibt es Punkte.

3. Story Points & Velocity

Man schätzt nicht in Stunden ("Dauert 4h"), sondern in Komplexität (Story Points: 1, 2, 3, 5, 8, 13...). Warum? Menschen sind schlecht im Zeitschätzen. Aber gut im Vergleich ("Das ist doppelt so schwer wie das andere"). Velocity = Summe der Punkte pro Sprint. Hilft bei der Vorhersage ("Wir schaffen ca. 30 Punkte pro Sprint").

1. Scrum-Skalierung (SAFe vs. LeSS)

Wenn eine Firma nicht aus 5, sondern aus 500 Entwicklern besteht, stößt das Standard-Scrum an seine Grenzen. Hier kommen Skalierungs-Frameworks ins Spiel.

SAFe (Scaled Agile Framework): Sehr hierarchisch, führt "Release Trains" und Quartalsplanungen (PI Planning) ein. Kritiker sagen: "Das ist Wasserfall in Verkleidung."
LeSS (Large-Scale Scrum): Versucht, so nah wie möglich am Original-Scrum zu bleiben. Es gibt nur einen Product Owner für das gesamte Produkt (nicht pro Team!), um Silos zu vermeiden. Wichtig ist: Skalierung löst keine organisatorischen Probleme, sie macht sie nur sichtbarer.

2. Cargo-Cult und "Agiler Wasserfall"

Ein häufiges Phänomen: Ein Team macht Dailies, Sprints und Retros, aber am Ende des Jahres gibt es trotzdem einen festen Release-Termin mit festem Scope. Das nennt man Cargo-Cult Scrum. Man kopiert die äußeren Zeichen (Meetings), ohne das Prinzip (Empirie und Anpassung) zu verstehen. Der größte Feind von Scrum im Deep Dive ist die fehlende psychologische Sicherheit: Wenn in der Retrospektive niemand die Wahrheit sagt ("Der Code ist Schrott"), wird das Team nie schneller (Velocity Trap). Scrum ist kein Tool zur Leistungsüberwachung, sondern zur Risikominimierung durch frühes Scheitern.

3. Technische Exzellenz und Scrum

Scrum sagt fast nichts über Technik aus. Das führt oft dazu, dass Teams nur "Features ballern", um die Velocity hochzuhalten. Aber ohne Clean Code, Testautomatisierung und Refactoring sinkt die Velocity nach 5 Sprints auf Null, weil die Altlasten (Technical Debt (Technische Schulden)) alles blockieren. Experten-Teams integrieren technische Praktiken aus XP (Extreme Programming): Pair Programming und Test-Driven Development sind oft der unsichtbare Motor hinter erfolgreichen Scrum-Teams. Ein "Done" ohne automatisierte Tests ist eine Zeitbombe.