XP vs Scrum: Komplementäre Ansätze

XP und Scrum entstanden etwa zur gleichen Zeit und haben dieselben Wurzeln, aber sie konzentrieren sich auf unterschiedliche Probleme.

Scrum konzentriert sich auf Projektmanagement: Wie organisiert man Arbeit? Welche Rollen braucht man? Welche Meetings? Welche Artefakte? Scrum gibt dir ein Framework für die Verwaltung des Arbeitsflusses durch ein Team.

XP konzentriert sich auf Engineering-Praktiken: Wie schreibt man eigentlich den Code? Wie stellt man Qualität sicher? Wie hält man die Codebasis gesund? XP gibt dir Praktiken, um die Arbeit gut zu erledigen.

Deshalb ergänzen sie sich so natürlich. Scrum sagt dir, was du in einem Sprint bauen sollst. XP sagt dir, wie du es baust.

Trotz unterschiedlicher Schwerpunkte teilen XP und Scrum wichtige Konzepte:

• Iterationen: Scrum hat Sprints (2-4 Wochen). XP hatte ursprünglich 1-2 Wochen Iterationen.
• Kundenbeteiligung: Scrum hat den Product Owner. XP hat den Kunden vor Ort.
• Retrospektiven: Beide betonen Reflexion und Verbesserung.
• Selbstorganisierende Teams: Beide vertrauen darauf, dass Teams herausfinden, wie sie arbeiten.
• Funktionierende Software: Beide priorisieren lauffähigen Code über Dokumentation.

Ein Team, das „Scrum macht", sieht von außen sehr ähnlich aus wie ein Team, das „XP macht". Der Unterschied liegt unter der Haube.

Scrum schweigt zu Engineering-Praktiken. Der Scrum Guide sagt nichts über TDD, Pair Programming, Refactoring oder Continuous Integration. Er geht davon aus, dass Teams die technischen Praktiken selbst herausfinden.

XP ist präskriptiv bei Engineering-Praktiken. XP sagt, du musst Tests zuerst schreiben. Du solltest Pair Programming machen. Du wirst kontinuierlich refactoren. Du wirst viele Male am Tag integrieren.

Scrum definiert Rollen. Product Owner, Scrum Master, Development Team. Diese Rollen haben spezifische Verantwortlichkeiten.

XP ist flexibel bei Rollen. Es gibt einen Kunden und Entwickler. Das war's im Wesentlichen. XP geht davon aus, dass sich das Team bei Bedarf selbst um Rollen organisiert.

Scrum hat spezifische Events. Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.

XP hat flexiblere Kadenzen. Planning Game, Standup, Iterations-Demo – ähnlich, aber weniger starr definiert.

Viele erfolgreiche Teams nutzen Scrums Framework mit XPs technischen Praktiken. Diese Kombination ist kraftvoll:

• Von Scrum: Sprints, Product Owner, Scrum Master, Sprint-Events, Product Backlog
• Von XP: TDD, Pair Programming, Refactoring, Continuous Integration, Collective Ownership

Das ist nicht „unrein" oder falsch. Die ursprünglichen Scrum-Erfinder erwarteten, dass Teams Engineering-Praktiken mitbringen. XP liefert sie.

Ein gängiges Muster:

1. Nutze Scrum für Planung und Organisation der Arbeit
2. Nutze XP-Praktiken für die Durchführung der Arbeit
3. Nutze Retrospektiven, um beides kontinuierlich zu verbessern

Teams nennen das oft „Scrum mit XP-Engineering-Praktiken" oder einfach „Agile gut machen".

Du kannst XP ohne Scrum machen. Manche Teams bevorzugen XPs leichtgewichtigeren Ansatz:

• Continuous Flow statt fester Sprints
• Kunde vor Ort statt eines Product-Owner-Stellvertreters
• Selbstorganisierte Rollen statt definierter Scrum-Rollen

Das funktioniert gut für Teams, die Scrums Struktur zu schwerfällig finden, oder wo Arbeit kontinuierlich ankommt (wie Operations oder Support).

Der Schlüssel ist, dass XPs technische Praktiken nicht verhandelbar sind. Ob du Scrum, Kanban oder etwas anderes nutzt, um Arbeit zu organisieren – TDD, Refactoring und Continuous Integration bleiben essenziell.