Extreme Programming vs. Scrum: Unterschiede, Gemeinsamkeiten

Wie unterscheiden sich die beiden beliebtesten agilen Frameworks voneinander? Und wann solltest du welche Methode einsetzen? Sowohl Extreme Programming als auch Scrum kommen in der Softwareentwicklung zu Einsatz. Sie sind in den 90er Jahren entstanden und haben die Prinzipien des agilen Manifests maßgeblich beeinflusst.

Beide regeln die Zusammenarbeit sowie die Prozesse im Team. Doch es gibt Unterschiede. 

Außerdem erfährst du, warum es für uns XP und Scrum heißt, anstatt XP vs. Scrum.
Dieser Artikel ist Teil unserer Blog-Reihe Do Better Scrum. Wir decken die Schwachstellen von Scrum auf und zeigen, wie es besser geht.

Du lernst hier mehr über:

1. Was ist Scrum?

2. Was ist Extreme Programming?

3. Was sind die Gemeinsamkeiten?

4. Was sind die Unterschiede: Scrum vs. Extreme Programming?

5. Fazit: Scrumming als Alternative

Scrum kennst du wahrscheinlich schon, wenn du bereits in der IT unterwegs bist. Deshalb möchten wir in aller Kürze die wichtigsten Grundlagen für dich festhalten. 

Ins Leben gerufen haben das agile Framework die Mitunterzeichner des agilen Manifesto Anfang der 90er Jahre: Jeff Sutherland und Ken Schwaber. Der erste Scrum Guide wurde 2010 veröffentlicht, neun Jahre nach der Begründung des agilen Manifests.

Scrum regelt auf der organisatorischen Ebene den genauen Prozess, wie eine Software zu entwickeln ist, sowie die Zusammenarbeit im Team. Das Vorgehen ist inkrementell und es geht darum eine Software mit größtem Mehrwert (=Value) zu liefern. Dabei geht das Team in 1- bis 2-wöchigen Zyklen vor, den sogenannten Sprints.

Am Ende eines Sprints steht ein fertiges Inkrement. Das Team testet die neue Version, holt sich Feedback vom Kunden ein und entwickelt daraufhin das Produkt weiter. Das Product Backlog ist in Scrum das zentrale Artefakt. Es ist eine Liste, in der alle Anforderungen an die Software definiert sind. Der Product Owner oder die Stakeholder priorisieren die benötigten Features der Software, die in Form von User Stories beschrieben sind.  

Die Methode ist ursprünglich aus der Softwareentwicklung entstanden, erfreut sich mittlerweile aber auch in anderen Bereichen großer Beliebtheit. Mit Scrum kannst du auch ein Konzept oder Produkt entwickeln. Es gibt einen Rahmen vor und stellt vor allem für unerfahrenere Teams einen leichten Einstieg in die agile Welt dar.

Die Scrum Werte sind Mut, Offenheit, Respekt, Fokus und Commitment, auf die wir in einem gesonderten Beitrag bereits näher eingegangen sind. Im Team gibt es drei unterschiedliche Rollen:

1. Scrum Master: bewacht den Prozess und steht dem Team unterstützend als Coach, Mediator und Moderator zur Seite.
2. Product Owner: verantwortlich für die Nutzenmaximierung des Produkts, nimmt die Nutzerperspektive ein, definiert Anforderungen und pflegt das Product Backlog.
3. Developer: Entwickler:innen, die sich um die technische Umsetzung kümmern.

1. Backlog Refinement: Das Backlog Refinement findet entweder im Rahmen eines Meetings mit dem Team gemeinsam statt oder der Product Owner übernimmt das Refinement während des Sprints selbst. Die Einträge im Product Backlog werden spezifiziert und die Prioritäten der Features festgelegt.
2. Sprint Planning: Das Team plant gemeinsam den anstehenden Sprint. Es wird das Sprint-Ziel festgelegt, die zu entwickelnden Features ausgesucht sowie die Umsetzung im Team besprochen.
3. Daily Standup: In einem täglichen 15-minütigen Meeting tauscht sich das Team über Aufgaben und Probleme des Tages aus und versucht gemeinsam Lösungen zu finden.
4. Sprint Review: Am Ende des Sprints stellt das Team dem Kunden das fertige Inkrement vor. Die Teammitglieder nehmen das Feedback des Kunden auf und optimieren darauf basierend die Software.
5. Retrospektive: Die Teammitglieder reflektieren den letzten Sprint, klären Konflikte, finden gemeinsam Lösungen und definieren Maßnahmen für die zukünftige Zusammenarbeit.

Extreme Programming ist ein agiles Modell für die Entwicklung einer Software, das von den Mitbegründern des Agilen Manifesto Mitte der 90er Jahre konzipiert wurde: Kent Beck, Ron Jeffries und Ward Cunningham. 

Kent Beck veröffentlichte erstmalig das Konzept 1999, zwei Jahre vor dem Agilen Manifest. Damit du nicht erst ein ganzes Buch lesen musst, um das Konzept zu verstehen, geben wir dir einen kurzen Überblick.

Im Gegensatz zu Scrum fokussiert sich Extreme Programming weniger auf einen genauen Prozessablauf, sondern mehr auf Methoden zum Programmieren einer Software. Es beschreibt 12 Praktiken, wie sich das agile Mindset in der Zusammenarbeit  umsetzen lässt.

Die Software wird ebenfalls schrittweise entwickelt. Die Zyklen sind 1- bis 2 Wochen lang. Feedback erhält das Team konstant. Der Kunde ist stark in den Entwicklungsprozess eingebunden. 

Ein genauer Ablauf ist in XP nicht definiert. Wie in Scrum sind aber bspw. Planning Meetings oder Acceptance Tests Bestandteil der Praktiken. Sie können individuell angewandt und daraus ein eigener Prozess kreiert werden.

Kent Beck beschreibt in seinem Buch verschiedene Rollen unter anderem die des Testers oder Architekten. Das Team kann sich unterschiedlich zusammensetzen. Die Rollen, welche in XP am häufigsten zusammenkommen, sind:

1. Programmer (auch genannt Developer): entwickeln die Software. Sie schätzen Aufwände, planen die Umsetzung und achten auf das richtige Tempo (=Sustainable Pace).
2. Kunde: Der Kunde ist Teil des Teams. Er definiert die Anforderungen an das Produkt und priorisiert die Features. Er definiert Acceptance Tests und gibt Feedback. Manager (auch genannt Tracker): Der Manager trackt die wichtigsten Kennzahlen und hat den Fortschritt der Entwicklung jederzeit im Blick. Er plant und moderiert die Planning Meetings durch.
3. Coach: Der Coach steht dem Team unterstützend zur Seite und achtet darauf, dass die XP-Praktiken korrekt umgesetzt werden. 

Die wesentlichen Bausteine des agilen Frameworks sind die Werte, Prinzipien und Praktiken. Die agilen Werte im XP werden wie folgt beschrieben:

1. Kommunikation: Sowohl die Developer als auch der Kunden sind konstant im Austausch. Informationen werden transparent offengelegt. Hindernisse frühzeitig angesprochen. Ein persönliches Gespräch vor Ort wird dem schriftlichen Austausch bevorzugt. Alle sind jederzeit im Boot und fühlen sich für das Projekt verantwortlich.
2. Einfachheit: Das Team sucht immer nach den einfachsten Lösungen. Es werden nur die Features entwickelt, die auch wirklich benötigt werden. Und der Code soll möglichst sauber und strukturiert bleiben. Damit alles übersichtlich ist. So ist der Code leichter verständlich und die Zusammenarbeit effizienter.
3. Feedback: Die konstanten Feedbackzyklen sind im Extreme Programming ein zentrales Element. Auf Basis des Feedbacks kann der Code und das Produkt stetig verbessert werden. Durch die Unit Tests wird der Code kontinuierlich und automatisch getestet. Methoden wie das Pair Programming ermöglichen, dass die Developer sich untereinander austauschen und Team im Review Meeting bekommt fortwährend Feedback von Kunden und Stakeholdern.
4. Respekt: Respekt ist das Fundament einer positiven Arbeitsatmosphäre. Nur wenn sich die Teammitgliedersicher fühlen, können sie auch ihre beste Leistung erbringen. Respekt bedeutet, dass sich das Team untereinander und auch dem Kunden gegenüber auf Augenhöhe begegnet. Dazu gehört es, andere Meinungen ernst zu nehmen, aufeinander einzugehen und die Arbeit der anderen wertzuschätzen.
5. Mut: Mut ist im XP die Bereitschaft ehrliches Feedback zu geben, eigene Fehler einzugestehen, offen die Meinung zu teilen und neues auszuprobieren. Dafür braucht es eine offene Kultur und gegenseitiges Vertrauen. Fehler dürfen nicht bestraft werden. Es gilt nicht mit dem Finger auf andere zu zeigen. Sondern die Chance sollte ergriffen werden, daraus zu lernen und es beim nächsten Mal besser zu machen.

Good to know: Je nach Quelle können sich die Anzahl der Werte, Prinzipien und Praktiken unterscheiden. Die Abweichungen sind aber kaum von Bedeutung. Denn alle Modelle basieren auf den gleichen Grundlagen.

Im nächsten Beitrag der Reihe Do Better Scrum beschreiben wir alle 12 Praktiken im Detail. Folge uns also gerne auf LinkedIn, um über unsere neusten Beiträge informiert zu werden! 

Scrum und Extreme Programming verfolgen das gleiche übergeordnete Ziel: Eine hochqualitative Software effizient zu entwickeln, die genau die Bedürfnisse des Kunden erfüllt, und die Möglichkeit bietet, schnell auf Veränderungen reagieren zu können. 

Da die Anforderungen im Softwareumfeld meist sehr komplex sind, wird die Software schrittweise entwickelt. Die Intervalle sind meist 1 bis 2 Wochen lang. 

Der Scrum Guide spricht noch von einem Monat, was aus unserer Sicht aber nicht zu empfehlen ist. Umso kürzer die Intervalle, umso schneller können die Entwickler:innen Änderungen berücksichtigen. Die Intervalle werden in Scrum übrigens Sprints genannt, in Extreme Programming Iterationen. 

In beiden Frameworks übernehmen Teammitglieder verschiedene Rollen im Team. Es gibt eine Rolle, die sich um die Umsetzung kümmert. In Scrum ist es das Developer Team, in Extreme Programming in der Regel die Programmer. 

Die Aufgaben des Coaches überschneiden sich mit denen eines Scrum Masters. Und der Customer im Extreme Programming übernimmt Aufgaben eines Product Owners. Es gibt aber auch einige Unterschiede, dazu später mehr.

Beide Teams managen sich selbst. Alle Teammitglieder befinden sich auf derselben Hierarchieebene und sind sich nicht weisungsbefugt. Die Developer suchen sich ihre Aufgaben selbst aus, nach dem Pull-Prinzip. 

Das Team spricht sich untereinander ab, priorisiert mit dem Kunden zusammen die Features und unterstützt sich gegenseitig.

In Scrum und Extreme Programming ähneln sich viele Werte. Mut und Respekt gehören jeweils zu den wichtigen Umgangsformen. Die weiteren Werte überschneiden sich wie bspw. Kommunikation (XP-Wert) und Offenheit (Scrum-Wert). 

Beide plädieren dafür, dass die Teammitglieder transparent sind und Informationen teilen. Es lässt sich ein ähnliches Mindset erkennen. 

Feedback ist sowohl in Scrum als auch in XP ein zentraler Bestandteil. Es ist ein Element des agilen Arbeitens und steht bei beiden Methoden im Fokus. Denn für beide Teams ist es essenziell, um die Software entsprechend weiterzuentwickeln. 

Die Feedbackzyklen sind in Extreme Programming kürzer als in Scrum, dazu gleich mehr. Bei beiden Methoden bekommen die Entwickler:innen aber regelmäßig Rückmeldung zu den entwickelten Features. 

Scrum fokussiert sich auf den Prozess. Es gibt einen genauen Rahmen für den Ablauf und die Zusammenarbeit im Team. Wenn es allerdings um die Anwendung technischer Methoden geht, weist Scrum einige Lücken auf. Genau diese lassen sich mit Extreme Programming schließen. Denn XP ist ein Framework, das aus Entwicklersicht entstanden ist.

Das technische Handwerk ist das Herzstück. Es werden 12 konkrete Praktiken vorgegeben, welche sich auf die technische Umsetzung beziehen. Das Ziel dabei ist einen hochqualitativen Code zu schreiben und damit die Qualität der Software sicherzustellen. Eine Reihenfolge von Prozessschritten wie in Scrum wird hingegen nicht vorgegeben.

Scrum erlaubt keine bis wenige Änderungen während des Sprints, damit das Team fokussiert arbeiten kann. In XP ist das anders. Auf Veränderungen kann auch während des Sprints reagiert werden. Solange ein Feature noch nicht angefangen wurde zu entwickeln, kann es durch ein anderes ersetzt werden. Das Team commitet sich nicht wie in Scrum auf ein bestimmtes Ziel oder einen Plan.

Das XP-Team bespricht im Planning Meeting zwar auch die Umsetzung, gibt aber kein direktes Commitment ab und ist damit flexibler. Da das Team mit dem Kunden konstant im Austausch ist, benötigt es nicht den vorab “perfekten” Plan wie in Scrum. Durch schnellere Umpriorisierungen kann aber auch der Fokus verloren gehen.

Scrum lässt sich auch in anderen Bereichen wie Marketing oder HR einsetzen. Das Framework ist problemlos auf Produkte oder Konzepte anwendbar. Außerdem ist Scrum ein ganzheitliches Konzept. Das bedeutet, entweder verwendest du Scrum mit dem gesamten Prozess, den Rollen und alles, was im Scrum Guide beschrieben ist. Oder du arbeitest nicht mit Scrum.

Es gibt offiziell keinen Mittelweg. Auch wenn wir das anders sehen. Da die fixen Regeln in Scrum einen Widerspruch zum Agilen Manifest darstellen können (“Individuals and interactions over processes and tools“). Wenn wir in unterschiedlichen Teams und Kontexten arbeiten.

Extreme Programming ist dagegen ein Framework, das sehr speziell für die Softwareentwicklung konzipiert ist. Im Extreme Programming können und sollten die Praktiken individuell angewandt werden. Einzelne Entwickler:innen im Team können die Methoden nutzen und damit bereits Erfolge erzielen. Im XP sollen sich die Teams ihre Tools selbst aussuchen und damit ihre eigene Arbeitsweise kreieren.

In Scrum gibt es drei feste Rollen im Team. Alle erfüllen ihre eigene Funktion und entfalten im Zusammenspiel ihre volle Wirkung. Von einer Doppelbesetzung der Rollen ist abzusehen. Das heißt, ein:e Entwickler:in sollten nicht gleichzeitig Scrum Master sein. Scrum ist auch für Teams, denen die agile Arbeitsweise nicht vertraut ist, gut geeignet. Da es einen ersten Rahmen an die Hand gibt. 

In Extreme Programming sind bis zu 9 unterschiedliche Rollen definiert. Es müssen aber nicht alle im Team vertreten sein. Die Zusammensetzung kann je nach Bedarf individuell gestaltet sein. Einige Rollen können auch doppelt besetzt werden. So kann zum Beispiel ein:e Entwickler:in auch gleichzeitig die Position des Managers einnehmen. 

Im Extreme Programming ist der Kunden in der Regel stärker in den Entwicklungsprozess involviert als in Scrum. Denn im XP wird die Einbindung ausdrücklich beschreiben. Der Kunde ist Teil des Teams, für die Entwickler:innen jederzeit ansprechbar und gibt fast täglch Feebdack.

In Scrum ist die enge Zusammenarbeit natürlich auch möglich. Laut Scrum Guide ist der Kunde aber weniger im Prozess integriert. Im Review und eventuell noch dem Planning ist der Kunden anwesend. Ansonsten läuft die Kommunikation über den Product Owner.

Wie bereits oben erwähnt, sbekommen beide Teams regelmäßig Feedback. In Scrum findet am Ende des Sprints ein Review Meeting statt, in dem das Team dem Kunden das fertige Ergebnis vorstellt. Auf täglicher Basis tauscht sich das Team im Daily aus. Ansonsten gibt es keine fest definierten Maßnahmen.

In XP wird eine Qualitätssicherungen im Sekundentakt ermöglicht. Durch automatische Tests wird der Code zeitgleich getestet. Durch Pair Programming tauschen sich die Entwickler:innen untereinander aus. Da der Kunde sehr stark in das Team eingebunden ist, bekommen die Entwickler:innen permanent sein Feedback.

Weitere Methoden wie einer kontinuierlichen Integration des geschriebenen Codes in den Quellcode geben Aufschluss darüber, ob der Code funktioniert. Auf diese Weise kann das Team Fehler frühzeitig erkennen und die Qualität der Software sichern.

Scrum wird aus diesem Grund auch oft als ausgehöhlter Prozess “Flaccid Scrum” beschrieben. Das Framework definiert  im Vergleich zu Extreme Programming nur den äußeren Kreis. Auch wenn Scrum einen ausgeklügelten Prozess vorgibt, fehlt es an genaueren Angaben zur technischen Umsetzung, wie es in XP der Fall ist. Von daher ergänzen sich beide Frameworks in vielen Punkten und sind gut miteinander kombinierbar. 

Scrum und XP sind agile Frameworks, um eine Software effizient zu entwickeln. Dabei gehen beide Teams inkrementell vor. Die Teamrollen ähneln sich. Auch die Werte wie Respekt, Offenheit, Transparenz und Feedback spielen eine wichtige Rolle. Allerdings gibt es auch Unterschiede. Während Scrum den Prozess und die Zusammenarbeit  genau regelt, fehlt es an Vorgaben zu Programmiertechniken.

Extreme Programming hingegen legt genau darauf seine Aufmerksamkeit. Es beschreibt 12 Praktiken, welche das technische Handwerk regeln und die Qualität des Codes sowie die Effizienz steigern. Es definiert damit, wie sich das agile Mindset im Team praktisch umsetzen lässt.

Im Allgemeinen empfehlen wir die Methoden miteinander zu kombinieren und individuell zu gestalten. Da wir mit Menschen arbeiten, ist auch jedes Team anders. Das bedeutet, dass nicht jede Methode und jeder Prozess für alle passend ist. Sowohl Scrum als auch XP sehen wir als Unterstützung an.

Die Frameworks sollen den Teams helfen, effizienter zu arbeiten. Sie dürfen sie nicht daran hindern, indem sie feste Gesetze vorschreiben. Wie immer ist das agile Mindset entscheidend. Es geht darum herauszufinden, was wirklich für das Team hilfreich ist. Ums Ausprobieren, daraus lernen und den eigenen Weg finden. 

Im nächsten Artikel unserer Reihe gehen wir auf die 12 Praktiken in XP ein und erklären, wie du sich für dich und dein Team nutzen kannst. Abonniere unseren Newsletter oder folge uns auf LinkedIn. Dann erfährst du als Erstes von unseren neuen Beiträgen!