XP + Scrum

Scrum bietet organisatorische Struktur. XP bietet Engineering-Praktiken. Zusammen schließen sie unterschiedliche Lücken:

Scrum gibt dir:

• Definierte Rollen (Product Owner, Scrum Master, Entwickler)
• Rhythmus (Sprints, Sprint-Events)
• Artefakte (Product Backlog, Sprint Backlog, Inkrement)
• Verantwortungsstrukturen

XP gibt dir:

• Wie man gut Code schreibt (TDD, Refactoring, einfaches Design)
• Wie man beim Code zusammenarbeitet (Pair Programming, kollektive Verantwortung)
• Wie man zuverlässig liefert (CI, kleine Releases)
• Praktiken für Teamgesundheit (nachhaltiges Tempo, Coding-Standards)

Scrum schweigt darüber, wie Entwickler tatsächlich programmieren sollen. XP füllt diese Lücke.

Die meisten erfolgreichen „Scrum-Teams" praktizieren in Wirklichkeit Scrum + XP-Engineering-Praktiken, ob sie es so nennen oder nicht.

Sprints = Iterationen Scrums Sprint ist XPs Iteration. Zeitlich begrenzt, fokussiert, liefert funktionierende Software.

Product Backlog = Release-Plan XPs Release-Planung erzeugt die Arbeit; Scrums Product Backlog organisiert sie.

Sprint Planning = Iterationsplanung Dieselbe Aktivität: entscheiden, was in dieser Iteration gebaut wird, in Aufgaben aufteilen.

Daily Scrum = Daily Standup Dieselbe Absicht: Team synchronisieren, Blocker aufdecken.

Sprint-Retrospektive = Retrospektive XP schreibt Retrospektiven nicht so strikt vor, aber die Praktik ist dieselbe.

User Stories Funktionieren in beiden Ansätzen. Scrum schreibt das Format nicht vor; XPs Story-Format funktioniert gut.

Sprint Review = Demo XPs Iterations-Demos sind im Wesentlichen Sprint Reviews.

Die Terminologie unterscheidet sich; die Praktiken stimmen überein.

Scrum-Teams, die XP-Praktiken übernehmen, erleben typischerweise:

Bessere Codequalität: TDD fängt Bugs früh ab. Refactoring hält das Design sauber. Kollektive Verantwortung verteilt Wissen.

Vorhersehbarere Velocity: Wenn Qualität hoch ist, stabilisiert sich die Velocity. Keine überraschenden Verlangsamungen durch Bug-Fixing.

Nachhaltiges Tempo: XP benennt und schützt dies explizit. Scrum kann zum „Sprint" im falschen Sinne werden – immer unter Druck.

Verbesserte Zusammenarbeit: Pair Programming baut Beziehungen auf. Kollektive Verantwortung bricht Silos auf.

Kontinuierliche Verbesserung: XPs Prinzip der Verbesserung plus Scrums Retrospektiven schaffen eine kraftvolle Kombination.

Gängiges Muster: Teams starten mit Scrum, weil es organisatorisch ist. Sie fügen XP-Praktiken hinzu, während sie reifen. Die Kombination ist mächtiger als jeder Ansatz allein.

Obwohl XP und Scrum gut zusammenarbeiten, existieren einige Spannungen:

Scrum Master vs. XPs Selbstorganisation XP geht von tiefer Selbstorganisation des Teams aus. Scrum fügt eine Rolle (Scrum Master) zur Moderation hinzu. Diese können koexistieren, aber wenn der Scrum Master zur Befehlsstruktur wird, leidet XPs Selbstorganisation.

Sprint-Commitment vs. XPs Flexibilität Scrum betont Sprint-Commitment. XP betont Reaktion auf Veränderung. Wenn Commitment starr wird, geht XPs Anpassungsfähigkeit verloren.

Definition of Done vs. kontinuierliche Qualität Scrums „Definition of Done" kann zur Checkliste werden. XPs Qualitätspraktiken sind kontinuierlich. Stelle sicher, dass DoD XP-Qualität widerspiegelt, nicht nur „Tests bestehen".

Velocity als Metrik Scrum trackt oft Velocity. XP warnt vor Velocity als Ziel (sie wird manipuliert). Nutze Velocity für Planung, nicht für Leistungsmessung.

Diese Spannungen sind handhabbar. Der Schlüssel ist, XPs Prinzipien lebendig zu halten, während man Scrums Struktur nutzt.

Um Scrum und XP effektiv zu kombinieren:

Nutze Scrums Struktur:

• Sprints für Rhythmus
• Product Owner für Prioritäten
• Scrum Master für Moderation
• Sprint-Events für Kadenz

Füge XPs Praktiken hinzu:

• TDD für allen Produktionscode
• Pair Programming (mindestens für komplexe Arbeit)
• Kollektive Verantwortung (keine Code-Silos)
• Continuous Integration (mehrmals täglich)
• Refactoring (als Teil jeder Story)
• Nachhaltiges Tempo (keine Überstunden)

Bewahre XPs Prinzipien:

• Qualität ist nicht verhandelbar
• Starte, wo du bist, und verbessere dich
• Begrüße Veränderung
• Feedback auf allen Ebenen

Viele Teams entdecken diese Kombination natürlich. Sie starten mit Scrum, erkennen, dass sie Engineering-Praktiken brauchen, und fügen XP hinzu. Das Ergebnis wird oft „gut gemachtes Agile" genannt.